Argon2i cross-platform reference implementation available
https://github.com/P-H-C/phc-winner-argon2
PBKDF2's time is up. Custom ASICs used by bitminers have demonstrated PBKDF2 is all but useless, parallelizing tens of millions of rounds per second without breaking a sweat. Argon2i is the winner and the libraries exist for every platform 1password runs on. What are the plans to move to it?
1Password Version: 7
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:scrypt
Comments
-
You're right, there are better key derivation functions than PBKDF2 available now. When it comes time to roll out our next data format I would love to see us using a memory-hard function like Argon.
0 -
Dave - thanks for the response. Any chance you can provide a timeline though? The vulnerability exists right now, and when it comes to password safes the need for a reasonable amount of forward secrecy raises the urgency. It's already implemented in at least one competitor (Keepass). Alternatively (or in unison), perhaps it's time to accept U2F on top of the master password (optionally?) as a second line of defense?
0 -
Hi @bgrubin. I'm more than a bit of a wonk when it comes to slow hashing, and was fairly actively involved in the password hashing competition that resulted in Argon2. So you've hit upon a topic I like to talk about a lot. The good news is that my plane should be boarding soon, so I have to keep this brief.
Availability of Argon2
Sadly Argon2 is not available for every platform we need unless there is a web-assembly implementation that will run efficiently in all the browsers we support that I'm not yet aware of. The defender needs efficient implementations for the hardware that they have, and I do not believe that that exists in browsers. Remember, we are doing this stuff client-side. This was one of the points made in our Security white paper about our choice.
Also keep in mind that we do have six client platforms, and we would need to introduce the capacity to cope with a new Key Derivation Function (KDF) for all of them before we could start using it for any one. So any will take time.
Diminishing gains from hard hashing
Slow hashing is essential, but it offers diminishing returns. So while we should use the memory and time hardest slow hashes that we can get into our clients without eating up everyone's batteries, we need to recognize that once you have reached a certain point, hardening your slow hashing doesn't increase security much. This is because with slow hashing vs cracking, we don't have the exponential asymmetry that we have with, say, increasing the strength of the master password. I attempted to write about this in Bcrypt is great, but is password cracking “infeasible”?
With, say, a master password, rolling a die and adding a digit 1 through 6 will make cracking efforts six times harder. To achieve the same with our 100,000 PBKDF2 rounds we would need to go to 600,000 PBKDF2 rounds.
This symmetry between attacker and defender also means that just as we are seeing dedicating hardware today for hash cracking, we will see the same develop for memory hard cracking once Argon2 becomes more popular. This is because in this domain the arms race between attacker and defender is largely symmetrical. But with other cryptographic systems it is asymmetrical with an exponential advantage to the defender. With normal cryptographer, every time attackers double their power, we only have to increase keys by a single bit to keep up.
This is why we introduced 2SKD
We understood from the outset that slow hashing (memory hard or not) could never be enough to defend the prime target: The data on our servers. So what we do is client side a user's Master Password is combined with a high entropy client created Secret Key. This makes data stolen from our server completely uncrackable.
Slow hashing and a good Master Password are still needed to protect you if your data is stolen from your device.
Estimating cracking costs.
I'm about to board, but see How strong should your Master Password be? For World Password Day we’d like to know for how we are trying to get a better assessment of actual cracking costs. So far, no one has claimed a prize.
0 -
As a follow up, I have now checked the GitHub repo that @bgrubin pointed to, and am pleased to find that there are a number of JavaScript bindings/implementations. However, they still aren't where we would need them. We need to be able to deliver these in a web-client, and so the linking to a native library (compiled from C++) isn't going to do the job.
But all browser implement a fast (native) PBKDF2 implementation as part of WebCrypto,
0 -
Browser library: https://github.com/antelle/argon2-browser
I'm a local vault user, so I'm not concerned with the protections unique to your cloud offering. The vault data is on a number of devices, all of which are nearly constantly network connected. Prudence dictates you assume those can be obtained by a determined adversary.
Your argument about the symmetry of slow hashing is absolutely true. But you can't have it both ways. You can't pretend that PBKDF2 provides any additional security at all while saying it's not worth moving to a considerably better alternative now that it's hopelessly broken.
I tend to feel that the security my vault is worth the slow hashing, and I'd increase the rounds to 500,000 if I thought it would make a difference, damn my mobile device battery. But unfortunately, it won't, and I can't anyhow. If we didn't have a good alternative (which was true until recently) I certainly wasn't here demanding improvements, because there weren't any feasible improvements to make. But there is a good alternative now, and here I am :)
Last but not least, I think your dollar values are a too low in the password cracking challenge. IF your cost estimate of up to $2,000 is even close to right, you are offering 2x returns but over what time period? 2x returns over a month is great. Over a year it's not bad. But it's certainly not a windfall. The other problem is, you forgot to calculate the risk of losing. I can't assume a 2x ROI if I am competing with 50 other well-armed teams. Unless I can guarantee I'm faster at this than everyone else who might participate, I might only assume I have a 20% chance of winning first prize (if not worse). And second prize only pays me back, I win nothing. So my EV of participating is badly negative. I think you need to think about expected value and the ROI over time and up your prizes if you want to actually motivate anyone.
0 -
Excellent points @bgrubin!
For people using OPVault we are not constrained by web-browser limitations, and so do have more freedom on KDF. Note that OPVault's KDF uses HMAC-SHA512 as the PRF in PBKDF2, and this already makes this hard to optimize for many common cracking setups. So we have more freedom to move to a memory hard KDF. I cannot promise any sort of timeline for this, and we would need to do a lot of experimenting to find appropriate parameters on mobile devices, but it certainly is doable.
Regarding the challenge and prizes, the was to smooth out the time/capital trade-off and aim for an assessment of "total cost over time". Given our uncertainty in our own estimates, we didn't know if there would be results within days or not. We did say that if we don't get results in a month or so, we would consider increasing the prizes. It looks like we will need to. You are correct that turning it into a race, does change the incentives in a way that may discourage participants. Anyway, it looks like we will have to increase prizes, but by how much and when we won't announce until we announce it. (We don't want people to hold back submitting in the hope of an increased prize.)
For people like you, who understand these things, the details of our KDF are not the issue, once we have a hard KDF. You know to pick a good Master Password. That is where you will get the biggest security gain for the effort. And no amount of hardness will help people who pick terrible Master Passwords. So we are really aiming to protect people in the middle. And, yes, moving to a memory hard KDF where we can would be a good thing.
One way that I look at this is that if data is captured from a users system the strength of their Master Password and the hardness of our KDF indicate how much time people have to change the passwords that they have stored in 1Password. Is it weeks, months, decades?
0 -
Hi @jpgoldberg ,
I found this thread after searching the forum for "Argon2", following reading a couple of 1Password vs Dashlane comparisons that mentioned that Dashlane uses Argon2.
Just wondering if there have been any developments regarding this since your last post in June 2018?
0 -
Thank you for asking, @Tezcatlipoca.
There has definitely been progress. Using WASM is no longer just a "theoretical" possibility. We have common code (compiled from Rust) in almost all of our clients, including 1Password X, which is a browser-based client. See our recent blog post, 1Password X 1.17: New brain, new menu, and even more accessible for some background on that.
Great progress
So this means that we are in a better position to not have to depend on what can safely and efficiently run in JavaScript. I should say that "just compile [Rust or whatever] to WASM and use that" is not at all as simple as one might think. It has taken time and quite of bit of learning to get to where we are now.
Not just around the corner
But, I should point out that there are still some obstacles to overcome.
Content Security Policys, wasm, and unsafe-eval
Executing wasm in a browser extension is one thing, executing it in a web-app is another. This has to do with the fact that these and WASM interact differently with respect to CSPs (Content Security Policies). In particular, for a web-app to execute the whole you need to punch in your CSP is a really bad and nasty whole. (
allow: unsafe-eval).We are exploring a number of work-arounds. Some of those are looking promising, but not promising enough for us to promise anything. We are also tracking the very very slow moment in standards processes for CSPs to get where we want them to be. But it is going to take a long time. (I suspect that it will be hard for browsers to implement what is needed, because they probably block
unsafe-evalat a very low level.)Sane parameters for all clients
We need to have the same KDF on every platform, as you need to deriving the same keys no matter which device you are on. A desktop is going to have a lot more memory than phone. So we may have to tune the memory requirements for the most limited device we support. It's not clear that doing so would leave us with much to gain from using a memory-hard KDF, as we'd have to limit that.
There are ways around that problem. We could have each device only compute the "hard" stuff once and then encrypt and store those derived secrets in a way that is appropriate for the specific device. That sort of thing has both security risks and security advantages, but it needs to be worked out on a device by device bases; and it adds yet another layer of complexity.
So, yes. there really has been great progress, but there are still some serious problems to address before we can move away from PBKDF2.
0 -
Thanks, @jpgoldberg :)
0 -
On behalf of jpgoldberg you are very welcome. :) If there is anything else we can do, please don't hesitate to contact us.
Ben
0
