Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Re: Re: Ecrypting passwords

by waswas-fng (Curate)
on Oct 06, 2003 at 04:35 UTC ( #296859=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Ecrypting passwords
in thread Ecrypting passwords

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.


Replies are listed 'Best First'.
Re: Re: Re: Re: Ecrypting passwords
by tilly (Archbishop) on Oct 06, 2003 at 05:18 UTC

    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?

        That is what I meant by the phrase, The vulnerability to things like replay attacks is controllable on the server side in how it produces and verifies what the nonce was.

        However it is good to make it clear how you avoid replays, and why you would want to.

      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.

Re: Re: Re: Re: Ecrypting passwords
by Willard B. Trophy (Hermit) on Oct 06, 2003 at 17:18 UTC
    Alternatively, if you don't mind requiring JavaScript, PAJ has MD4, MD5 and SHA-1 password hashing for CHAP login.

    bowling trophy thieves, die!

Re: Re: Re: Re: Ecrypting passwords
by bdonlan (Novice) on Oct 07, 2003 at 22:32 UTC
    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?

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2023-10-01 22:31 GMT
Find Nodes?
    Voting Booth?

    No recent polls found