4 ms·
I completely agree. What makes all of it even worse is that they only use 8192 iterations of PBKDF2, based on their blog post [1]. To counter GPU-based password
by obi1kenobi 10y ago
I completely agree. What makes all of it even worse is that they only use 8192 iterations of PBKDF2, based on their blog post [1]. To counter GPU-based password cracking, 100,000+ iterations are needed as of 5 years ago [2].
[1] https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4 https://blog.lesspass.com/lesspass-how-it-works-dde742dd18a4
[2] http://stackoverflow.com/questions/6054082/recommended-of-iterations-when-using-pbkdf2-sha256 http://stackoverflow.com/questions/6054082/recommended-of-it...
- problems 10y agoYeah, 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...