Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: Re: Ecrypting passwords

by tilly (Archbishop)
on Oct 06, 2003 at 00:51 UTC ( #296827=note: print w/replies, xml ) Need Help??


in reply to Re: Ecrypting passwords
in thread Ecrypting passwords

Your users are still sending their passwords in plaintext, unless you're using a secure server and HTTPS.

Not necessarily true. See Digest Authentication, which there is a useful introduction to here.

Replies are listed 'Best First'.
Re: Re: Re: Ecrypting passwords
by waswas-fng (Curate) on Oct 06, 2003 at 04:35 UTC
    Digest Auth still effectivly transfers the password in plaintext no? sure the client hashes to md5 or whatever but someone listning on the line can use that hash to auth just as easily as the plaintext version. I have not read the full RFC but that is my understanding of it.


    -Waswas
      No.

      The idea is that both sides prove that they know the same secret. The server sends the browser a challenge string called a nonce. The browser's reply contains both the nonce and an MD5 hash of various information including the nonce and its secret. The server satisfies itself that the nonce was valid, and tries to do the same hashing calculation. If the server and browser come up with the same answer, then they knew the same secret, and have managed to verify this without ever saying the secret.

      The vulnerability to things like replay attacks is controllable on the server side in how it produces and verifies what the nonce was. Even if you can do a replay, you cannot use it against other pages because the complete requested URI is part of the hash. So a man in the middle can get the same page that they saw flying past a second ago.

      Incidentally the shared secret is: Digest::MD5::md5_hex("$user:$realm:$password") So the server doesn't have to keep the actual password, but if you have used a one-way encryption mechanism which is incompatible with the above, then you will not be able to transparently move users to Digest authentication.

      (Or at least this is how I read the documentation after scanning it quickly.)

        Good description of Digest encrytption from what I remember about it. I'd just like to add a slight addition though..

        If I remember correctly from what I read in Applied Cryptography (My copy is currently on loan, alas) if required a nonce can be strengthened by adding an accurate timestamp, request counter, or other non-repeating series.

        By using Digest::MD5::md5_hex("$user:$realm:$password:$series_id") as the nonce, and keeping track of 'used' nonces and rejecting them it stops the man-in-the-middle even being able to use replay attacks to see those pages that just flew past them.

        After all, would you really want someone to replay your entire session for shutting down your database server when they so choose?

        Just a side note. Hashing the user, realm, and password to create the shared secret does not provide the same protection the hashing in standard password files. The hash is the shared secret so anyone who retrieves the password database can use the secret to authenticate. They don't need the brute force the plaintext password like the password files.

        The advantage is that they don't acquire the plaintext password and can't use it to login into any other services that use the same password.

      Alternatively, if you don't mind requiring JavaScript, PAJ has MD4, MD5 and SHA-1 password hashing for CHAP login.

      --
      bowling trophy thieves, die!

      Are partial hashes secure for this purpose? If so, you could store a partial hash and send some sort of random token to the client. The client could then create a hash from the password and token, and the server could check by finishing the hash with the token. If the tokens are not reusable, then I'd think that'd solve the problem.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://296827]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (8)
As of 2021-04-16 11:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?