6 ms·
> it can easily take a second to check a hash On what hardware?
by fit2rule 10y ago
> it can easily take a second to check a hash
On what hardware?
- cm2187 10y agoAn i7 laptop. But even if you use an 18 cores server, it doesn't really change the point. It might take a month instead of a year. But it still doesn't scale, even to only check the most common passwords.
- iagooar 10y agoHow can you say it doesn't scale? You just need to spin up a cluster that is powerful enough to get down to let's say a week. The cost of this would be a joke for a company / institution of a certain size.
- cmdrfred 10y ago1 week only tests 1 password. It would have to run for years to get a decent set of results. I don't see how a company can afford all that hardware and power to do something that is illegal to begin with. How do they monetize it to get a return?
- iagooar 10y agoYou just need to target certain accounts, no need for all.
- iagooar 10y agoAnd don't forget, that every 18 months, the amount of processing power you get for a modest price, doubles.
- nikbackm 10y agoStill?
- marcosdumay 10y agoNot anymore. It's hard to get specific numbers about a trend that just changed. But the double every 18 months is now clearly wrong. We've got a couple of approximately 27 months doubling, but that is past too. My bet is that we won't get a fixed number ever again.
- tracker1 10y agoI'm not sure the fastest per core speed for the last 5 years in CPUs is significantly faster.. more cores, more caches for some operations, but not nearly the growth we used to see.
- cm2187 10y agoWell, I was surprised by these benchmarks: http://www.anandtech.com/show/10404/asrock-deskmini-110-ministx-pc-review/2 http://www.anandtech.com/show/10404/asrock-deskmini-110-mini... When you compare the skull canyon CPU and the i5 6500: http://ark.intel.com/compare/93341,88184 http://ark.intel.com/compare/93341,88184 The i5 has better specs on pretty much any aspect, but the skull canyon does way better in those benchmarks. I am told the impact is the 128MB eDRAM which acts as a L4 cache. So maybe that's the way for computers to become much faster, making everything around the CPU go faster. Integrate the RAM and the GPU on the chip. Superfast SSDs. Etc.
- cmdrfred 10y agoLet's say that were true, so in a year and half you will only have to spend 20 years cracking the passwords? Bcrypt is designed for this exact situation and performs pretty well.
- iagooar 10y agoI am not saying bcrypt is bad. But thruth is, we have to be constantly challenging our assumptions about security and avoid feeling like the battle is "won".
- kalleboo 10y ago> I don't see how a company can afford all that hardware and power to do something that is illegal to begin with. An evildoer would use stolen credentials, stolen credit cards, or stolen hardware (botnets).
- matthewmacleod 10y agoIt does technically scale, just like everything else :) But I think the parent's point was that this compute time only lets you check one password against one account. All you can do, after this compute time, is state that "'monkey' is/ is not the correct password for @iagooar's account". Those results can't be used to check other accounts (because they're salted) so this approach doesn't really scale well at all. It might, for a huge adversary (state-scale) allow a single password to be cracked in a reasonable timeframe, iff it's relatively simple password.
- creshal 10y agohttps://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... 107 kHashes/second/machine for bcrypt in default settings (which probably many sites will use).
- cm2187 10y agoIn the comment at the bottom it says: bcrypt work factor is 5, scrypt work factor is N=1024 r=1, and PBKDF2 rounds are set to 1,000. If they did indeed use a work factor of 5 then this analysis is pretty much meaningless for bcrypt. The default is 10 and I usually use 12 myself.
- adrianmsmith 10y agoWith 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 agoBut 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 agoOr 1 second of GPU time. Or 1 second of time running on an ASIC.
- DasIch 10y agoChances 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 agoYes, 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 agoTrue 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.