4 ms·

I have read this article and read the Wikipedia entry on bcrypt and I still cannot understand something. In this article it states that : "As computers get fast

by Khao 15y ago

I have read this article and read the Wikipedia entry on bcrypt and I still cannot understand something. In this article it states that : "As computers get faster you can increase the work factor and the hash will get slower.". How can you make the algorithm slower over time and still be able to validate user passwords that were stored before you changed the speed? Could anyone enlighten me on this?

mshafrir 15y ago
I believe that the work factor is encoded with the hash, so bcrypt can identify which work factor to use.
- Khao 15y ago
  Thanks for your answer. At first I though it didn't make sense because the hash should be one-way and bcrypt should not decrypt the hash or mess around with it other than comparing it with what the user entered but I have searched a bit more and found this post on stackoverflow that explains in detail : http://stackoverflow.com/questions/4443476/optimal-bcrypt-work-factor http://stackoverflow.com/questions/4443476/optimal-bcrypt-wo... Your answer was right, it stores the work factor, the salt and the hash so that at any given time you can change the work factor and it will adjust in the database!
chops 15y ago
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 way, bcrypt with a paltry work factor of 7 or 8 is orders of magnitude slower than md5 and sha. Jack that up to 12 or 13 and you're pretty much good to go for years, the only problem is the near 1-second processing time on semi-current hardware.
- 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...
- antihero 15y ago
  If you know the previous work factor of a hash, you could of course re-hash it New-Old factor times.
deleted 15y ago
[deleted]
peteretep 15y ago
Here is an example: https://gist.github.com/1051238 https://gist.github.com/1051238

by Khao 15y ago

mshafrir 15y ago

I believe that the work factor is encoded with the hash, so bcrypt can identify which work factor to use.

Khao 15y ago
Thanks for your answer. At first I though it didn't make sense because the hash should be one-way and bcrypt should not decrypt the hash or mess around with it other than comparing it with what the user entered but I have searched a bit more and found this post on stackoverflow that explains in detail : http://stackoverflow.com/questions/4443476/optimal-bcrypt-work-factor http://stackoverflow.com/questions/4443476/optimal-bcrypt-wo... Your answer was right, it stores the work factor, the salt and the hash so that at any given time you can change the work factor and it will adjust in the database!

chops 15y ago

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 way, bcrypt with a paltry work factor of 7 or 8 is orders of magnitude slower than md5 and sha. Jack that up to 12 or 13 and you're pretty much good to go for years, the only problem is the near 1-second processing time on semi-current hardware.

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...
antihero 15y ago
If you know the previous work factor of a hash, you could of course re-hash it New-Old factor times.

deleted 15y ago

[deleted]

peteretep 15y ago

Here is an example: https://gist.github.com/1051238 https://gist.github.com/1051238