Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > Hashes and Passwords

Reply
Thread Tools

Hashes and Passwords

 
 
Dr Socrates
Guest
Posts: n/a
 
      05-21-2006
I am a student as well as "preacher" of network security in Singapore.

While teaching some of my friends about hashes, I told them Yahoo! Mail (and
most other Web-based email services) use
hashes to safeguard the password from being stolen from the user's
(client's) end.

Instead of the password being sent in the clear, it would be better to send
a hash of the password. If the hash is obtained
by a malicious node, it is not going to be very useful since it is not the
actual password.

The email server will hash its own copy of the password and compare the hash
it just generated against
the one sent by the client. If both hashes are the same, then the client is
authenticated.

After thinking about it and analyzing a great deal, I found that this not
really as secure as it first appears to be.

The hashed password method entails that either side keep a copy of the
password. Either the client
send sthe password in cleartext and the hashed version is kept by the
server. Or vice versa. It is even more dangerous
for the server to keep the password. If the email service is popular, like
Gmail, Hotmail or Yahoo, then the passwords
database is going to be very huge, in the millions. Any compromise of the
passwords database would be a disaster.
The risk can be mitigated somewhat by encrypting the paswords database.

I realized that the client sending the hash is not a truly secure method
because it could be captured by a sniffer.
The sniffer could then log onto the server by sending the hash to the
server. The server does not care as long
as the hash it generates itself is the same as the one it generates itself.
There is this risk - of someone playing this
replay attack.

Encrypting the password and then sending the ciphertext would be good,
however the requirments and overhead are
going to make it expensive - in terms of resources used and the time
required. Hashes are cheaper and faster but they
are apparently not totally safe.

Can the experts here please comment and shed some light?

Thanks.


 
Reply With Quote
 
 
 
 
Jim Watt
Guest
Posts: n/a
 
      05-21-2006
On Sun, 21 May 2006 17:36:52 +0800, "Dr Socrates"
<(E-Mail Removed)> wrote:

>I am a student as well as "preacher" of network security in Singapore.
>
>While teaching some of my friends about hashes, I told them Yahoo! Mail (and
>most other Web-based email services) use
>hashes to safeguard the password from being stolen from the user's
>(client's) end.
>
>Instead of the password being sent in the clear, it would be better to send
>a hash of the password. If the hash is obtained
>by a malicious node, it is not going to be very useful since it is not the
>actual password.
>
>The email server will hash its own copy of the password and compare the hash
>it just generated against
>the one sent by the client. If both hashes are the same, then the client is
>authenticated.
>
>After thinking about it and analyzing a great deal, I found that this not
>really as secure as it first appears to be.
>
>The hashed password method entails that either side keep a copy of the
>password. Either the client
>send sthe password in cleartext and the hashed version is kept by the
>server. Or vice versa. It is even more dangerous
>for the server to keep the password. If the email service is popular, like
>Gmail, Hotmail or Yahoo, then the passwords
>database is going to be very huge, in the millions. Any compromise of the
>passwords database would be a disaster.
>The risk can be mitigated somewhat by encrypting the paswords database.
>
>I realized that the client sending the hash is not a truly secure method
>because it could be captured by a sniffer.
>The sniffer could then log onto the server by sending the hash to the
>server. The server does not care as long
>as the hash it generates itself is the same as the one it generates itself.
>There is this risk - of someone playing this
>replay attack.
>
>Encrypting the password and then sending the ciphertext would be good,
>however the requirments and overhead are
>going to make it expensive - in terms of resources used and the time
>required. Hashes are cheaper and faster but they
>are apparently not totally safe.
>
>Can the experts here please comment and shed some light?
>
>Thanks.



The idea of storing a hash is to prevent the password being disclosed
by someone reading data from the host machine.

If the password is exchanged using SSL as most of these systems do for
logon it should be safe in transit.
--
Jim Watt
http://www.gibnet.com
 
Reply With Quote
 
 
 
 
nemo_outis
Guest
Posts: n/a
 
      05-21-2006
"Dr Socrates" <(E-Mail Removed)> wrote in
news:447034b9$(E-Mail Removed):

The subject of authentication (one-way and two-way) has been the object of
a great deal of study. A little googling will bury you in choices.

A good starting point is the Wikipedia:

http://en.wikipedia.org/wiki/Authentication

If you'd like to get your teeth into something meatier, try Kerberos:

http://web.mit.edu/kerberos/

Regards,

 
Reply With Quote
 
Unruh
Guest
Posts: n/a
 
      05-22-2006
"Dr Socrates" <(E-Mail Removed)> writes:

>I am a student as well as "preacher" of network security in Singapore.


>While teaching some of my friends about hashes, I told them Yahoo! Mail (and
>most other Web-based email services) use
>hashes to safeguard the password from being stolen from the user's
>(client's) end.


>Instead of the password being sent in the clear, it would be better to send
>a hash of the password. If the hash is obtained
>by a malicious node, it is not going to be very useful since it is not the
>actual password.


>The email server will hash its own copy of the password and compare the hash
>it just generated against
>the one sent by the client. If both hashes are the same, then the client is
>authenticated.


The hash sent is password equivalent. The bad guy simply sends teh hash he
grabbed from the net. The email client has no way of knowing whether that
hash was derived from the password or was snaffled from the net.

This problem has an ancient history. For example the chap/pap in ppp --
chap protects against password snaffling but stores passwords on the server
in the clear and thus is liable to server attacks. pap can store the hash
but the cleartext password is sent. There is a procedure called eap (SRP)
(srp.stanford.edu) gets by both these problems.


>After thinking about it and analyzing a great deal, I found that this not
>really as secure as it first appears to be.


>The hashed password method entails that either side keep a copy of the
>password. Either the client
>send sthe password in cleartext and the hashed version is kept by the
>server. Or vice versa. It is even more dangerous
>for the server to keep the password. If the email service is popular, like
>Gmail, Hotmail or Yahoo, then the passwords
>database is going to be very huge, in the millions. Any compromise of the
>passwords database would be a disaster.
>The risk can be mitigated somewhat by encrypting the paswords database.


>I realized that the client sending the hash is not a truly secure method
>because it could be captured by a sniffer.
>The sniffer could then log onto the server by sending the hash to the
>server. The server does not care as long
>as the hash it generates itself is the same as the one it generates itself.
>There is this risk - of someone playing this
>replay attack.


Yes.


>Encrypting the password and then sending the ciphertext would be good,
>however the requirments and overhead are
>going to make it expensive - in terms of resources used and the time
>required. Hashes are cheaper and faster but they
>are apparently not totally safe.


>Can the experts here please comment and shed some light?



See above.

 
Reply With Quote
 
Anne & Lynn Wheeler
Guest
Posts: n/a
 
      05-22-2006
"Dr Socrates" <(E-Mail Removed)> writes:
> Instead of the password being sent in the clear, it would be better
> to send a hash of the password. If the hash is obtained by a
> malicious node, it is not going to be very useful since it is not
> the actual password.


the issue is evesdropping static data transmitted and using it for
replay attack.

regardless of what it is called, if it is the same data (static) sent
each time ... and is compared against something; then it can be
evesdropped and replayed. whatever it is called being transmitted, if
it is always the same, then it can be evesdropped and replayed.

for a little drift, here is discussion of one-time-password hash
scheme ... based on hash being a one-way function, and the use of hash
iterations that decrements on each use. the server has to remember the
previous hash and the current hash iteration count . the server sends
the client one less than the current hash iteration count. the client
then does hash iterations for the indicated count and transmits that
value. the server hashes the received value and compares it with the
saved value. if correct, the server decrements the count by one and
saves the most recently transmitted value.

the issue here is that the same value/hash is not transmitted each
time ... so it supposedly is not subject to replay attack (and since
hash is one-way function, simple evesdropping can't predict the next
value.

however, the original claims were that the transmissions did not have
to hidden/encrypted (countermeasure to evesdropping) and/or require
the client to carry with them anything; supposedly useable in public
environment. it supposedly then is also immune to man-in-the-middle
attacks.

an attack is a man-in-the-middle substituting a much smaller iteration
count
http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
 
Reply With Quote
 
Howard Bryce
Guest
Posts: n/a
 
      05-22-2006
On Sun, 21 May 2006 17:36:52 +0800, Dr Socrates wrote:

> I am a student as well as "preacher" of network security in Singapore.
>
> While teaching some of my friends about hashes, I told them Yahoo! Mail
> (and most other Web-based email services) use hashes to safeguard the
> password from being stolen from the user's (client's) end.
>
> Instead of the password being sent in the clear, it would be better to
> send a hash of the password. If the hash is obtained by a malicious node,
> it is not going to be very useful since it is not the actual password.
>
> The email server will hash its own copy of the password and compare the
> hash it just generated against
> the one sent by the client. If both hashes are the same, then the client
> is authenticated.
>
> After thinking about it and analyzing a great deal, I found that this not
> really as secure as it first appears to be.
>
> The hashed password method entails that either side keep a copy of the
> password. Either the client
> send sthe password in cleartext and the hashed version is kept by the
> server. Or vice versa. It is even more dangerous for the server to keep
> the password. If the email service is popular, like Gmail, Hotmail or
> Yahoo, then the passwords database is going to be very huge, in the
> millions. Any compromise of the passwords database would be a disaster.
> The risk can be mitigated somewhat by encrypting the paswords database.
>
> I realized that the client sending the hash is not a truly secure method
> because it could be captured by a sniffer. The sniffer could then log onto
> the server by sending the hash to the server. The server does not care as
> long as the hash it generates itself is the same as the one it generates
> itself. There is this risk - of someone playing this replay attack.
>
> Encrypting the password and then sending the ciphertext would be good,
> however the requirments and overhead are going to make it expensive - in
> terms of resources used and the time required. Hashes are cheaper and
> faster but they are apparently not totally safe.
>
> Can the experts here please comment and shed some light?


Have you considered using a one-time password mechanism? With such an
approach, the server does not have to store any piece of information that
requires any protection.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to make an array of hashes to a single array with all thevalues of these hashes ? kazaam Ruby 12 09-13-2007 01:30 PM
"Pseudo-hashes are deprecated" error and accessing a hash of hashes ernestm@mindspring.com Perl Misc 3 01-31-2006 04:40 AM
using hashes as keys in hashes Steven Arnold Ruby 3 11-23-2005 03:25 PM
Hash of hashes, of hashes, of arrays of hashes Tim O'Donovan Perl Misc 5 10-28-2005 05:59 AM
Hashes of Hashes via subs Ben Holness Perl 8 10-08-2003 06:57 AM



Advertisments