1Password PBKDF2 Iterations?
Re: PBKDF2 Iterations?
In looking over the field of Password Managers, I noticed that several of them tout their number of PBKDF2 iterations, for example, 10,000+ and 24,000. This has spawned several questions…
Q) How many of these does 1Password have/do? 5,000? 10,000? 24,000? More?
Q) I think, if I recall correctly, that the practical number of iterations is constrained by a balance between the time it takes the CPU to do them. If the CPU and # iterations combination takes too long than the Password Manager will be too slow for all practical purposes. This makes me ask, doesn’t 1Password and wouldn’t it be best to query the CPU speed and then do the maximum # iterations that don’t make the Password Manager too slow? As for the objection that handhelds would than be overwhelmed by desktops, could 1Password create a table of the practical CPU speeds of all the devices that it is shared with (e.g. my iMac my MacPro my iPhone my iPad, my Android, my Windows 10 PC, etc.) and choose the number that keeps 1Password on all of the devices close to the same speed?
Q) Why doesn’t 1Password or whoever divide the vault into 2 files which no master password can decipher and then join them only locally obviating the need for more iterations?
1Password Version: multiple
Extension Version: corresponds to each 1Password version
OS Version: multiple Mac OS X 10.6.8 to 10.12
Sync Type: Dropbox
Comments
-
Hi @rrnowell ,
Thanks for taking the time to write in with your excellent questions!
For traditional vaults, 1Password varies the number of PBKDF2 iterations based on machine performance but these days tops out at 100,000. You can read more about that here: https://support.1password.com/defense-against-crackers/
1Password for Families and Teams accounts use 100,000 iterations. We've found that the decrypting performance when using 100,000 is good on mobile and desktop. Also, because of the added strength of the account key, it adds a lot more protection than upping the iteration count beyond that.
The article linked above discusses the advantages of increasing password strength compared to PBKDF2 iteration counts.
I also recommend reading our white paper to see how security works with Families and Teams accounts: https://1password.com/files/1Password for Teams White Paper.pdf
Can you elaborate a bit more on diving the vault into two files? Are you referring to the opvault file stored on Dropbox for sync purposes? In order to be useful 1Password would have to combine them again. If 1Password is able to combine the two parts, an attacker could easily do the same - I'm not sure if splitting the file up into pieces provides additional protection. But if I misunderstood your question, please let us know, and we can reply in more detail.
Cheers,
Kevin0 -
Hi Kevin,
I am talking about dividing the 1Password vault on the Cloud service into multiple files. I thought of what you did... why couldn't the hacker just reassemble them. They could, but with many files with unique randomized names, which only 1Password would know from its writing of the files, the hacker would know which files to join, or how to join them, or the order to join them in to get a file to attack. If 1Password on the local machines alone knew of the files than the strength and security is enhanced. Of course, the 1Password files would have to share the info, but that too could be encrypted. In fact, the files could be disbursed among multiple Cloud services or sharing resources. It was just a thought. In reality it is just adding another layer I suppose. I don't know at what point the complexity of doing this would outweigh any increased security. As far as 1Password's resources, they might be better spent on adding the Linux platform and web browsers like BRAVE and Vivaldi. Still it is another way beyond what is being used today. Thanks for the info on the iterations and taking the time to answer my questions. Thanks too for 1Password!
May God richly bless you and yours,
Robert0 -
Hi Kevin,
It is me again. I just had a thought. If each Master Password had an expiration date and time that was used for part of the decryption and that only the 1Password programs knew by intercommunication between them via files on the sharing resource, wouldn't that allow 1Password to strengthen the weakest of Master passwords... adding say 20160726070816.02 to even a very weak Master password would at least mitigate to a degree the hacking of the Master passwords on a file some hacker got access to. Another way to do this is to have a Master password that you enter the first time you start/use 1Password each day and a second easier Master password that is used during the day. Of course the time period of a Day for the first password could be controlled. These two ideas combined might be helpful and possibly not too difficult to implement? I suppose you could make the fist one required again after a certain number of uses as opposed to just a period of time.
Hopefully these 3 ideas might have some merit or usefulness.
Again, all God's best to you and yours,
Robert
0 -
Hi @rrnowell ,
Thanks for taking the time to write in with those ideas. I don't believe the expiry date is possible, since it would be dynamic data, that would have to be enforced by the app, and not the encryption algorithm. For example, the 1Password app could enforce and update the encrypted data with an expiry date, but an attacker that somehow gained access to the files could make a copy, write their own app that ignores any expiry and decrypts the data regardless of whether the date has passed or not.
But the other ideas are interesting. With all of these, care must be taken with regard to usability, sync, performance, if there are any "secrets" that must be stored, and if those secrets must and can be stored securely, and other factors, and of course, whether they offer significantly improved security over a good Master Password.
Thank you again for writing in. It's great to hear from customers that care about their security and want to help make it better!
Cheers,
Kevin0
