|
Posted by Unruh on May 22, 2006, 1:16 am
If you were Registered and logged in, you could reply and use other advanced thread options
>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.
| 
XML site map