Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Slow is good for a password hashing function. :P


No. You don't want to use an unnecessarily slow PB-KDF in your daily operations, because that means that the ratio your_speed / attackers_speed is worse.

In other words, you want the KDF that is slowest for an attacker that still completes a KD in, say, 0.5 seconds on your devices.


If it takes 1 sec on my device and 1 year on attackers

versus

If it takes 2 sec on my device and 2 years on attackers

My conclusion

I will spend one second of my life for each login I do, but I'll gain 1 year of security (or the attacker will have to double his power).

Perhaps 5 years to generate, 5 years to break isn't usefull (and the ratio would be terrible).

But keeping the same ratio, or even making it a little worse when it makes the attacker take longer, doesn't seem bad.


No, dom0 is right.

You are spending 2sec computing the result in browser JavaScript. The attacker will throw JS out of the window and spend 0.01sec in hand-optimized C++ or OpenCL code. You gain no security.


Don't get it, would you mind to elaborate?

Because, IMHO, the attacker will always use optimized resources. Be it algorithm, cpu speed, gpu, and so on. If I double the number of interactions, it'll take more or less twice the time. For me or for the attacker. So I'll trade twice my time vs twice his time.

He can reduce his time having more cpu, gpu or finding a better algorithm.


Argon2 is slow in the browser, but isn't an inherently slow algorithm.

In other words, you have two algorithms that will each take 1 year on an attacker's machine. Option A takes 1 second on your machine, Option B takes 2 seconds. Option B isn't any better. In fact, it's worse, because it only compromises user experience and potentially leads people down the path of assuming it's more secure than it is.


Oh, so we're talking about different things (not exactly with you, but in the conversation)

I was thinking about the number of interactions (or any other tunable parameter) in the same algorithm, like Scrypt or bcrypt or PBKDF2.

Of course, you're completely right on your example: change one for another that increases time just in browser doesn't give any gain. It must be harder to the attacker...


A better comparison for this situation would be:

1 second in my browser and 1 year to bruteforce on attacker's server cluster

v.s.

0.5 seconds in my browser and 1 year to bruteforce on attacker's server cluster

or

1 second in my browser and 2 years to bruteforce on attacker's server cluster

The idea is to choose the method that is most efficient for you, because doing so allows you to choose a work factor that makes things harder for the attacker without sacrificing usability.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: