Hashes and Passwords

Discussion in 'Computer Security' started by Dr Socrates, May 21, 2006.

  1. Dr Socrates

    Dr Socrates Guest

    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, May 21, 2006
    #1
    1. Advertising

  2. Dr Socrates

    Jim Watt Guest

    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, May 21, 2006
    #2
    1. Advertising

  3. Dr Socrates

    nemo_outis Guest

    "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, May 21, 2006
    #3
  4. Dr Socrates

    Unruh Guest

    "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, May 22, 2006
    #4
  5. "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, May 22, 2006
    #5
  6. Dr Socrates

    Howard Bryce Guest

    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, May 22, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. AdminKen

    Wireless LAN with PEAP and Passwords Aironet 1200

    AdminKen, Mar 30, 2005, in forum: Wireless Networking
    Replies:
    3
    Views:
    7,786
    Jeffrey Chong
    Sep 4, 2006
  2. Michael King

    Change password with 802.1x WinXP and cached Passwords.

    Michael King, Apr 25, 2005, in forum: Wireless Networking
    Replies:
    0
    Views:
    973
    Michael King
    Apr 25, 2005
  3. Dennis J. Tuchler

    Thunderbird and Passwords

    Dennis J. Tuchler, Jul 9, 2004, in forum: Firefox
    Replies:
    2
    Views:
    467
    Dennis J. Tuchler
    Jul 10, 2004
  4. Northern Lights
    Replies:
    3
    Views:
    1,189
    AnyBody43
    Aug 3, 2004
  5. monkeesandbananas
    Replies:
    0
    Views:
    669
    monkeesandbananas
    Apr 22, 2008
Loading...

Share This Page