Hacker News Reader

Comment by fit2rule | Hacker News Reader

> it can easily take a second to check a hash

On what hardware?

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.

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

Or 1 second of GPU time. Or 1 second of time running on an ASIC.

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.

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.

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.

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.

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.

An 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.

How 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.

It 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.

1 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?

> 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).

And don't forget, that every 18 months, the amount of processing power you get for a modest price, doubles.

Not 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.

I'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.

Well, I was surprised by these benchmarks: 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 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.

Let'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.

I 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".

Still?

You just need to target certain accounts, no need for all.

https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...

107 kHashes/second/machine for bcrypt in default settings (which probably many sites will use).

In 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.

Reply on news.ycombinator.com