Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #53340 > unrolled thread

Accessing Hunt's pwned database.

Back to article view | Back to alt.os.linux

Contents

  Accessing Hunt's pwned database. William Unruh <unruh@invalid.ca> - 2019-01-29 18:24 +0000
    Re: Accessing Hunt's pwned database. Jasen Betts <jasen@xnet.co.nz> - 2019-01-30 02:54 +0000
      Re: Accessing Hunt's pwned database. Peter Pearson <pkpearson@nowhere.invalid> - 2019-01-30 18:16 +0000
    Re: Accessing Hunt's pwned database. Richard Kettlewell <invalid@invalid.invalid> - 2019-01-30 08:59 +0000
      Re: Accessing Hunt's pwned database. Jasen Betts <jasen@xnet.co.nz> - 2019-01-30 10:47 +0000
        Re: Accessing Hunt's pwned database. Richard Kettlewell <invalid@invalid.invalid> - 2019-01-30 11:05 +0000
          Re: Accessing Hunt's pwned database. William Unruh <unruh@invalid.ca> - 2019-01-30 18:06 +0000
            Re: Accessing Hunt's pwned database. Richard Kettlewell <invalid@invalid.invalid> - 2019-01-30 20:02 +0000
              Re: Accessing Hunt's pwned database. William Unruh <unruh@invalid.ca> - 2019-01-30 22:41 +0000
                Re: Accessing Hunt's pwned database. Richard Kettlewell <invalid@invalid.invalid> - 2019-01-31 08:24 +0000
                  Re: Accessing Hunt's pwned database. William Unruh <unruh@invalid.ca> - 2019-01-31 16:50 +0000
                    Re: Accessing Hunt's pwned database. Richard Kettlewell <invalid@invalid.invalid> - 2019-02-01 14:19 +0000
                      Re: Accessing Hunt's pwned database. Jim Beard <jim.beard@verizon.net> - 2019-02-01 14:45 +0000
                        Re: Accessing Hunt's pwned database. Richard Kettlewell <invalid@invalid.invalid> - 2019-02-01 15:06 +0000
            Re: Accessing Hunt's pwned database. "Carlos E.R." <robin_listas@es.invalid> - 2019-01-30 23:23 +0100
              Re: Accessing Hunt's pwned database. William Unruh <unruh@invalid.ca> - 2019-01-30 22:43 +0000
                Re: Accessing Hunt's pwned database. "Carlos E.R." <robin_listas@es.invalid> - 2019-01-31 03:03 +0100
                  Re: Accessing Hunt's pwned database. William Unruh <unruh@invalid.ca> - 2019-01-31 02:11 +0000
        Re: Accessing Hunt's pwned database. William Unruh <unruh@invalid.ca> - 2019-01-30 20:16 +0000
        Re: Accessing Hunt's pwned database. Jasen Betts <jasen@xnet.co.nz> - 2019-01-31 03:08 +0000
          Re: Accessing Hunt's pwned database. William Unruh <unruh@invalid.ca> - 2019-01-31 04:18 +0000

Page 1 of 2  [1] 2  Next page →

#53340 — Accessing Hunt's pwned database.

Troy hunt has done a great job of making accessible the latest list of
passwords published on the net. There are reports that this list of
500000000 passwords is being used by for example the ssh attacks.
You can download the list of sha1 hashed passwords (it is about 20GB in
size which takes forever to scan) or query his database which occurs
very quickly. 

I wrote a program which you can use to test if a password is in the
database using his k-anonymizer setup.
The idea is that you take the sha1 hash of your password, send the first
5 letters of the sha1hash to his site, and it returns the list of all
hashes of passwords in his database which start with those 5 lettersi
(about 500 of them). 
This means that anyone intercepting your message (including Troy) has
virtually no knowledge of what password you sent. (the 5 letters of the
hash are not sufficient to determine what the password is, even by
exhaustive search. ) But you can "with certainty" determine whether the
password you try is in the database. 

Here is a bash script to impliment this. 


#!/bin/bash -x
T=/tmp/t1
read -s -p Password: passwd
echo
hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
passwd=''
hash1=`echo $hash|awk '{print $1}'`
hash2=`echo $hash|awk '{print $2}'`
wget -O /tmp/t1 api.pwnedpasswords.com/range/$hash1 2>/dev/null
if s=`grep $hash2 $T` ;then
	echo Times password in pwned database= `echo $s|awk -F: '{print $2}'` 
