Hashes and Passwords

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.

Dr Socrates

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?
>
>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

Jim Watt

"Dr Socrates" <> wrote in
news:447034b9$:

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,

nemo_outis

"Dr Socrates" <> 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.

Unruh

"Dr Socrates" <> 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/

Anne & Lynn Wheeler

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.

Howard Bryce