3 ms·
Yeah, going to Scrypt or Argon2 would mitigate a lot of the GPU-based concerns while still offering reasonable in-browser performance.
by problems 10y ago
Yeah, going to Scrypt or Argon2 would mitigate a lot of the GPU-based concerns while still offering reasonable in-browser performance.
- homakov 10y agoScrypt seems to be performing better in the browser because of 32 bit operations. Argon2 in browser was slow in my tests.
- cyphar 10y agoSlow is good for a password hashing function. :P
- deleted 10y ago[deleted]
- dom0 10y agoNo. 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.
- woliveirajr 10y agoIf 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.
- Quiark 10y agoNo, 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.
- woliveirajr 10y agoDon'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.
- kgreene2 10y agoArgon2 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.
- woliveirajr 10y agoOh, 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...
- Ajedi32 10y agoA 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.