Hashes and Passwords

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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

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?


Re: Hashes and Passwords

On Sun, 21 May 2006 17:36:52 +0800, "Dr Socrates"

Quoted text here. Click to load it

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          

Re: Hashes and Passwords

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:


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

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


Re: Hashes and Passwords

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


See above.

Re: Hashes and Passwords

Quoted text here. Click to load it

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

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

an attack is a man-in-the-middle substituting a much smaller iteration
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 /

Re: Hashes and Passwords

On Sun, 21 May 2006 17:36:52 +0800, Dr Socrates wrote:

Quoted text here. Click to load it

    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.

Site Timeline