5 ms·

The easy way is to support the previous work factors and increase it next time the user logs in (since you'll have the password in plaintext in memory). Either

• podperson 15y ago
  It's a hash function and, at least over an insecure connection, you should not be transferring the plaintext password from client to server so it's not guaranteed that you will have the plaintext password. Assuming you're using a secure connection and you're willing to send plaintext passwords over it then yes, you could re-hash the password when a user logs in.
  • tzs 15y ago
    In any kind of scheme where all the server stores is some kind of hash of the password, how are you going to verify a password without sending the plaintext password to the server, so the server can compute the hash and compare against the stored hash?
    • reginaldo 15y ago
      You could do that with something called a Zero-knowledge password proof[1], of which SRP[2] is an example. As far as I know, SRP is patented. It is extremely clever, though. [1] http://en.wikipedia.org/wiki/Zero-knowledge_password_proof http://en.wikipedia.org/wiki/Zero-knowledge_password_proof [2] http://en.wikipedia.org/wiki/Secure_remote_password_protocol http://en.wikipedia.org/wiki/Secure_remote_password_protocol
      • tptacek 15y ago
        To the best of my knowledge the SRP patents are not a big deal, and SRP is used in a number of commercial products. The bigger problem with SRP is that it's dangerous; it is difficult to screw bcrypt up, but it's very easy to screw SRP up; if you have to implement it yourself, dollars/donuts you're going to end up with an implementation that allows me to log in without a password.
        • reginaldo 15y ago
          I agree. I should just clarify that I'm all for bcrypt, having used it and recommended to friends/clients/employers. When I found out about SRP, I was researching on ways to do exactly what tzs asked, i.e., verifying a password without sending the plaintext (or plaintext-equivalent). In my case, the client had a login form that couldn't be placed behind SSL (don't ask why). Do you know of any solutions to this problem?
    • Smerity 15y ago
      One possible option is challenge-response authentication. There a number of variations, but the simplest example is to hash both the hashed password and a nonce on both ends and check the resulting hash[1]. This means that the server only requires that the hashed password is stored, and the client never sends the password in plaintext as it generates the hash itself. As long as the nonce is unique each time, we can prevent replay attacks. Various schemes introduce a client nonce and server nonce (to prevent man-in-the-middle attacks) or generate a shared secret nonce through methods similar to the Diffie-Hellman key exchange (so attackers can't work out the nonce). [1] Ensure that h(h(passwd)+nonce) is equal on both ends where h(passwd) is either stored (server) or created by the user providing the plaintext password. [2] http://en.wikipedia.org/wiki/Challenge-response_authentication#Simple_Example_mutual_authentication_sequence http://en.wikipedia.org/wiki/Challenge-response_authenticati...
      • TwistedWave 15y ago
        The goal of hashing the passwords is to not store them in plaintext in the database, in case the server is compromised. In your case, an attacker doesn't need the password, the hash is enough to login.
        • roel_v 15y ago
          I suppose you mean "goal <...> is to not store them in plaintext"? I was confused there for a second.
          • TwistedWave 15y ago
            Indeed, thanks. I fixed it.
  • deleted 15y ago
    [deleted]
  • roel_v 15y ago
    It's rather obvious that we're talking about a system in which the client submits the clear-text password to the server, and of course that should be done over SSL.
    • podperson 15y ago
      The vast majority of site authentications (including many very large sites) use http, so their authentication code should be hashing and salting the password on the client-side and sending the result to the server for authentication. In this model, the site never actually has a plaintext copy of the password. In this model, the server would receive the (unsalted) hash of the password when the password is set, and a salted hash for each login. At no point will the server ever have the plaintext password. I describe the implementation details here: http://loewald.com/blog/?p=1374 http://loewald.com/blog/?p=1374
      • dpark 15y ago
        This is not a secure system. It is completely broken. The hash simply becomes the password when you do this. All an attacker needs to do is replay the hash and they're in. The "plaintext" is irrelevant, because an attacker doesn't need it. Also, if you're storing the unsalted hash in your DB, your security is doubly broken. Someone who accesses your DB can more easily brute force the passwords (it looks like you're using a single salt rather than a per-user salt), and your scheme is vulnerable to rainbow attacks as well.
• antihero 15y ago
  If you know the previous work factor of a hash, you could of course re-hash it New-Old factor times.