1P PBKDF2 iterations are less than recommended by OWASP. Please do better.
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
OWASP recommends 310,000 iterations since 2021. 1P only have 100k iterations which is just not good enough for a leading password manager.
Bitwarden and LP both allow users to customise iterations.
Even if you guys have secret keys, we shouldn't be so careless or relaxed about not having a well protected master password. You guys need to at least meet the recommended minimum of 310k but even better allows us to go even higher if we wanted to. With computing power these days being very powerful, I could even do 2million and not be slow on my phone.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided
Comments
-
Hi there @strif4
The recommendation from OWASP is working on the basis that only a password is being iterated to derive a key, especially since PBKDF stands for Password-Based Key-Derivation Function, and doesn't take other factors such as the Secret Key into account.
Even a good human-created password will provide about 40 bits of entropy. Adding the Secret Key to that process adds another 128 bits of entropy, which means that those additional iterations of PBKDF2 won't add any more entropy in a meaningful way, and the additional processing required yields only diminishing returns.
Because of this, the recommended 310k rounds of PBKDF2 on a ~40-bit password provides a key of similar strength to our existing 100k rounds on a ~40+128-bit token made up of your account password and Secret Key.
Our Principal Security Architect, Jeff Goldberg, goes into this in a new blog post posted yesterday:
You might also find the blog post Secret Key - What Is It And How Does It Protect Users? helpful in explaining the difference.
Please let me know if you have any questions, or would like any further help. :)
— Grey
0 -
Hi @GreyM1P ,
The article is informative but kind of reinforces my point on several aspects.
“ You still need a good account password
Your Secret Key protects you if your encrypted 1Password data is captured from our servers, but it does not protect you if your encrypted 1Password data is captured from your machines. So you still need a good account password.”A strong master password is still important in many cases. And currently 1Password lags behind even Lastpass which is funny because the article is based on Lastpass.
Yet Lastpass has higher default iterations and also allows users to customize it themselves. I had mine set to 2 million which would make my master password many many times more difficult to crack.
The article highlights exactly why it’s so important we meet at least the minimum recommended industry standards. Because humans make terrible passwords. Quite simply as the article describes, we make bad passwords and hence need to rely on strong kdf encryption settings,
Article writes “Success requires designing for failure”.
1password is not following its own advice. In cases where the secret key fails, the current design of your master password is below industry standards and competitors like Lastpass and bitwarden that have both higher default settings and also allow customizations.
I would actually say people might tend to have weaker master passwords in general on 1P because of the existence of the secret key. It could create a false sense of security compared to other managers that don’t have one. So it’s even more crucial for 1P to have high iterations.
I find the article a little bit hypocritical in that sense. You’re criticising a competitor yet you guys yourselves aren’t even meeting the minimum recommended standards for pbkdf iterations. And that specific competitor will actually be MORE secure than 1P in situations where the secret key fails or is not helpful.
0 -
I'll come to some of your points separately, because I feel it's important to have a full understanding.
A strong master password is still important in many cases.
It always is! And we're under no illusion that the Secret Key is a replacement for a good account password (after all, we advise customers How to choose a good 1Password account password), but a supplement to it.
Yet Lastpass has higher default iterations
Lastpass uses 100,100 rounds, whereas 1Password uses 100,000. A difference of 0.1% in the number of rounds with the default settings won't make much of a difference.
By comparison, adding the Secret Key to the process of deriving the Account Unlock Key, however, has an equivalent effect as adding 2^128 rounds of PBKDF2. Even just adding a random digit to your account password has an equivalent effect as multiplying the number of rounds by a multiple of 10, e.g. from 100k to 1mil.
The article highlights exactly why it’s so important we meet at least the minimum recommended industry standards. Because humans make terrible passwords.
This is precisely what the Secret Key is there to mitigate against. Users who choose poor account passwords are better protected with the Secret Key than without. Having the Secret Key means that there is an absolute minimum 128 bits of entropy (plus whatever entropy is provided by the account password) being used to derive the Account Unlock Key, even with a terrible account password. It's a "seat belt and airbag" or "belt and braces" approach.
Technically proficient users of any service (not just password managers) will choose strong passwords all the time. But, we can't rely on that. The Secret Key strengthens what goes in to the PBKDF2 function so that what comes out is stronger. The number of rounds isn't the only factor in what that function produces.
Ultimately, any cracking of 1Password data would rely on breaking an AES-256 key, which is impossible as it stands today. Any attacks against AES are only hypothetical right now.
In cases where the secret key fails
Could you tell me a bit more about what you mean by this? The Secret Key is a 128-bit randomly-generated key, so it's resistant to dictionary attacks, and the only way to break it would be by brute force, which isn't possible. If someone could break 128-bit keys, secure online connections wouldn't work like they do, since they also use 128-bit keys. How else could you see the Secret Key "failing"?
the current design of your master password is below industry standards and competitors like Lastpass and bitwarden that have both higher default settings and also allow customizations.
We're using 0.1% fewer rounds of PBDKF2 than Lastpass, and 1 (one) fewer round than the client side of Bitwarden's implementation. Bitwarden then performs another 100k rounds on the server side, but 1Password does all key derivation on device, so that's not an equal comparison.
Also, allowing users to customise that setting can backfire, particularly with non-technical users. We don't want a situation where someone well-meaning (but not technically proficient) sets the number of iterations to some very low number but thinks they're secure. In my tests, for example, I was able to set the number of rounds to
1(!) with Lastpass and5000in Bitwarden. If a user wasn't sure what they were doing, they could undermine their own account security in this way.I would actually say people might tend to have weaker master passwords in general on 1P because of the existence of the secret key.
Maybe! But weak passwords happen anyway, with or without a Secret Key, especially for the majority of users who aren't that technical. The Secret Key raises the floor from
0to128bits of entropy, as I mentioned above.I find the article a little bit hypocritical in that sense. You’re criticising a competitor yet you guys yourselves aren’t even meeting the minimum recommended standards for pbkdf iterations.
Iterations aren't the only thing that governs how secure your 1Password data is, and we shouldn't treat that 100k number as some one-size-fits-all solution. If it was, we wouldn't bother with the Secret Key and would just set iterations to some very high number and cross our fingers.
Even if a 1Password customer reused their account password somewhere else (which is, to be clear, a Very Bad Idea™), they definitely haven't reused their Secret Key, so credential stuffing wouldn't work.
Hypothetically, let's say 1Password used
1 millionrounds of PBKDF2, but no Secret Key. In situations where the account password was reused (and as you mentioned, "humans make terrible passwords", which includes reusing them), the number of rounds is pretty irrelevant, since an attacker could just try already-leaked passwords, wait that little bit longer for the function to complete compared to100krounds, and they would be able to generate your Account Unlock Key.However, they're never going to guess the Secret Key, and they're not going to crack it by brute force.
They're not going to crack the resulting AES-256 key which encrypts your data.
Also, that key was seeded by the combination of your account password and Secret Key, so even a bad account password doesn't matter, since the Secret Key is doing much of the heavy lifting.If you'd like to learn more about the 1Password security model, you can do so at either of these links:
I'll be happy to answer any questions you might have about the details in either of those documents, or anything else relating to 1Password's security.
0 -
Hi @GreyM1P ,
The article is informative but kind of reinforces my point on several aspects.
“ You still need a good account password
Your Secret Key protects you if your encrypted 1Password data is captured from our servers, but it does not protect you if your encrypted 1Password data is captured from your machines. So you still need a good account password.”A strong master password is still important in many cases. And currently 1Password lags behind even Lastpass which is funny because the article is based on Lastpass.
Yet Lastpass has higher default iterations and also allows users to customize it themselves. I had mine set to 2 million which would make my master password many many times more difficult to crack.
The article highlights exactly why it’s so important we meet at least the minimum recommended industry standards. Because humans make shit passwords. Quite simply as the article describes, we make bad passwords and hence need to rely on strong kdf encryption settings,
Article writes “Success requires designing for failure”.
1password is not following its own advice. In cases where the secret key fails, the current design of your master password is below industry standards and competitors like Lastpass and bitwarden that have both higher default settings and also allow customizations.
I would actually say people might tend to have weaker master passwords in general on 1P because of the existence of the secret key. It could create a false sense of security compared to other managers that don’t have one. So it’s even more crucial for 1P to have high iterations.
I find the article a little bit hypocritical in that sense. You’re criticising a competitor yet you guys yourselves aren’t even meeting the minimum recommended standards for pbkdf iterations. And that specific competitor will actually be MORE secure than 1P in situations where the secret key fails or is not helpful.
0 -
I don't have anything further to add beyond what we've outlined above and what we posted in this reddit thread, but thank you for taking the time to engage and ask important and engaging questions. I don't have anything specific to announce, but 1Password is not a static product. It will continue to evolve to adapt to the ever-changing security landscape and the threats our customers face.
Ben
0 -
I would personally like to add - please dont use and repeat such misleading statement fragments:
Yet Lastpass has higher default iterations ...
Yet Lastpass has higher default iterations ...
For those of us who have had accounts for years, our "defaults" were 1, 500, or in my case, discovered to my horror during this debacle), 5000. LastPass did nothing reasonable or competent to recommend, advise or upgrade this insecurely low default value. It is entirely unacceptable, as indicated also by @GreyM1P, to expect ordinary users to routinely go fishing for such values, understand the implications of said values, and be accountable for not updating their settings. That the value is 100,100 today (vs, say, 100000) is insignificant and irrelevant, let alone what the value has remained for likely many thousands of users for years.
Furthermore, there is nothing in its UI that encourages a default large, recommended value. its just a dull integer input field, left to uneducated users to find, and guess some appropriate value to use.
0 -
Hi @GreyM1P
It always is! And we're under no illusion that the Secret Key is a replacement for a good account password
Great! We are in agreement. Let's make the master password as strong as it can get by increasing the iterations to at least the minimum recommended by OWASP and even better, make it customizable too. This should be separate to what the secret key achieves or does, they are separate levels of protection and both should be made as strong as possible.
Lastpass uses 100,100 rounds, whereas 1Password uses 100,000. A difference of 0.1% in the number of rounds with the default settings won't make much of a difference.
I agree the difference is barely anything. I think the main competitive advantage is their customization option so now you are comparing 2 million iterations that I used to have to 100,000 on 1password. That makes it exponentially more difficult to crack.
I just found it funny since lastpass has technically higher default settings than 1P that you would critisize them.
This is precisely what the Secret Key is there to mitigate against. Users who choose poor account passwords are better protected with the Secret Key than without.
Which is great. But pbkdf2 iterations also help mitigate against this. So might as well make sure it meets industry standards because secret key doesn't protect in every case.
Could you tell me a bit more about what you mean by this?
The article explains this.
"but it does not protect you if your encrypted 1Password data is captured from your machines. So you still need a good account password.”
I'm assuming the secret key is stored on disk and easily decrypted. If someone stole your computer then the master password is the only thing that is protecting access to the vault.
Also, allowing users to customise that setting can backfire, particularly with non-technical users. We don't want a situation where someone well-meaning (but not technically proficient) sets the number of iterations to some very low number but thinks they're secure.
The option should be in advanced settings, not allow it to go below 310k (or over couple mil) and also have a link to a guide that walks through what it is. Similar to the article that was recently posted.
Iterations aren't the only thing that governs how secure your 1Password data is,
Which is why I like 1password and the secret key. Iterations aren't the only thing but it certainly is 1 factor. And I think as a leading security company, you should aim to have every factor as strong as it can be.
So currently you are not meeting industry standards for iterations because you are relying on secrey keys. But as the article mentioned, the secret key doesn't protect the user against direct attacks.
Hypothetically, let's say 1Password used 1 million rounds of PBKDF2,
I definitely agree with you in situations where the data was hacked from your server that a master password with 2mil iterations is way less safer than than a master password with 100k iterations + secret key.
But in other situations where my data was hacked from my computer, the master password with 2 mil iterations is safer than master password with 100k iterations + secret key.
0 -
Increasing the iterations is not without cost (to the end user). Higher iterations means more computational power is required, which means more drain on batteries and slower performance. We don't plan to increase the PBKDF2 iterations. We are looking into alternative KDF functions beyond PBKDF2, but again I don't have any news to announce here.
When looking at the OWASP recommendation it is important to understand that it is context dependent, and was not written with 1Password (or any system that utilizes something similar to the Secret Key) in mind. We understand what went into those recommendations and decided that given our threat model 100,000 iterations is appropriate.
But in other situations where my data was hacked from my computer, the master password with 2 mil iterations is safer than master password with 100k iterations + secret key.
I think the main competitive advantage is their customization option so now you are comparing 2 million iterations that I used to have to 100,000 on 1password. That makes it exponentially more difficult to crack.
Adding a single random character to your account password would do more for your security than us significantly increasing the PBKDF2 iterations, and would have significantly less impact on performance. There are sharply diminishing returns with such increases, and as such that isn't a path we're planning to pursue. If this is a threat you are concerned about, adding a random character or two to your account password would offer greater protection for less cost.
Ben
0 -
Came here from Googling iterations as a potential user / LastPass refugee.
To be honest the responses sound a bit like the dismissals LastPass was giving prior to their security incidents. Similar to how clearing plain text master passwords and secret keys in client memory for security from same-user memory dumps was dismissed by 1pass support until it became a project every password manager took more seriously and 1PW eventually worked on.
We get it, the security keys are a useful add-on. The fact that they're not an OWASP-defined industry standard best practice but rather a bleeding edge clever process invention 1PW staff gave a conference talk about less than 5 years ago does not fully reassure users.
How much additional cracking time does each character provide versus 10x or 100-400xing the iterations?
Is there a non conflicted independent audit covering the question of whether it is appropriate given your threat model and why to deviate from the OWASP standard?
Why not make it configurable or raise the iterations regularly to keep up with Moore's law? LastPass thought their default iterations were fine over the years but did not uniformly regularly upgrade them, leaving some users vulnerable to a full vault breach
This sort of thing is important to address in detail, higher levels of protection seem prudent given the reduced trust users now feel in vault security. An "it's fine because of other features and UX-wise it would add some time to 0.5% of users' vault opening" response is less assuring than e.g. BitWarden's open GitHub issues and pull requests and yearly independent audits listing the most recent concerns. LastPass thought "Storing URLs unencrypted is fine relative to our product roadmap because". (As an aside among users careful picking password managers the increased focus of 1PW on sales and marketing and enterprise appeal over security improvements combined with a massive private capital raise give some folks vibes of when LastPass turned a bad corner they wished they'd heeded sooner.)
0 -
I agree completely with pn20000736. I was very likely to move to 1password, but now that I've found this thread I've changed my mind and won't be doing so.
I agree with the 1Password members that the gain in security from moving from 100k to the recommended 310k is very negligible, and that having a secret key (which in principle is really just an enforced long randomly generated password) gains much more security than the difference between 310k to 100k.
However, I don't want to move to a password manager (something that is entirely about security), that's reason for not meeting a basic security recommendation is they've decided it doesn't really matter (even if I agree it doesn't matter). The absolute bare minimum for a security based company should be always meeting security recommendations. The only time it shouldn't be is if they have a strong argument for why it's best not to meet the recommendation. That the gain is negligible is not a real argument to not satisfy the bare minimum of meeting recommendations.
0 -
I agree with pn2000736, I was planning to move to 1Password and was just looking up things about it before making that decision.
Until I found this thread I was pretty much certainly going to move to 1Password, however now I am not.I agree completely with the 1Password team that moving from 100k iterations to the recommended 310k iterations would have an entirely negligible improvement in security, and that the secret key (which in principle really is just enforcing that your password is longer randomly generated password so isn't really a way to argue that this recommendation doesn't apply) is a much greater improvement to security than moving to the recommended iterations would be.
However, that the improvement by moving to the recommended iterations is negligible does not matter to me. For a security company I consider meeting security recommendations to be the absolute bare minimum. The only reason you should not be meeting them is if you have a strong argument for why meeting them would be a negative improvement. That you consider the improvement gain by meeting the recommendation to be entirely negligible (which again I agree with) is not a reason to not meet the bare minimum.
I'm particularly put off by the dismissive attitude especially with the 'technically true but really a lie' comments that have been made as an argument to not meet it e.g. "Higher iterations means more computational power is required, which means more drain on batteries and slower performance." this is just such a non-statement. 'more drain on batteries' is... Sure. It'll change from taking up a millionth of your phone's battery once a day to taking up 300 thousandth. This is not a concern of anyone.
Same with slower performance, unless you're using a 20 year old phone you're going from taking up something like a thousandth of a second to a 300th of a second. I am certain the 1Password team knows, this is not something any of their users care about.
These are absolutely not reasons to not meet what I consider the bare minimum of satisfying security standards.
The only reasons I can think that the 1Password team would be trying to dismiss this are either:
1) They genuinely just don't care about meeting security recommendations so long as they think their own standards are good enough.
Or
2) Their codebase is in disarray (or their developers are not competent enough) to the point that meeting security recommendations is too much work for them.Both of these are things that I do not want in a security company, so I will not be moving to 1Password.
0 -
I'll come to some of your points in one reply. Some later points are covered in earlier sections.
We get it, the [Secret Key is] a useful add-on. The fact that they're not an OWASP-defined industry standard best practice but rather a bleeding edge clever process invention 1PW staff gave a conference talk about less than 5 years ago does not fully reassure users.
All of our cryptography is laid out in the 1Password Security Design White Paper for anyone - potential users, current customers, academics, security researchers, and so on - to scrutinise. The crypto on its own won't reassure most users, since they're not looking at it in that depth.
What will reassure customers is that we've never had a breach, we've offered the biggest bug bounty in the industry of USD $1 million for anyone who can break 1Password's security (still unclaimed, by the way), and that all of our security model is in the open. We use industry-standard cryptography. We just happen to use it in novel ways, which anyone can examine and double-check our maths.
How much additional cracking time does each character provide versus 10x or 100-400xing the iterations?
If we assume an ASCII character from this set...
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789
space
!"#$%&'()*+,-./:;?@[]^_`{|}~...hen you're adding one of 96 possible characters. This would give you the same benefit as multiplying the number of rounds by 96.
Is there a non conflicted independent audit covering the question of whether it is appropriate given your threat model and why to deviate from the OWASP standard?
We get regular security audits from outside agencies, and we publish all our results:
☞ Security audits of 1Password
Why not make it configurable or raise the iterations regularly to keep up with Moore's law? LastPass thought their default iterations were fine over the years but did not uniformly regularly upgrade them, leaving some users vulnerable to a full vault breach
Simply put? Because people will get it wrong. As I mentioned above, Lastpass will let you set the number of rounds toa minimum
1, and Bitwarden to5000. That ability to configure the number of rounds clearly doesnt add security in those cases. Sure it might feel more secure if you raise it, but as we saw above, you could just use a longer account password with 100k rounds to achieve better results than the same account password with 310k rounds. Add two ASCII characters to your account password and you've got the same result as multiplying the number of rounds by 96^2 (9,216).By adding the Secret Key to the process, we get the same benefit as multiplying the number of rounds by 2^128.
Honestly, leaning too heavily on number of rounds of PBKDF2 is a red herring. Increasing the entropy of what goes into it, by including the Secret Key, has a much bigger result on the output.
Also, bear in mind that OWASP's recommendations aren't a standard. In fact, as they say, "This cheat sheet provides guidance on the various areas that need to be considered related to storing passwords." (source: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)
We are looking at moving to a different key-derivation function (and have been for a little while), and I don't doubt we will look at the number of rounds that are appropriate for that function. Right now, it's important to note that neither Lastpass or Bitwarden are using the recommended number of rounds for PBKDF2 either, unless a technically competent user knows how to change that value, and, perhaps more importantly, what to change it to. That's not going to be a large proportion of any password manager's userbase.
To be clear, we're not saying "100k rounds are enough", because 100k rounds of just a password would not be enough. What we are saying is that 100k rounds in combination with the Secret Key is enough, for the reasons outlined above and in our White Paper.
- a password is, of course, 100k rounds, and is what is used elsewhere
- your 1Password account password + Secret Key run through 100k rounds of PBDKF2 is equivalent to
3.4 × 10^43rounds of just a password. (100k * 2^128)
None of our outside security audits have ever criticised the number of rounds we use for PBKDF2, since they understand that the Secret Key adds the extra entropy before the rounds are run.
[The Secret Key ...] is just enforcing that your password is longer randomly generated password
It provides a floor below which the input to the key derivation function cannot fall. Without it, the minimum entropy of PBKDF2's input is whatever terrible password the customer might choose. With the Secret Key, the minimum entropy is 128 bits + whatever comes from the account password, even if it only just meets the minimum requirement. It's a "seat belt + airbag" approach.
They genuinely just don't care about meeting security recommendations so long as they think their own standards are good enough.
It's not just us! Our external auditors confirm it, our SOC2 certification says we're good enough, and our $1 million bug bounty bets that we are too.
If 1Password isn't secure, it's worth a million bucks for someone to prove it. No-one's claimed the money yet. For our customers, we can explain why we work differently from others, and we can lay out the whole security model for the whole world to examine. Maybe we're not going to convince everyone. We can only show our working as a way to help people understand what's going on behind the scenes.
I hope that all the above has shown why we take this seriously, and why we've never been breached. If you haven't already, please do examine our White Paper and the summary of our security model. There's so much more to it than the number of iterations used for one function.
And as always, if you'd like any more detail about anything or have any follow-up questions, please do ask. I'll be happy to address them. :)
0 -
Thanks, that is a helpful and reassuring explanation regarding the iterations.
I'm curious, how often are audits of the 1PW system and clients conducted by security teams performed? Just looking for more supporting thoughts around why the broader situation for 1PW is distinct from the early days of LastPass' relaxing of security to feel more comfortable. Lot of us are a bit traumatized from their backups breach / lax and I consistently upgraded security model and having trouble trusting services long-term 😂
0 -
Higher iterations means more computational power is required, which means more drain on batteries and slower performance.
True. You need the right balance between security and usability. But these days computing power has come a long way since pbkdf2 was first introduced, I haven't noticed any difference in speed at 2 million on my devices. Certainly wouldn't be the cases at 310k, I would be curious to know actual numbers on how much more draining it is at 310k vs 100k on average user devices.
(or any system that utilizes something similar to the Secret Key)
I want my master password protected to in case my laptop gets stolen.. :( Secret key doesn't help in that situation as the article mentioned.
Adding a single random character to your account password would do more for your security than us significantly increasing the PBKDF2 iterations, and would have significantly less impact on performance.
Oh I agree just making the password longer is significantly safer. But long master pass + high iterations is safest.
Adding a single randomly chosen lowercase letter to your password adds 4.7 bits of entropy.
Each doubling of PBKDF2 iterations adds 1 bit of entropy. Going from 100k to 2mil adds about 4.3 bits of entropy.
No matter what though, there will always be people out there with bad/average master passwords on 1P. It's just human nature and mostly out of your control. What is in your control are those iterations though.
I just thought you guys would at least meet the minimum recommended standards on this given your history of not trading convenience for security. At least if someone gets their vault hacked, you can say you've done everything you can and protected the user to industry standards. But if you haven't, you are opening yourself up to some kind of blame and criticism.
If I was running 1P, I would sleep safer knowing there's no way they can blame the company for failing to protect users by not meeting minimum industry standards. It's probably a trivial thing to change from 100k to 310k iterations.
If this is a threat you are concerned about, adding a random character or two to your account password would offer greater protection for less cost.
My master pass is already a long one. I think the problem is that this is more relevant for people who don't care about things like this. People who don't really know things like PBKDF2 iterations or in what situations the secret key doesn't help you. The average consumer who insists on using a bad master password and doesn't understand password security will be the ones most at risk of having low number of iterations.
But as you guys exploring new kdf I will just leave it at that. I'm sure it'll be better than pbkdf2 with 310k iterations anyway.
0 -
Refugee from LastPass after nearly a decade of paid subscription here.
I understand 1Password team's stance of secret key making the need of high PBKDF2 iteration "obsolete". But that is true if and only if the threat model only consider data breach from 1Password server.
If one's laptop is lost, both the encrypted blob and secret key will be compromised, and the master password will be the only remaining line of defense. Assuming the master password is of average strength for usability reason, a high iteration would make the difference between crackable and uncrackable.
I believe the 1Password team knows this (how would a developer in a security software miss this?). However, this threat (client losing laptop leading to data leak) would not lead to headlines or PR crises for 1Password as a cloud data leak would. Nor is 1password's proudly unclaimed 1 million dollar bounty relevant since that jackpot would certainly be solely encrypted on the server and not on a client device as in the real world scenario. I wonder how comfortable would it be for 1password team to put the bounty flag on each and every vault of 1password's employee from CEO to developer to customer service agent.
The risk of customer setting inappropriately low iteration and unnecessarily high iteration is also trivial since a hard minimum of 100,000 can be enforced and a warning tip displayed if user set it to say >310,000. And the minimum can be updated as the 1password team see fit with auto reencryption in the background when the user is signed in.
That adding an extra character is a better alternative is also raising the question : Isn't it the password manager's role to maximize security in face of limitation of the human factor? Of course 1password team can and should encourage strong password, but why not act on both front? I am sure many has experienced the difficulties in persuading your colleagues and families to use a strong password.
Battery performance, app responsiveness are trade off for high iteration, but I wonder how significant the impact is. I wonder if 1password team did benchmark the difference and what's the result? Wouldn't it be solved by including a warning when an unknowing user sets an unusually high iteration?
Is 100,000 iteration a one-size-fit-all setting? If I am to save a crypto key or trade secret that worth a million dollar on a mobile device, is 100,000 iteration adequate anymore?
I think it all comes down to how much emphasis do we put to the end user's threat of losing the device. It appears to me the current stance is that it is the users' sole responsibility to have a strong master password and keep the device (hence secret key) safe. And if the users are failing this, it's their fault, not 1password.
These concerns aside, I have to compliment 1password team for making such an excellent piece of software. After studying the security white paper and other security aspect of all major password manager in the market, I found 1password's model is amonst the best and as an added benefit the usability is better than LastPass too. I have just started my 1password family subscription and hope 1password would continue to improve.
0 -
Yes I did mention that the Secret Key is not the panacea for all types of attacks. I think there may be too much reliance on it to the point where the master password is not as well protected as it should be for scenarios where the secret key fails.
I've seen people actually write that for 1P, the master password is not as important and hence you can get away with an easier one.
0 -
The account password needs to be a compromise between security and convenience. If you choose a password too difficult to remember, you risk being locked out. If you write down your password because of that and keep the note near your computer, you severely weaken its security. And if it's too difficult to enter, for example on your mobile, you will stop using the app.
So the password needs to be reasonably secure from being guessed or dictionary brute-forced, but at the same time easy to remember for you and not too difficult to enter. Not as easy as a 4-6 character PIN, but also not some 30 or 40 character monster.
0 -
I agree the Iterations should be increased if possible and the current value being used should be visible. But I don't necessarily agree with the option for users to change them, or more especially if they can downgrade them like you could (in theory) on LastPass below the safe minimum requirement to as low as 1 (you can also downgrade them as a user in Bitwarden too, but only to 5,000 minimum, but that's still very low). With BW you can as a user increase up to 2,000,000 iterations if you want and it would be nice for 1PW to provide some sort of similar choice in the future, to allow users to go higher than the current 1PW default. The recommended level is now about 320,000 IIRC - so allowing for the secret key effect in 1PW ideally you'd probably still want to at least increase it to at least the 225,000 or so range I'd presume, to be extra safe these days?
LP made a total mess of this in general and left their customers wanting by not ensuring all customers were at a certain minimum level and not providing obvious and critical guidance on the setting. 1PW is much better but 100,000 is absolutely the minimum these days...
0 -
I think the 1Password team make a convincing argument that the secret key obviates the need for additional iterations. NONETHELESS, I suggest they provide the option to increase iterations, for the sole reason of satisfying people who don't want to trust the math. (Me, I was raised to trust the math.)
Dear @GreyM1P & @Ben, You're right of course, but look at it this way: There are features the customer needs, and then there are features the customer wants. Sometimes a feature falls 100% into only ONE of those buckets! (Source: I've developed and sold some successful consumer software.)
Offering a setting doesn't mean you think it's important, or even useful, for us to mess with it. (For an iconic example, see an old-gen .xdefaults file.)
My personal top gripes with 1Password are the bad (IMHO) design decisions you've made that I cannot fix with the obvious -- but cruelly missing -- settings. (My top examples: I want to swap the behavior ctrl-enter & enter when searching. And I crave a window border, because white-on-white isn't an accessibility-friendly level of contrast.)
0 -
I think the 1Password team make a convincing argument that the secret key obviates the need for additional iterations. NONETHELESS, I suggest they provide the option to increase iterations, for the sole reason of satisfying people...
Yes a valid reason I think @Netpog; and I definitely think in the interim (easy) visibility of the actual iteration used on an individual vault or account in 1PW would be nice and most reassuring for users. It is visible in 1PW I've learnt, if you want to dig and I think 1PW's integrity is such it's not in doubt here but it is still reassuring to be able to see it. This is especially so given how badly LastPass have botched managing iterations over an incredibly long period of time, as I mused about here: LastPass Iteration Failures: Can you verify the PBKDF2 Iterations used on your 1Password Vault? (and where info is on how to currently view iterations used, from 1PW; on a Mac at least).
0 -
I suggest they provide the option to increase iterations, for the sole reason of satisfying people who don't want to trust the math.
"Trust The Math" is literally Principle 2 in the Security Design White Paper, after "Privacy By Design". If customers don't want to trust the math that "runs" the security of 1Password (for lack of a better word), that's a whole different issue, and one that we might not be able to do much about. We're not going to be able to convince people who already don't trust the math that their data is safe, and adding a control which acts as little more than a placebo doesn't exactly help to reinforce the existing math's trustworthiness.
The narrative of "100k is secure, but if you want you can increase it" would raise the potential question of "why should a user ever need to increase it if it's secure?", which would be a fair question in my view. Imagine having two seat belts per seat in your car and being told you only need to use one to be safe, but you can use two if you want to. You might reasonably ask why the second one is there if the first one is safe enough.
Our position of using 100k rounds in combination with the Secret Key is based on sound math which bears out this decision. We are (and have been) looking at a new key-derivation function for 1Password, and we'll make decisions about how to implement that based on sound math too. This is a process which takes some time and we don't want to rush it. One very important thing which forms part of this process is migrating customers from one function to another in a way that minimises disruption and maximises compatability. As we've seen elsewhere, making changes to your security model and not updating existing users is a bad idea, so great care is needed here to make sure things go smoothly for everyone.
0 -
"Trust The Math" is literally Principle 2 in the Security Design White Paper, after "Privacy By Design".... We're not going to be able to convince people who already don't trust the math that their data is safe...
Our position of using 100k rounds in combination with the Secret Key is based on sound math which bears out this decision. We are (and have been) looking at a new key-derivation function for 1Password, and we'll make decisions about how to implement that based on sound math too. This is a process which takes some time and we don't want to rush it. One very important thing which forms part of this process is migrating customers from one function to another in a way that minimises disruption and maximises compatability. As we've seen elsewhere, making changes to your security model and not updating existing users is a bad idea, so great care is needed here to make sure things go smoothly for everyone.
👍🏻 👍🏻 👍🏻 @GreyM1P
0 -
I think adding this option should be a MUCH lower priority than (say) restoring the reordering feature that was cruelly removed with version 8. Or giving us the option to swap Ctrl+Enter and Enter when searching.
That said....
It's a sad and unjust fact that the manner in which LastPast squandered the community's trust will cause consumers to be more skeptical of 1Password, as well. I've seen this response from otherwise-educated people to whom I'm trying to introduce the very concept of "password vault".
It's also a fact that ""Trust The Math" is literally Principle 2 in the Security Design White Paper" is irrelevant to CONSUMERS, who aren't designing security systems, and who shouldn't have to understand the math, or research the purpose of these iterations and the equivalence of the secret key.
I've tried to explain, but the only thing they've ever internalized, when I've urged clients or family members to embrace 1Password in preference to LastPass, is "Dan says it's more secure."
Your prospective new users (as distinct from the committed & loyal users like me and most of the commentators here) just want to be reassured.
No harm in letting them increase iterations. Windows includes all sorts of settings that are pointless, or even harmful in most environments. But they give warnings, or they bury them deep in the Policy UI or even in the Registry.
An afterthought that this shouldn't carry much weight: but this option might also please the trade press. As I'm sure you know, they can be quick to focus on pointless (even idiotic) quantitative metrics. Its lazy & ignorant, but they do it.
0 -
I'm gonna go out on a limb here and say that providing options for which likely 99%+ of the 1Password audience has no understanding would just be a bad idea. Let the security people do their jobs, and let the customers easily use the software without concern for these mundane, esoteric, and highly difficult concepts. Users who prefer more control and knob fiddling should look elsewhere.
0 -
No harm in letting them increase iterations.
There is, though. There is a performance hit (and thus a battery hit), there are the diminishing returns discussed above, and there is opportunity cost in terms of development resources.
Windows includes all sorts of settings that are pointless, or even harmful in most environments.
As you've alluded, there are plenty of things we'd rather have our engineers focused on vs spending their time building a setting that is "pointless, or even harmful in most environments."
Options can be good, but they are not always good. People should not have to make a choice in order to ensure that their data is protected. It should simply be protected. If an option exists to increase an aspect of security, it follows that there will be some people that will not know about it or understand it and that are therefore not protected by it. 1Password is made for everyone, not just for people that can understand the technical complexities of security. So you can bet that if/when 1Password does make changes here, it will apply to everyone and not just the people that can find a toggle for it.
It's a sad and unjust fact that the manner in which LastPast squandered the community's trust will cause consumers to be more skeptical of 1Password, as well. I've seen this response from otherwise-educated people to whom I'm trying to introduce the very concept of "password vault".
Indeed; and we're working on getting resources out to help differentiate the security aspects of 1Password vs our competitors. One such resource we just published is:
Make the switch to 1Password
Ben
0 -
There is a performance hit (and thus a battery hit)
@Ben I would love to know if you guys actually tested this and have some numbers. Because I personally haven't noticed anything on my PC or iphone with iterations at 2 million.
I just don't think the performance hit is anywhere near close to being significant as you think. 100k to 310k (or even a million) would be inconsequential difference in battery on any modern device. I would guess at most it may reduce battery life by a couple of minutes? Happy to be proven wrong if you have actually tested this out.
there are the diminishing returns discussed above
I would say it's still quite effective until you start hitting 7 figure iterations.
Going from 100,000 iterations to 200,000 doubles the crack time, and so it adds the equivalent of 1 bit to the effective strength.
Going from 100,000 PKDF2 iterations to 1,000,000 PBKDF2 iterations (increasing the iterations 10 times) effectively adds about 3.3 bits of entropy. The attacker needs to work 10 times harder.
These are all significant improvements imo. Sure, making the masterpass longer is more effective but since the dawn of time people like to have crappy passwords (hence the invention of password managers).
0 -
Can't you get more entropy by a 1 character longer password, or using additional character sets (like Latin-1)
0 -
Yes there’s a variety of ways.
Increasing iterations is the easiest without getting consumers to change their ways and it can strengthen every single master password on 1password.
Obviously 1P can’t force everyone to increase/strengthen their master pass.
0 -
After reading this thread (and others) on PBKDF2 iterations, while I already had a strong master password, I've modified that password to further boost its strength. Seems like a prudent thing to do and simple enough.
0