else
	echo Not in pwned database
fi
rm -f $T
hash=''
hash1=''
hash2=''
s=''

[toc] | [next] | [standalone]

#53357

On 2019-01-29, William Unruh <unruh@invalid.ca> wrote:
> Troy hunt has done a great job of making accessible the latest list of
> passwords published on the net. There are reports that this list of
> 500000000 passwords is being used by for example the ssh attacks.
> You can download the list of sha1 hashed passwords (it is about 20GB in
> size which takes forever to scan) or query his database which occurs
> very quickly. 
>
> I wrote a program which you can use to test if a password is in the
> database using his k-anonymizer setup.
> The idea is that you take the sha1 hash of your password, send the first
> 5 letters of the sha1hash to his site, and it returns the list of all
> hashes of passwords in his database which start with those 5 lettersi
> (about 500 of them). 
> This means that anyone intercepting your message (including Troy) has
> virtually no knowledge of what password you sent. (the 5 letters of the
> hash are not sufficient to determine what the password is, even by
> exhaustive search. ) But you can "with certainty" determine whether the
> password you try is in the database. 
>
> Here is a bash script to impliment this. 
>
>
> #!/bin/bash -x
...

 Neato!  
 
I changed it to use bash bult-ins for most of the string manipulation
mainly because OCD 

And added a check on wget (which may return a error eg because DoS)
 
		     
#!/bin/bash
read -s -p Password: passwd
echo
hash="$(echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F')"
unset passwd
hash1="${hash:0:5}"
hash2="${hash:5:35}"
nl=$'\n'
if res="$nl$(wget -O- api.pwnedpasswords.com/range/$hash1 2>/dev/null)" 
then if
  s="${res#*$nl$hash2:}" &&
  [ "$s" != "$res" ]
then
        echo "Times password in pwned database= ${s%%$nl*}"
else
        echo Not in pwned database
fi
else
 echo network error >&2
fi
unset res hash1 hash2 hash s nl




1337 considered hamful:

 root : 11915
 r00t : 18740

-- 
  When I tried casting out nines I made a hash of it.

[toc] | [prev] | [next] | [standalone]

#53394

On Wed, 30 Jan 2019 02:54:46 -0000 (UTC), Jasen Betts <jasen@xnet.co.nz> wrote:
> On 2019-01-29, William Unruh <unruh@invalid.ca> wrote:
[snip]
>>
>> Here is a bash script to impliment this. 
[snip]
>  
> I changed it to use bash bult-ins for most of the string manipulation
> mainly because OCD 

Beautiful!  Many thanks to both of you.

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#53373

