25 ms·

Yeah, what I'm getting at is that those posts don't actually come right out and say your code should be calibrating itself regularly. They talk about selecting

by ntucker 12y ago

Yeah, what I'm getting at is that those posts don't actually come right out and say your code should be calibrating itself regularly. They talk about selecting a work factor by benchmarking your current hardware, but they leave it there, and one might come to the conclusion that once they've measured their hardware, they put "13" in a config file and call it done. I'm advocating for advice like "Don't think about work factors, think about time. Your configuration should be a time value, and when your app starts up, it should compute its own work factor based on this time value." If your code does this, there's no need for rules of thumb like "11 is a good starting point for a bcrypt work factor."

jjarmoc 12y ago
Ohh, okay. I see what you're getting at now. Yah, that does seem like a reasonable design. The implementation wrinkles there are that the hardness params have to be encoded in the digest itself, or otherwise stored alongside it. Since implementations commonly do this anyhow, that doesn't seem likely to pose much problem in practice (if any). The other issues would be details around when to calculate the hardness. On app initialization seems obvious, but you'd have to sample over some period of time to get a representative benchmark. I worry that this could exceed administrator tolerance for how long an app can reasonably take to start up, but this doesn't seem like a show stopper either. Ultimately though, I'm not sure the factors are THAT variable. I mean, you want to reconsider work factors as hardware advances, but I don't think the line is so solid that running a work factor of N versus N+1 will make that much of a practical difference in the span of a few months or even a few years. Still, with the goal of making it as hard as feasible while still being suitably performant in the context of a given system it makes sense.
saurik 12y ago
This doesnt make any sense: the goal of this work factor is to make things slower for the opponent, not my own servers. My estimation of the computational power available to my opponent has nothing to do with how large the web servers I chose to use happen to be.
- ntucker 12y ago
  The recommendation is to make it as slow as you can tolerate, which is based on how fast your web servers are.

by ntucker 12y ago

jjarmoc 12y ago

Ohh, okay. I see what you're getting at now. Yah, that does seem like a reasonable design. The implementation wrinkles there are that the hardness params have to be encoded in the digest itself, or otherwise stored alongside it. Since implementations commonly do this anyhow, that doesn't seem likely to pose much problem in practice (if any). The other issues would be details around when to calculate the hardness. On app initialization seems obvious, but you'd have to sample over some period of time to get a representative benchmark. I worry that this could exceed administrator tolerance for how long an app can reasonably take to start up, but this doesn't seem like a show stopper either. Ultimately though, I'm not sure the factors are THAT variable. I mean, you want to reconsider work factors as hardware advances, but I don't think the line is so solid that running a work factor of N versus N+1 will make that much of a practical difference in the span of a few months or even a few years. Still, with the goal of making it as hard as feasible while still being suitably performant in the context of a given system it makes sense.

saurik 12y ago

This doesnt make any sense: the goal of this work factor is to make things slower for the opponent, not my own servers. My estimation of the computational power available to my opponent has nothing to do with how large the web servers I chose to use happen to be.

ntucker 12y ago
The recommendation is to make it as slow as you can tolerate, which is based on how fast your web servers are.