4 ms·

With bcrypt you can set a parameter which determines how slow it is. So if hardware gets faster, you can change the parameter. (brcrypt uses 2^n iterations wher

With bcrypt you can set a parameter which determines how slow it is. So if hardware gets faster, you can change the parameter. (brcrypt uses 2^n iterations where n is the parameter.) So it doesn't matter on what hardware, if you want bcrypt to take 1 second on modern hardware (for any value of "modern"), you can.

nilved 10y ago
But 1 second of CPU time on your Web server is a lot different than 1 second of CPU time on a supercomputer.
- nathan-wall 10y ago
  Or 1 second of GPU time. Or 1 second of time running on an ASIC.
DasIch 10y ago
Chances are that you can't afford the most modern hardware. An attacker at least temporarily can probably afford more than you can. If you configure bcrypt so that an attacker spends 1s, it will be to slow to be practical for you.
- sokoloff 10y ago
  Yes, but even if you allow it to only take 1ms per check for an attacker, it's still practical for you and will take an attacker 4 minutes per account to check all of /usr/share/dict/words (to say nothing of the "add a 1 or a ! at the end"), so long as you are using random per-account salt (which bcrypt basically guides you towards). Make it 15ms for an attacker and it becomes an hour per account just for the dictionary.
  - DasIch 10y ago
    True but in reality an attacker won't just use any dictionary. They look at password leaks, figure out what passwords people are actually using and what the most popular ones are. You also can't assume that all accounts are equally valueable. An attacker might very well prioritize some of them. This doesn't render all of this useless but I think you shouldn't consider even best solutions out there to be anything else than a temporary barrier. It's a good one and you probably will have enough time to change your password after a leak but you really do need to change your password within a week or so.
Unklejoe 10y ago
It seems like implementing a security strength which is a function of the current practical CPU speed is a recipe which could lead to disaster in the future, mainly because of how reluctant some companies are to change existing systems once they are in place. The concept actually makes sense, but it kind of assumes that the strength of the security will be increased at the same rate of which technology progresses, which I don’t think will always be the case. This is especially true when you consider potential “bursts” in computation speed progression. That being said, I’m not implying that I have a better idea. Running algorithms that take 30 seconds to execute isn’t going to work for logging into your Twitter account either.
- tracker1 10y ago
  Depends on how you design your password system... once upgraded a password system by putting a marker with the pwd for newer encoding... this way it can be upgraded as users login.. after n% of users have rolled to the new system, or x days, you can disable the other accounts and require they reset/recover their password for use.

nilved 10y ago

But 1 second of CPU time on your Web server is a lot different than 1 second of CPU time on a supercomputer.

nathan-wall 10y ago
Or 1 second of GPU time. Or 1 second of time running on an ASIC.

DasIch 10y ago

Chances are that you can't afford the most modern hardware. An attacker at least temporarily can probably afford more than you can. If you configure bcrypt so that an attacker spends 1s, it will be to slow to be practical for you.

sokoloff 10y ago
Yes, but even if you allow it to only take 1ms per check for an attacker, it's still practical for you and will take an attacker 4 minutes per account to check all of /usr/share/dict/words (to say nothing of the "add a 1 or a ! at the end"), so long as you are using random per-account salt (which bcrypt basically guides you towards). Make it 15ms for an attacker and it becomes an hour per account just for the dictionary.
- DasIch 10y ago
  True but in reality an attacker won't just use any dictionary. They look at password leaks, figure out what passwords people are actually using and what the most popular ones are. You also can't assume that all accounts are equally valueable. An attacker might very well prioritize some of them. This doesn't render all of this useless but I think you shouldn't consider even best solutions out there to be anything else than a temporary barrier. It's a good one and you probably will have enough time to change your password after a leak but you really do need to change your password within a week or so.

Unklejoe 10y ago

It seems like implementing a security strength which is a function of the current practical CPU speed is a recipe which could lead to disaster in the future, mainly because of how reluctant some companies are to change existing systems once they are in place. The concept actually makes sense, but it kind of assumes that the strength of the security will be increased at the same rate of which technology progresses, which I don’t think will always be the case. This is especially true when you consider potential “bursts” in computation speed progression. That being said, I’m not implying that I have a better idea. Running algorithms that take 30 seconds to execute isn’t going to work for logging into your Twitter account either.

tracker1 10y ago
Depends on how you design your password system... once upgraded a password system by putting a marker with the pwd for newer encoding... this way it can be upgraded as users login.. after n% of users have rolled to the new system, or x days, you can disable the other accounts and require they reset/recover their password for use.