http://qs321.pair.com?node_id=296820


in reply to Ecrypting passwords

 As has already been mentioned you can use MD5 for turning your passwords into unrecoverable strings inside your database.

 If you do this you read the password from the user, apply the MD5 function and compare the result with that in your database, this is fast, easy and very standard.

 However it suffers from two "drawbacks":

 The first point may not be a big deal to you, I guess it depends upon the nature of your site.

 The second point might be an issue if you have lots of forgetful users. In practise if you include a function for "resetting" your users passwords and mailing them a new one that will probably suffice.

Steve
---
steve.org.uk

Replies are listed 'Best First'.
Re: Re: Ecrypting passwords
by tilly (Archbishop) on Oct 06, 2003 at 00:51 UTC
    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.

[reply]
      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
[reply]
        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.)

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

        --
        bowling trophy thieves, die!

[reply]
        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.
[reply]
Re: Re: Ecrypting passwords
by crouchingpenguin (Priest) on Oct 06, 2003 at 01:02 UTC
    You don't have the plaintext password in your database, so you cannot implement a "remind me of my password" function.

    An even better way is to simply reset the password, sending them the new password and an urgent request to change it ASAP. No worry about needing to keep a plaintext copy around... so you can implement the one way md5 checksum as tilly suggested.


    cp
    ----
    "Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic."
[reply]
      That is only better if management agrees to that solution. Otherwise..well remember that part of what you are being paid for is to do things that you wouldn't choose to do if you weren't being paid..
[reply]

In Section Seekers of Perl Wisdom