William Unruh <unruh@invalid.ca> writes:
> Here is a bash script to impliment this. 
>
>
> #!/bin/bash -x
> T=/tmp/t1
> read -s -p Password: passwd
> echo
> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`

This not a secure approach. The candidate password will briefly appear
in ps output.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#53374

On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
> William Unruh <unruh@invalid.ca> writes:
>> Here is a bash script to impliment this. 
>>
>>
>> #!/bin/bash -x
>> T=/tmp/t1
>> read -s -p Password: passwd
>> echo
>> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
>
> This not a secure approach. The candidate password will briefly appear
> in ps output.
>


hash = $( (tr -d $'\n' << pwd
$passwd
pwd
) | sha1sum | tr 'a-f' 'A-F'|sed 's/^...../& /g')


blech!

maybe there's a better way.




-- 
  When I tried casting out nines I made a hash of it.

[toc] | [prev] | [next] | [standalone]

#53375

Jasen Betts <jasen@xnet.co.nz> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> William Unruh <unruh@invalid.ca> writes:
>>> Here is a bash script to impliment this. 
>>>
>>> #!/bin/bash -x
>>> T=/tmp/t1
>>> read -s -p Password: passwd
>>> echo
>>> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
>>
>> This not a secure approach. The candidate password will briefly appear
>> in ps output.
>
> hash = $( (tr -d $'\n' << pwd
> $passwd
> pwd
> ) | sha1sum | tr 'a-f' 'A-F'|sed 's/^...../& /g')
>
>
> blech!
>
> maybe there's a better way.

There is: use a more sensible language than shell.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#53391

On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Jasen Betts <jasen@xnet.co.nz> writes:
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> William Unruh <unruh@invalid.ca> writes:
>>>> Here is a bash script to impliment this. 
>>>>
>>>> #!/bin/bash -x
>>>> T=/tmp/t1
>>>> read -s -p Password: passwd
>>>> echo
>>>> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
>>>
>>> This not a secure approach. The candidate password will briefly appear
>>> in ps output.

I did think of that but also know that the amount of time it does so is
very small, but could not think of a way of doing so with my knowledge. 
>>
>> hash = $( (tr -d $'\n' << pwd
>> $passwd
>> pwd
>> ) | sha1sum | tr 'a-f' 'A-F'|sed 's/^...../& /g')
>>
>>
>> blech!
>>
>> maybe there's a better way.
>
> There is: use a more sensible language than shell.

Helpful aren't you?
When a hammer is the only tool you have you have to make everything look
like a nail. One of the key things I want is that almost anyone can look
at the program and see exactly what it does. Anyone that uses a program
to ship out passwords to unknown places in the world (and I and 99.9999%
of the world have no idea who Troy Hunt is or how reliable he is-- and
this is NOT an invitation for anyone to tell me) should know exactly and
easily how the program is handling the password.  A bash scipt does
that. Troy's web pages do not. 

>

[toc] | [prev] | [next] | [standalone]

#53399

William Unruh <unruh@invalid.ca> writes:
> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Jasen Betts <jasen@xnet.co.nz> writes:
>>> maybe there's a better way.
>>
>> There is: use a more sensible language than shell.
>
> Helpful aren't you?
> When a hammer is the only tool you have you have to make everything look
> like a nail.

Personally I prefer to find the right tool for the job. Life’s a lot
better than way. In this particular case, better-design languages are
readily available on Linux.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#53415

On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
> William Unruh <unruh@invalid.ca> writes:
>> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> Jasen Betts <jasen@xnet.co.nz> writes:
>>>> maybe there's a better way.
>>>
>>> There is: use a more sensible language than shell.
>>
>> Helpful aren't you?
>> When a hammer is the only tool you have you have to make everything look
>> like a nail.
>
> Personally I prefer to find the right tool for the job. Life’s a lot
> better than way. In this particular case, better-design languages are
> readily available on Linux.
>

It depends on the job. In this case one would have to learn those other
languages first, and that would take days (or weeks or months) and this
problem simply is not worth that time committment on my part. 
Of course if you happen to know other languages, then using them (the
lerning commitment is already in place) is probably a good idea. 
It is like, you have a hammer, and if you were to use some other tool
you would first have to make the tool (eg smelt some steel, create a
rod, and then file down the rod to make a screwdriver). 
It is not the availability of the language, but the knowledge of how to
use the language that is the impediment. 
Plus as I said, I wanted the program to be obvious in what it does, and
I suspect that a bash script is more readable than a perl script say, or
whatever your favourite interpreted language is. Non-interpreted
languages are a no-go because it is impossible for anyone to read the
compiled language and know what it does. 

Anyway, I encourage you to write something in your language of choice
that does what I want to do. 

[toc] | [prev] | [next] | [standalone]

#53436

William Unruh <unruh@invalid.ca> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> William Unruh <unruh@invalid.ca> writes:
>>> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> Jasen Betts <jasen@xnet.co.nz> writes:
>>>>> maybe there's a better way.
>>>>
>>>> There is: use a more sensible language than shell.
>>>
>>> Helpful aren't you?
>>> When a hammer is the only tool you have you have to make everything look
>>> like a nail.
>>
>> Personally I prefer to find the right tool for the job. Life’s a lot
>> better than way. In this particular case, better-design languages are
>> readily available on Linux.
>
> It depends on the job. In this case one would have to learn those other
> languages first, and that would take days (or weeks or months) and this
> problem simply is not worth that time committment on my part. 
> Of course if you happen to know other languages, then using them (the
> lerning commitment is already in place) is probably a good idea.

Unless you only ever have one problem to solve, the cost of learning new
languages is ammortized over the whole set of problems you address with
them.

> It is like, you have a hammer, and if you were to use some other tool
> you would first have to make the tool (eg smelt some steel, create a
> rod, and then file down the rod to make a screwdriver).
> It is not the availability of the language, but the knowledge of how to
> use the language that is the impediment.

I’ve not encountered anyone arguing in _favour_ of “when the only tool
you have is a hammer, every problem looks like a nail” before. Usually
it’s seen as something to avoid.

> Plus as I said, I wanted the program to be obvious in what it does, and
> I suspect that a bash script is more readable than a perl script say, or
> whatever your favourite interpreted language is.

That’s only true for readers who have already learned shell scripting.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#53447

On 2019-01-31, Richard Kettlewell <invalid@invalid.invalid> wrote:
> William Unruh <unruh@invalid.ca> writes:
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> William Unruh <unruh@invalid.ca> writes:
>>>> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>>> Jasen Betts <jasen@xnet.co.nz> writes:
>>>>>> maybe there's a better way.
>>>>>
>>>>> There is: use a more sensible language than shell.
>>>>
>>>> Helpful aren't you?
>>>> When a hammer is the only tool you have you have to make everything look
>>>> like a nail.
>>>
>>> Personally I prefer to find the right tool for the job. Life’s a lot
>>> better than way. In this particular case, better-design languages are
>>> readily available on Linux.
>>
>> It depends on the job. In this case one would have to learn those other
>> languages first, and that would take days (or weeks or months) and this
>> problem simply is not worth that time committment on my part. 
>> Of course if you happen to know other languages, then using them (the
>> lerning commitment is already in place) is probably a good idea.
>
> Unless you only ever have one problem to solve, the cost of learning new
> languages is ammortized over the whole set of problems you address with
> them.

I am certainly not arguing against learning other languages. But to use
the tools you have readily available to kludge together a solution to a
problem is better than to not do anything because you do not have
exactly the right tools at hand. 
>
>> It is like, you have a hammer, and if you were to use some other tool
>> you would first have to make the tool (eg smelt some steel, create a
>> rod, and then file down the rod to make a screwdriver).
>> It is not the availability of the language, but the knowledge of how to
>> use the language that is the impediment.
>
> I’ve not encountered anyone arguing in _favour_ of “when the only tool
> you have is a hammer, every problem looks like a nail” before. Usually
> it’s seen as something to avoid.

I changed it to "every problem must be made to look like a nail"
So when one of our favourite posters wrote his programs in ADA, you
rushed out to learn Ada in case it was useful for many other programs?

In this case Jason improved my version in bash sufficiently that it now
looks reasonable (but somewhat less transparent). (I am sure you could have whipped up a perl routine
even faster than I made the original bash script, but didn't.) 

>
>> Plus as I said, I wanted the program to be obvious in what it does, and
>> I suspect that a bash script is more readable than a perl script say, or
>> whatever your favourite interpreted language is.
>
> That’s only true for readers who have already learned shell scripting.

Well, not really. While the details might be obscure, the script is
simple enough that one could read it even without knowing shell. 
And one could always run it with bash -x and explicity see what is sent out. 
I do agree that you would have to know about -x. 

Can you read Troy's html and see that what he does is essentially
equivalent to what I did? Not his explanation, but the actual code.
If I am going to be entering all my passwords into a program being
shipped out to someone I do not know, I am not going to take his word as
to what his program does. 
That would seem to be an even more important security aspect than
worrying about whether the password would be revealed in a ps listing
for a millisecond of time. 

[toc] | [prev] | [next] | [standalone]

#53471

William Unruh <unruh@invalid.ca> writes:
> On 2019-01-31, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> I’ve not encountered anyone arguing in _favour_ of “when the only tool
>> you have is a hammer, every problem looks like a nail” before. Usually
>> it’s seen as something to avoid.
>
> I changed it to "every problem must be made to look like a nail"
> So when one of our favourite posters wrote his programs in ADA, you
> rushed out to learn Ada in case it was useful for many other programs?

No, don’t be silly. When I find the language(s) I know are a poor fit
for some set of problems, though, I do look for better choices, and
adopt them where I can.

Now it may be that not everyone is equipped to learn computer languages
in the first place, but if someone is capable of learning shell, other
scripting languages aren’t that big a leap.

>>> Plus as I said, I wanted the program to be obvious in what it does,
>>> and I suspect that a bash script is more readable than a perl script
>>> say, or whatever your favourite interpreted language is.
>>
>> That’s only true for readers who have already learned shell scripting.
>
> Well, not really. While the details might be obscure, the script is
> simple enough that one could read it even without knowing shell.

Humans are not born with the knowledge of what backticks do, or of the
sed or awk syntax your program uses, or what the options to read mean,
and so on. It’s all learned, and someone who hasn’t learned it is not
going to have an easy time interpreting your script.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#53472

On Fri, 01 Feb 2019 14:19:45 +0000, Richard Kettlewell wrote:
> William Unruh <unruh@invalid.ca> writes:

>> Well, not really. While the details might be obscure, the script is
>> simple enough that one could read it even without knowing shell.
> 
> Humans are not born with the knowledge of what backticks do, or of the
> sed or awk syntax your program uses, or what the options to read mean,
> and so on. It’s all learned, and someone who hasn’t learned it is not
> going to have an easy time interpreting your script.

Linux like UNIX requires an administrator with some level of knowledge.
An ability to read a shell script, use man pages, and search for things 
using grep and perhaps locate would seem to fall within that "some level" 
of knowledge.

An "easy time" interpreting a script is not a requirement, but it should 
be possible for an administrator with minimal knowledge to discern what 
the script is doing, how.  Some searching on the 'Net for elaboration may 
be required.

Cheers!

jim b.

-- 
UNIX is not user-unfriendly, it merely expects users 
     to be computer-friendly.

[toc] | [prev] | [next] | [standalone]

#53475

Jim Beard <jim.beard@verizon.net> writes:

> On Fri, 01 Feb 2019 14:19:45 +0000, Richard Kettlewell wrote:
>> William Unruh <unruh@invalid.ca> writes:
>
>>> Well, not really. While the details might be obscure, the script is
>>> simple enough that one could read it even without knowing shell.
>> 
>> Humans are not born with the knowledge of what backticks do, or of the
>> sed or awk syntax your program uses, or what the options to read mean,
>> and so on. It’s all learned, and someone who hasn’t learned it is not
>> going to have an easy time interpreting your script.
>
> Linux like UNIX requires an administrator with some level of knowledge.
> An ability to read a shell script, use man pages, and search for things 
> using grep and perhaps locate would seem to fall within that "some level" 
> of knowledge.

I don’t really agree, but it’s hardly relevant, since William’s argument
is that the script can be understood _without_ knowing shell.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#53414

On 30/01/2019 19.06, William Unruh wrote:
> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Jasen Betts <jasen@xnet.co.nz> writes:
>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> William Unruh <unruh@invalid.ca> writes:
>>>>> Here is a bash script to impliment this. 
>>>>>
>>>>> #!/bin/bash -x
>>>>> T=/tmp/t1
>>>>> read -s -p Password: passwd
>>>>> echo
>>>>> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
>>>>
>>>> This not a secure approach. The candidate password will briefly appear
>>>> in ps output.
> 
> I did think of that but also know that the amount of time it does so is
> very small, but could not think of a way of doing so with my knowledge. 

I don't think it is an issue, as it runs in your own computer and would
only be visible to people with the right access in that computer.

Just don't run it on an internet café machine.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#53416

On 2019-01-30, Carlos E.R. <robin_listas@es.invalid> wrote:
> On 30/01/2019 19.06, William Unruh wrote:
>> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> Jasen Betts <jasen@xnet.co.nz> writes:
>>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>>> William Unruh <unruh@invalid.ca> writes:
>>>>>> Here is a bash script to impliment this. 
>>>>>>
>>>>>> #!/bin/bash -x
>>>>>> T=/tmp/t1
>>>>>> read -s -p Password: passwd
>>>>>> echo
>>>>>> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
>>>>>
>>>>> This not a secure approach. The candidate password will briefly appear
>>>>> in ps output.
>> 
>> I did think of that but also know that the amount of time it does so is
>> very small, but could not think of a way of doing so with my knowledge. 
>
> I don't think it is an issue, as it runs in your own computer and would
> only be visible to people with the right access in that computer.
>
> Just don't run it on an internet café machine.
>

Yes, that was a part of my argument to myself. Mind you, it is always
better to make sure that insecurities do not exist than to hope that
noone makes use of them for whatever reason. 

[toc] | [prev] | [next] | [standalone]

#53427

On 30/01/2019 23.43, William Unruh wrote:
> On 2019-01-30, Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 30/01/2019 19.06, William Unruh wrote:
>>> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> Jasen Betts <jasen@xnet.co.nz> writes:
>>>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>>>> William Unruh <unruh@invalid.ca> writes:
>>>>>>> Here is a bash script to impliment this. 
>>>>>>>
>>>>>>> #!/bin/bash -x
>>>>>>> T=/tmp/t1
>>>>>>> read -s -p Password: passwd
>>>>>>> echo
>>>>>>> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
>>>>>>
>>>>>> This not a secure approach. The candidate password will briefly appear
>>>>>> in ps output.
>>>
>>> I did think of that but also know that the amount of time it does so is
>>> very small, but could not think of a way of doing so with my knowledge. 
>>
>> I don't think it is an issue, as it runs in your own computer and would
>> only be visible to people with the right access in that computer.
>>
>> Just don't run it on an internet café machine.
>>
> 
> Yes, that was a part of my argument to myself. Mind you, it is always
> better to make sure that insecurities do not exist than to hope that
> noone makes use of them for whatever reason. 

It is no problem at all when run on a computer that you control. There
are other applications that can leak information that way (I think one
of the pgp tools, no less). So, just tell the problem with the code, do
not use on a computer shared with other people, and that's it.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#53428

On 2019-01-31, Carlos E.R. <robin_listas@es.invalid> wrote:
>
> It is no problem at all when run on a computer that you control. There
> are other applications that can leak information that way (I think one
> of the pgp tools, no less). So, just tell the problem with the code, do
> not use on a computer shared with other people, and that's it.

Of course this program is most useful on a multi-user machine. 
>

[toc] | [prev] | [next] | [standalone]

#53401

On 2019-01-30, Jasen Betts <jasen@xnet.co.nz> wrote:
> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> William Unruh <unruh@invalid.ca> writes:
>>> Here is a bash script to impliment this. 
>>>
>>>
>>> #!/bin/bash -x
>>> T=/tmp/t1
>>> read -s -p Password: passwd
>>> echo
>>> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
>>
>> This not a secure approach. The candidate password will briefly appear
>> in ps output.
>>
>
>
> hash = $( (tr -d $'\n' << pwd
> $passwd
> pwd
> ) | sha1sum | tr 'a-f' 'A-F'|sed 's/^...../& /g')

That should be

hash="$( (tr -d $'\n' << pwd
$passwd
pwd
) | sha1sum | tr 'a-f' 'A-F'|sed 's/^...../& /g')"


bash does not like a space after the =
nor does it like spaces in the right hand side (sha1sum give the hash
followed by space minus sign )

>
>
> blech!
>
> maybe there's a better way.

That would be nice I agree.
Certainly if you were to use this script within a login or a password
setting program, I would be worried about the brief show of the password
with echo. For a stand alone program I am not sure that the brief reveal
of the password in ps would be a worry.

[toc] | [prev] | [next] | [standalone]

#53429

On 2019-01-30, Jasen Betts <jasen@xnet.co.nz> wrote:
> On 2019-01-30, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> William Unruh <unruh@invalid.ca> writes:
>>> Here is a bash script to impliment this. 
>>>
>>>
>>> #!/bin/bash -x
>>> T=/tmp/t1
>>> read -s -p Password: passwd
>>> echo
>>> hash=`echo -n "$passwd"|sha1sum|tr 'a-f' 'A-F'|sed 's/^...../& /g'`
>>
>> This not a secure approach. The candidate password will briefly appear
>> in ps output.
>>
>
>
> hash = $( (tr -d $'\n' << pwd
> $passwd
> pwd
> ) | sha1sum | tr 'a-f' 'A-F'|sed 's/^...../& /g')
>
>
> blech!
>
> maybe there's a better way.
>

there is:

 echo -n Password:
 # turn off input echo
 stty -echo 
 # read a single line, trim the newline, hash and slice.
 hash=$(head -1 | tr -d $'\n' | sha1sum | tr 'a-f' 'A-F'|sed 's/^...../& /g' )
 stty  echo
 # move cursor to next line
 echo
   
this one supports leading and trailing spaces on the password. but
pwned database doesn't seem to include any password like that.

-- 
  When I tried casting out nines I made a hash of it.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.os.linux

csiph-web