Feature requests: 2FA and customizable PBKDF2 iterations
Two feature requests:
1) It would be great if there was support for 2 factor authentication using Google Authenticator and the other time-based apps that can scan a QR code. A setting in the team-wide settings page that requires everyone to use 2FA, and allows owner/admin/recovery users to change 2FA devices for team members (in case they lose their phone or whatever).
2) LastPass allows you to set up to 200,000 iterations for PBKDF2. It would be great if you could customize the iterations for your team: just a single number on the team-wide settings page that would apply for every vault in the team. I personally would set 100,000. I believe your default is 10,000.
Thank you.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
I would also like to see options for 2FA, as well as curating them for other users. I would prefer the Authenticator as well as SMS. Or at the very least Authenticator, with a fall over SMS option much like GitHub uses.
0 -
+1. Adding the 30billions characters key when using a new browser is a pain.
Using google auth would be so much easier0 -
If you look at the documentation you will see, why there is no 2FA necessary.
0 -
@random_31731ec7aea care to explain what you gleaned from the documentation that I didn't? Because I, as an admin, can just log in with my username (email) and password.
0 -
1Password for Teams currently defaults to 100,000 PBKDF2 iterations in the browser, combined with SRP-4096 and combined with the Account Key. On the server side we use hardware-based KMS to further encrypt the authentication info before storing it in the database.
0 -
Just call me super paranoid, I just prefer it. Placebo effect, very likely. After some issues with other providers and online databases, I think it will just make peoples minds more at ease.
I have been a 1Password user for years, I trust them implicitly. But I would still prefer the option. Just my 2¢.
0 -
If I've understood the whitepaper correctly, the Account Key makes brute-force attacks against data obtained from the sever (eg. vaults) practically infeasible. This is the classic something-you-have (the key) plus something-you-know (the master password) "two factor" approach to hardening. I am sure this approach is vastly superior to protecting the data with (even a strong) master password alone.
Like others, however, I'd like to see "two factor" implemented using a Google Authenticator style second factor (that is, RFC 6238 ie. TOTP). Why? Because the Account Key is effectively a shared secret, but only a static one. If somebody looking over my shoulder snaps a photo of the key on my screen (or manages to get their hands on a printed copy), then they know the account key's former, present and future values, because it never changes. As such, combine that with, say, a sneakily-obtained recording of me typing my master password, and they have access to my vaults.
On the other hand, if they manage to take a photo of a time-sensitive TOTP access code, it gives them nothing of lasting use, and doesn't compromise the shared secret of the second factor in any way. This is because the secret is used to derive the code in a one-way fashion, and knowing a concrete instance of the code reveals nothing about the secret to the attacker. In this case, an attacker would need physical possession of the TOTP-generating device, plus knowledge of the master password, in order to compromise the vault. This seems strictly better than the alternative, which requires only momentary access to the Access Key and not physical possession of a device. I know that 1Password implements some supplementary protection mechanisms (like emailing account owners about logins from new devices), but those can be implemented in TOTP-protected systems too, so these maintain their competitive advantage here too.
0 -
2FA would be cool for accessing the Web Admin Console.
It would be cool to have 2FA for Webaccess and for first sync with Native APP.But how could you encrypted your data with 2FA ? You can just do the login process with 2FA but when someone gets the raw data after sync then 2FA has no security use anymore.
You cannot encrypt your Data dynamicaly.
0 -
The Account Key feature is unique to 1Password for Teams. It is used to encrypt your data and make sure that it is useless even if someone has direct access to the database.
The TOTP can only be used for authentication (not encryption) with the server app. It does nothing to protect your data if someone has direct access to the database.
I agree that TOTP can still be useful and a lot of users expect to see this feature. @random_31731ec7aea outlined the possible use cases -- access to the Admin Console and enrolling a new device.
0 -
I agree 2FA is nice, but it also only really helps in the least likely of scenarios. I believe it is more likely for the servers to be attacked then for someone to try and take a picture of your account key.
If someone is targeting you or your data i'd hope they would know what they need. i.e. Don't just steal that PC, get his phone too. lol
Plus on most services 2FA devices can be removed. Just one click of an e-mail link and that level of security is out the window.
0 -
I agree 2FA is nice, but it also only really helps in the least likely of scenarios. I believe it is more likely for the servers to be attacked then for someone to try and take a picture of your account key.
@Scuba629: Indeed, and having you authenticate with AgileBits just makes us a gatekeeper and a bigger target for attackers. And this ends up being enforced by policy rather than actual security.
There are definitely advantages to traditional MFA, but it doesn't actually increase the actual security of your data, only the login process. And it can unfortunately also provide a false sense of security, making you think no one can get into your account without your magic dongle, but of course that also makes you the target for attacks — social engineering or otherwise.
It may be that we'll be able to add additional safeguards in the future; but frankly if I have to choose, I prefer to letting my data be the target of attack and have the encryption hardened as much as possible over jumping through more hoops due to dongles (or SMS).
0 -
Hey @Brenty and I want to say thanks. I don't think I made myself clear enough earlier up in the thread. I was only hoping for 2FA for web access etc. More of protecting the admin accounts or a portion thereof.
I would like a way to keep some of the features hidden behind the 2FA say printing, maybe other functions. Like new vault creations. I haven't given it a great deal of thought.
I would rather have my data protected by all the behind the scenes stuff you do. I don't expect it to stop someone in that aspect.
Thanks for reminding me, that what I understand in my head and I intend to convey on my display is not always so easily followable. I'm picky about telling my boy to make his thoughts clear and concise. But clearly today and a few other's I seem to have fallen off that horse.0 -
Hey @Brenty and I want to say thanks. I don't think I made myself clear enough earlier up in the thread. I was only hoping for 2FA for web access etc. More of protecting the admin accounts or a portion thereof.
@thightower: Ah, thanks for clarifying! That's an interesting idea. Just an additional safeguard for administrative access?
I would like a way to keep some of the features hidden behind the 2FA say printing, maybe other functions. Like new vault creations. I haven't given it a great deal of thought.
Well, we can put up some signs that say, "Keep off the grass" to avoid making it easy to do, but ultimately if you can see the data, you can just print screen or save to a PDF anyway. New vault creations, on the other hand, are something we can lock, since they'd be asking permission to store this on the server...which kind of goes back to your first point. Thanks for bringing this up!
And I wouldn't assume the misunderstanding is your doing. We've all got some new things we're working with here to try to communicate. In time I think we'll have a shared lexicon for 1Password for Teams and it will be easier on all sides. :)
0 -
Is there a plan to add two-factor authentication to 1Password for Teams?
Here's my use case. I am planning to setup a shared team for my family's use (i.e., personal). However, from time-to-time, I need to be able to access my personal password accounts while using my employer's computer. I work for a large company. My daughter plans to access her account from school. Both environments are notorious for key logging (benign in my case, possibly malicious in my daughter's case [think: fellow students]).
Anyway, where I'm going with this is that I know our credentials would be compromised. However, without our physical authentication device (probably cell phone), they cannot login to our 1Password accounts and any compromised data will be limited to only whatever occurred during that user's session.
- Do you already have a mechanism in place that covers this use case?
- If not, do you intend to implement two/multi-factor authentication and, if so, when will it be available?
Thanks!
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:two factor0 -
I have merged your topic with the best discussion we (forum members (myself included) and the staff) have had for 2 Factor Authentication request.
If you have any questions feel free to follow up with another posting.
0 -
Thanks, @thightower.
It really doesn't sound like 1Password for Teams is going to work for me then. In the past, I'd worked for a guy that used his network privileges to access a co-worker's personal accounts. He was able to do this because he had captured the login credentials and my co-worker didn't protect his password provider's account with 2FA. I did receive notifications of attempted access to my account but I was safe because I had enabled 2FA (I was using software provided by a competitor of 1Password).
I'll keep an eye out for any future developments with 1Password for Teams.
0 -
I wouldn't say its a solid no. Its still beta and up to discussion. Please stay around and see if the staff have any new comments. They are actually great folks and listen to their users. So you never know they may change things.
0 -
Hi @John L,
In your use case if your network guy only had access to the network traffic, he wouldn't be able to access any of your information. I suspect he used SSLStrip to trick his colleagues, but even if he used a more sophisticated Man-In-The-Middle attack he wouldn't have been able to access your account with the data he collected.
The reason for this is two fold: we use the Secure Remote Password protocol to ensure that your Master Password never leaves your machine, and second, we strengthen your Master Password immensely with the Account Key (a full 128 bits of entropy), which makes brute force attacks infeasible.
Given the badness of your network admin, however, one can imagine them going the extra distance and compromising your machine as well. They could install a key logger or other malicious software, and this is truly evil. Once the machine is compromised, all bets are off. I would personally recommend never doing anything on a compromised machine.
With all that said, to answer your question about adding additional factors, the answer is yes. We will indeed be adding support for additional MultiFactor Authentication methods within 1Password for Teams. This will likely be in the form of a Time-based One Time Password as that seems to be the most popular and best understood.
As for when this will be available, we have some technicalities to sort out first so I'm hesitant to make a guess. My hope is we'll have it available for the official release.
I hope this helps.
Cheers!
0 -
You're very welcome, John. Take care.
0 -
Another vote for real multi-factor AUTHENTICATION for at least the Website using the Google Authenticator / Authy Style (Preferred) or in the 1Password phone apps.
Having the Master password is nice for better encryption / isolation of data on the server. But I feel naked using just things I know to gain access to the literal Keys to the Kingdom.
0 -
Any chance you will support U2F in addition to TOTP? Appears to have broad industry support.
0 -
Hello @EnerJi,
We're going to start with TOTP as it still seems to be the most popular approach by far. The FIDO stuff looks interesting and I know @jpgoldberg has been intrigued by what they're doing so I wouldn't be surprised if we decide to add support for it at some point. In the short term, however, we're mostly focused on finishing the beta process and I think we can live without U2F for the initial release.
Thanks for the vote!
0 -
Nice points all.
Now that we actually do have authentication (when authenticating with the 1Password for Teams server), 2FA makes some sense (in a way that it wouldn't make sense for 1Password on your local device performing no authentication.)
FIDO looks very very interesting. I've seen proposals to "eliminate passwords" come and go for 20 years now. And FIDO looks like the most promising thing I've seen in a long time. But experience has taught me not to get my hopes up. I think we would all like to see FIDO or something like it succeed, but as @dteare said, it is probably the case that we would start with something like TOTP.
0 -
I know that these points have been made in this discussion, but I would like to summarize
PBKDF2 Iterations
- 1Password for Teams uses 100,000 PBKDF2-HMAC-SHA256 iterations.
- 1Password local uses 40,000 (or more) PBKDDF2-HMAC-SHA512.
- Teams uses an Account Key along with PBKDF2 in key derivation
So when comparing the two, we've got two steps forward (more interactions and account keys) and one step backwards (hash algorithm). (The switch from SHA512 to SHA256 was a consequence of there not being sufficiently efficient implementations of SHA512 on all of the platforms that we need.)
Configurability
At the risk of sounding arrogant and paternalistic, I'm going to be arrogant and paternalistic I do not think that most of the people who would use such an option would properly understand the security properties and consequences of increasing the numbers of iteration.
Strength is usually measured in terms of bits. It is exponential. But PBKDF2 iterations add strength only linearity. Suppose you have 50,000 interactions and a password, P. If you add a single randomly chosen digit to P to get PN, you get the same strength effect of going from 50,000 iterations to 166,000 iterations. So for a very large cost in user time and power consumption, you get a security improvement that would be far easier to get another way.
For a bit more on the math of that see the section titles "Doing time, time, time in an exponential rhyme" in Bcrypt is great, but is password cracking “infeasible”?.
The difficulty is that people would simply push configurations to the maximum for no good reason. Our goal is to make it easy for people to behave securely and hard for them to shoot themselves in the foot. We also prefer to avoid adding any configuration option unless there is really a compelling reason to do so. This is why we don't have tons of options in Advanced Preference.
Account Key
If I've understood the whitepaper correctly, the Account Key makes brute-force attacks against data obtained from the sever (eg. vaults) practically infeasible.
Precisely. If the everything stored on our servers was captured, the attacker would not have data which would enable a password cracking attempt. Without the Account Key, the hash data on the server does not serve as a Master Password cracking oracle.
Here is a slide from a recent talk I gave about the role of the Account Key.
The whole point of the Account Key is to make sure that we aren't holding onto anything that can be used by anyone for making guesses at your Master Password.
2FA
With respect to multi-factor authentication, I'm going to just refer people to my previous comment here.
0
