Two factor or not two factor
jpgoldberg
Team Member
This topic is set up for more community discussion of the blog post
http://blog.agilebits.com/2011/09/two-factor-or-not-two-factor/
then can be managed in blog comments. Please do read that blog post before commenting here.
Thanks!
-j
http://blog.agilebits.com/2011/09/two-factor-or-not-two-factor/
then can be managed in blog comments. Please do read that blog post before commenting here.
Thanks!
-j
This discussion has been closed.
Comments
If there's one thing I've learned in my year of research before writing my collection of password posts, it's that nothing is more crucial than finding the best possible balance between convenience and security. So I truly appreciate the challenge for security professionals and password management software companies in trying to strike that optimal balance. However, I think that balance point will be different for different individuals, and that is why some people will require a second factor if they're going to entrust their passwords to a password manager.
Also - in many discussions I've had with people who are unwilling to entrust their passwords to a password manager - the topic of keystroke logging often comes up. There's many ways keystroke logging can happen so logging the master password is a big fear for some. There are other ways that passwords can be stolen as well that aren't covered in the post. Rather than list them all here, I'll refer you to my post which describes the 9 most common methods in detail:
http://www.filterjoe.com/2010/05/14/how-attackers-steal-passwords/
I do understand that two factor authentication is difficult to implement in a simple enough fashion that the added complexity would be worth the incremental extra security benefit. I think Google is on to a good idea with the way they're handling two factor verification for Gmail logins (that require only one factor 30 days before requiring another round of two factor verification). In addition to requiring a second factor only once each 30 days, they also make it possible to enable that second factor to be accessed from more than one device. So for example you could enable it on your Android phone as well as your iPod touch. This addresses some of the concerns you point out in your post.
Google's two factor verification system is not without issues (the worst is some security holes related to applications that are not Google applications), but assuming these issues are worked out over time, this seems like a relatively good way to offer a two-factor option.
Though I don't think two-factor authentication is essential for the average person at this point in time, my guess is that password theft will become more sophisticated over time to the point where two-factor will become strongly recommended a few years from now. So I think this topic is certainly worth thinking about and perhaps Agile can come up with a breakthrough in usability (or perhaps just incrementally improve on Google's first stab at this) that makes adding a second factor relatively painless, avoiding issues you point out in your post.
P.S. minor typo in you post: "I know that computers do get stolen that and . . ." as the last two words in this quote should be swapped.
Team Member
As usual you've done some great thinking about these things. (For those of you who don't know Joe Galton; I a great deal of my thinking about password security has come from conversations with him. Do check out his blog: FilterJoe)
I didn't provide an exhaustive list of how passwords can be captured, and the one that really matters for a discussion of multi factor authentication (MFA) is keystroke loggers. (Note that the way that 1Password inserts passwords should be immune to most browser based keystroke loggers.)
Defeating keystroke loggers on your own computer is a trickier problem. We do have a virtual keyboard in 1Password for Windows, but approaches like that are pretty much a cat and mouse game where the deck is stacked against us. Improved, and specially targeted loggers can get around these counter-measures. Basically, if your machine is so completely compromised, then those sorts of methods only defend against today's loggers, and not ones specifically targeting the tool.
MFA for 1Password master passwords will fall into the same category. A specifically targeted and carefully designed bit of malware would not be defeated by MFA. Where MFA would be useful, if this is a concern, is for site passwords, not for 1Password master passwords. So there is some case for using MFA in combination with a password management system.
MFA is most useful for people who have to use untrusted computers to log on to things. My feeling is to just tell people not to do that. Portable devices are ever more affordable. The place where there might be some real benefit of sort of MFA tool with 1Password is with 1PasswordAnywhere. That is where people are most likely to be using an untrusted computer. But we can't do MFA just in one place. If it's to be turned on for one thing, it needs to be everywhere. That is, the data itself must not be usable without the second factor.
The other case for MFA for logins is when the sites aren't using HTTPS. In this case, I find it unlikely that any site would go through the complexity of setting up MFA system but not use HTTPS.
I am not saying that MFA has no place in addressing the problem with passwords, but it needs to be looked at on a case by case basis. In many cases it. Because of how 1Password handle's access to data, the security benefits of MFA are less than it might initially appear. But thanks for reminding us all about a class of threat that I hadn't mentioned. It needs to be considered in the balance as well.
And thanks for pointing out the typo. I usually try to have our Agile Herald (David Chartier) give these the once over before publishing. (I can't seem to proof read my own writing.) I think he's making a post-publication clean up.
Cheers,
-j
Team Member
So, essentially what you've done is created a bunch of different keys that all open the same lock. There is a much higher probability of a brute force attack being successful when more than one guess is the correct answer. In addition, if any one of the services you generate such a password for has a leak, your account is compromised, regardless of the fact that you would normally have a 2nd factor.
In this instance, I turned MFA off. Thankfully that was an option. I use a password that is more secure than the ones Google was generating, and so my overall security is much improved without MFA in this instance.
This is certainly not to say that all MFA systems are flawed in this way, but this was my experience with Google's.
Because of that issue, I'm using Google MFA in a limited fashion with my Google apps domain. I have 2 admin accounts. One of them is my main account and I don't use the second factor. The other is a second account I almost never use. It's purpose is to regain control of my domain if my main account with administrative rights ever gets hacked. That second one is protected by a second factor.
What I'm doing is clearly is too complicated and convoluted but I'm hopeful that Google can solve this issue at some point so I can just have a second factor on my main admin account as well.
For both Jeff and Ben: I wonder if a more limited form of second factor could be useful for a password manager. For example, if someone hacked into my computer and changed the master password to something else, then I would have no access to my passwords because I don't remember any of my 15 character jumbles - yet this person would have access. It would be nice if certain functions of the password manager were protected by a second factor - functions like:
Changing the master password
Deleting passwords
Dropping master password protection altogether
Etc.
Such a limited form of protection would not be as hard to implement as it wouldn't be as important for it to be available on every possible device.
Just a thought.
As for the issue of application-specific passwords, my initial thought on the matter was the same: I've gone from one good password that lets me in to many passwords that maybe aren't even as good as I'd normally use (and based on the ones I've seen so far, they're not). But there's at least one thing that I think could be done to make it better: set controls for what each password can access. For example, the one I use for Bitlbee can only access Google Chat, the one in Thunderbird can only access my contacts list since I don't use that for email, the one on my phone can only access contacts and calendar, etc. This granularity would at least mean that if someone compromised my Bitlbee installation, all they can do is chat with people on my friends list and not access my email via IMAP. It may even be that they do something like that internally and without presenting it, I haven't tried.
But the other reason I don't think it's as big of a deal for me is that of all of the passwords I might use to access the account, the main one is the one that could be sent from a less-reputable machine. All of the others would only ever be sent via SSL, in a way that wouldn't be keylogged or shoulder surfed. The main login password could be sniffed any of those ways, and so an extra bit of security on it is good in my opinion; nobody's going to sniff my phone syncing calendars, and if they root my phone somehow and get the password out of it they could just as easily slurp down the data that the password protects and save some trouble.
I agree with everything you all have stated, the only thing I would add is I would really like the option to use two factor authenication. I understand not everybody wants that or will use it but having the option to enable MFA is a bonus that some people would appreicate. Maybe its something that could be enabled as a preference in a future release
Team Member
At the moment we don't have plans to add it as an option, but we "never say never". One thing that we've learned is that when you create an option that says it uses a higher level of security, people will select it whether it is right for them or not. Because of the dangers of people losing access to their data through a mishap with two factor authentication, I am not comfortable with putting that option out there.
However, you are not the only one requesting this as an option, and so it isn't something we'd rule out completely. Plus, even though I think it would cause much more harm than good, I do find the idea really cool.
Cheers,
-j
So I guess I'm hoping you will expound on the "I think it would cause much more harm than good" part.
Team Member
Thanks for giving me the chance to clarify this point. My fear is that it would dramatically increase the chances of accidental data lose compared to the marginal security enhancement.
As I wrote in the original piece
Without two factor authentication we can take care to back up your data and reduce the changes of accidental data lose. Every time we get a report from a user about a disk crash with no external back-ups or data wiped through a tool like "CleanMyMac" (again without external backup or syncing), it makes for a very sad day around the "office". It's like when someone has forgotten their master password. There is nothing we can do to help them recover their data.
But with two-factor authentication, the whole point is that there would be no on-disk backup of the second factor. Lose or damage of that second factor wouldn't have the kind of backups that are used elsewhere. So the risk of complete lose or damage of that factor would be substantial and catastrophic. Our whole philosophy is that we want to make it easy for people to behave securely. Providing two-factor auth would make it easy for people to behave insecurely when "data availability" is taken as part of data security (as it should be).
If we could limit the use of two-factor auth to just those users who truly understand the risks and benefits that would be better, but at the risk of sounding arrogant, I think that if people really did understand the risks and benefits, they wouldn't want to do it anyway.
Now there is a third option, but that really would involve us going into a business that we are not aiming for. That is we (or some other trusted third party) could hold a backup of the second factor. So in the event of lose or damage, we could be contacted to provide the backup. In the jargon of the business we would be an "escrow" service. There are enormous difficulties in providing an escrow service. One is that we would need some very secure and elaborate mechanism for people to be able to prove who they are.
So our reasons for not providing simple two-factor auth is because we want to protect users from data loss. It's not that we don't want to code it. (We've got some pretty good ideas of exactly how we would go about it.) But our reasons for not wanting to run a key escrow service is that it would take enormous effort away from what we love doing.
But we are always reassessing the security environment. If the balance of risks shifts in the other direction, we may introduce something like MFA in the future. Nothing is ruled out.
Cheers,
-j
I'll still vote for Agile adding it as an Option, though, with a clearly worded caveat emptor before implementation.
Team Member
Cheers,
-j
Because this isn't a changing key like something like ubikey or an rsa fob, the difficulty in implementing it should be significantly less.
Thoughts?
Just started using 1Password and liking it. Followed this forum discussion regarding the Two Factor model and the concerns re keystroke logging.
Why not just sidestep the issue with a scrambled keypad option that randomly places the letters in the login screen.
You could make it easier by not displaying all keys all the time , just a selection that includes the required ones with a statistically significant additional ones. Sorry I am not a cryptographer or mathematician, just approaching from a layman's perspective.
This approach would be quite low lever but would spoil any potential key loggers efforts
At first blush an onscreen keyboard would seem to be a great solution. However, there a couple things to keep in mind:
1. OS X already provides secure input functionality which helps with keystroke logging in most cases. Password fields throughout the OS benefit from this feature.
2. If there is a key logger on your system, there is nothing preventing it from capturing screenshots each time you click on the onscreen keyboard. It may help in some cases, but is not a panacea.
We'll continue to evaluate features that make 1Password more secure while still remaining safe and convenient. Thanks for letting us know that you are looking for an additional layer beyond the master password entry via the keyboard. It helps us get an idea of the use cases that folks have "in the field" as it were.
On a side note, for all those interested, there is a very interesting article on Wired.com about how a man was hacked and the hack could have been prevented if he used his email-provider's two-factor authentication system: http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/all/
Now, granted, the hack was not at all due to a weak password (he used an alphanumeric), but it is still a good reason to have two-factor on email. Besides, I almost exclusively use email applications which cannot ask for the second verification code, so the two-factor would be mainly for a third-party user who uses the web app. Plus, having a unique random password never hurt anything either
Our existing blog post (for which this is the discussion thread) is useful for understanding the current state of multifactor authentication in 1Password, but it doesn't really address another very important aspect. I'd like to highlight the distinction between an authentication password and a decryption password.
Let me give a simple examples. Suppose you have a file encryption program called [font=courier new,courier,monospace]FileEncryptionProgram.app[/font]. It encrypts a file for you and stores the encrypted file as [font=courier new,courier,monospace]my-secret-diary.asc[/font].
Now the developers of [font=courier new,courier,monospace]FileEncryptionProgram[/font] could implement a form of multifactor authentication before the application would even begin to think about decrypting [font=courier new,courier,monospace]my-secret-diary.asc[/font]. That wouldn't be hard to do on the Mac.
But now imagine what happens if Mallory (an attacker) gets ahold of [font=courier new,courier,monospace]my-secret-diary.asc[/font]. Mallory can take that file off to his secret lair and try to attack the encryption on it. Mallory does not need to launch [font=courier new,courier,monospace]FileEncryptionProgram[/font] at all. Indeed, Mallory would be wise to use his own password guessing program that is built for speed and designed for the format of [font=courier new,courier,monospace]my-secret-diary.asc[/font].
Mallory is trying the decrypt the data. Mallory does not need to authenticate with some particular program or service. This is the case with 1Password data as well. Anyone can write a program that decrypts the data if they can get the master password. The data is protected by the encryption and the design of our data format. An attacker doesn't need to (and typically wouldn't) go through the 1Password application itself. In fact, this is exactly what John the Ripper does, and 1Password protects your data in ways which are appropriate to its design (i.e. PBKDF2 key strengthening).
Classical approaches to MFA won't work for us because unlocking your 1Password data is not about authenticating to some service. So sure we could add an authenticator for using 1Password.app itself, but it wouldn't actually provide any real additional security. It would be just for show.
Instead we would need a key splitting approach, and it would need to work across platforms. We do have ideas of how we could do this, but it would add complexity everywhere, and to every platform. It couldn't just be an option that you use on one platform but not another. (If it were, it would mean that the data could be decrypted without the second factor.)
Again, I'm not saying that we can't do it. (We have some good ideas about how we could.) But I am saying that at the moment we are disinclined to do it for the reasons outlined above and in our blog post. Even if it is made an option, we know that there are people who will sign up to every "more secure" option available to them, even if it is the wrong choice. We've joked about presenting people with a quiz about data security before allowing them to enable such an option, and still with a flashing red sign saying "This is a bad idea. Don't enable this."
Using a second factor in the way that we would have to doesn't just double the chance of getting locked out of your data, it increases those chances dramatically. This is because your 1Password data is backed up in a variety of different ways, with robust checks that it isn't damaged. But your second factor couldn't be backed up and stored with your 1Password data. And indeed, it would typically be stored on some other device (an encrypted USB drive or smartcard). Damage to that would be unrecoverable.
Anyway, thanks for bringing this up. We should do a blog post on the distinction between authentication and encryption passwords sometime. (The distinction is relevant to more than just MFA, it is also why you should only change your Master Password if it is weak. A good Master Password should be for life.)
Cheers,
Consider this scenario:
Your master password for 1password has been compromised. (peak over shoulder, key log, etc.)
You therefore immediately change the password to your 1password.
However, a backup of 1password has been saved to an old disk.
That disk contains passwords protected by your OLD master password.
This means, even though your latest database is safe and secure with a new master password, any of your old backups can be compromised.
Consider those that don't want to use Dropbox yet due to security concerns.
Consider those that have multiple computers.
Consider those that do use Dropbox and had setup multiple computers. What if someone turned off Dropbox on a system where the new master password had not synced yet. Or the Dropbox packrat service where it saves old files.
There are many situations where a 2-factor password that considers these scenarios can be your 1 last defence to your weekly or monthly master password changes.
Some have 2 or 3 or even more rotating physical backups. That means, it will take an entire rotation of backups to change all master passwords.
It would be great to have peace of mind to have some sort of timed lock that protects backups even if you have a master password where you need that extra 'key' such as a 2-factor password to get in.
If there is a way to do this now with existing 1password options that I am not aware of, please let me know.
Otherwise, I'll continue to:
a. not use Dropbox.
b. ensure rotating backups are expedited if master password is changed.
c. delete or secure the backups 1password creates when a master password is changed.
I hope someone at Agile can respond to this scenario.
Thank you.
Assuming your phone is out of commission, you theoretically have no access to 1Password. How do you plan to get into Dropbox without the password for it, even if 2-factor is disabled? This is a problem that has bothered me for a while, regardless of 2-factor authentication.
If 2-factor was enabled on Dropbox, you would need to get another of your devices already authenticated with Dropbox, one of your digital backups of 1PW or the paper backup of key service passwords. Presumably the latter two would both include the 6 digit code you need to turn 2-factor off for Dropbox.
Not sure if that answers your question or not.
However, I have 1 more scenario for you which I hope gets some attention to a vote for 2-step authentication which has greater value than the risks of being locked out of your passwords.
1. Imagine husband/wife or business partners or someone you had shared your master password with (for whatever reason)
2. you either divorce, dissolve, or no longer wish to allow access to your passwords to whoever you shared your password with*
* currently there is no way to give user privileges to your passwords so there are times a shared 1password is needed (again, for whatever reason)
3. with the separation, you decide to change the master password and go your merry way.
However, your spouse, business partner, or that someone that has your OLD password MAY have an installation of your old database.
- old computer
- old hard drive
- disconnected dropbox (during the separation, you changed the dropbox password meaning the other person could have files stored on their computer with dropbox trying to connect but can't due to the password change - therefore, the NEW password had not reached that computer --- let's just suppose the worst scenario and he/she still has a database)
- old backup (time machine, dropbox, etc.)
These are things you may have forgotten or left behind during a separation, company auction, deleted but recovered from hard drive - you can see how one of your backups are somewhere.
These are the things you want to protect with some sort of timer or convenient 2-step authentication.
Yes, this could be sidestepped as well with a worst case scenario.
The option, or even a PAID option for 2-step authentication would be greatly appreciated.
Yes, let us PAY for it. This will solve the average user stumbling upon this feature. A pay wall that users that know why they need it will gladly pay for it.
1. Husband/wife - nasty divorce, your other computer is seized for whatever reason, you immediately change the password hoping dropbox will sync the new password, you delete all traces of the backups on dropbox - BUT - you are only left to hope that a database hadn't been saved somewhere
2. business partners - you had been thrown out of the office, your computer is owned by the company so you cannot get it back, the 1password was of your PERSONAL passwords, you go home, change the passwords etc. - BUT...
3. the other person - you left a computer somewhere and he/she had saved your 1password database for whatever reason, you have a hunch someone has access to your 1password, you decide to change the master password to feel safe - BUT - there is a database out there somewhere, that is being shared, sold, saved etc.
Yes, there are many 'what if' scenarios, but if Agile is talking about the average person, then the average person doesn't know the risk of the rogue backup file when he/she sells their mac on ebay. or the friend that gives away passwords because there is trust etc.
Whether it is a 2-step verification or other, there should be some way to lock people out.
Agile: you should have a good master password
Agile: consider not changing it
Agile: 2-step is too risky
Agile: your database is safe even if it's found
Yes, but the master password is only 1 password away from dozens, 100's, 1000's of passwords you have saved.
You may think this as paranoia, but I'm sure you can think back to the mac you just sold to your friend or any of the scenarios above. I wouldn't want to be in any of these scenarios - but if you are, what can you do?
Edit: currently one solution I have for the above is to change each and every one of the passwords in the latest database. However, this is not (or as) helpful for those that may have saved credit cards, social insurance numbers, or other info that 1password gladly accepts. If there are any other solutions for this type of scenario, please let me know) Aside from this (and a few other wishlist items namely privileges) I am a big fan of 1password. However the latest blog post from Agile warning users to stay away from Dropbox's 2-step authentication seems much too arrogant for me.
The simple solution is to never give your master password to anyone as we recommend.
There are numerous ways to make your data available to a spouse or partner in the untimely event of your death that do not grant them access in the present. We've discussed this previously in another thread — specifically post #19 there.
I agree, never giving out your password is the best and should be the only choice.
I also appreciate the suggestions from the other thread.
I hope Agile will reconsider their stance on 2-step verification or some other kind of authentication that ensures backups are secure.
Even if you don't share your password with anyone else, changing your Master Password in fear that it had been found by someone else (look over shoulder, key log, security camera, etc.) is as weak as your previous password that is connected to your backups that may be somewhere without your knowledge...
I hope I'm not being too paranoid. Agile's recent and persistent insistence against 2-step has really got me thinking and concerned...
Multistep authentication has clear and obvious security benefits. So it is more than natural for people to ask why 1Password doesn’t employ it. We're planning to write a more detailed explanation of our developing thoughts on it, but let's discuss the difference between authentication and decryption.
When you connect to some service, like Dropbox, you or your system has to prove that it really has the rights to log in as you. That process is called “authentication”. It is the process of proving to the Dropbox servers in this case that you are really you. You can do this through a username and password; you can do this through a username, password, and code sent to your phone; you can do this by having a particular “token” stored on your computer. Authentication always involves (at least) two parties talking to each other. One party (the client) is under your control; the other (the server) is under someone else’s control.
1Password, however, involves the 1Password application (under your control) talking to your 1Password data (under your control) on your local disk (again, under your control). This is not an authentication process. So 1Password doesn’t even do one-step authentication. It does no authentication at all. 1Password doesn’t gain its security through an authentication process. Instead the security is through encryption. Your data on your disk is encrypted. To decrypt it you need your 1Password master password.
There are great advantages to this design: Your data and your decryption of it doesn’t require our participation in any way once you have 1Password. Your data is yours. Even if AgileBits were to get abducted by aliens tomorrow, you would still have access to your data since we never store it on our servers.
However, one disadvantage of this design is that the kinds of techniques used for multi-step authentication are entirely inapplicable to 1Password. Those techniques are designed to add requirements to an *authentication* process, but unlocking your 1Password data is not an authentication process at all. Because there is no 1Password "server", there are no (additional) steps we can insist on as part of a (non-existent) login process.
1Password is decrypting data stored locally on your system, it is not authenticating against some service. So in truth, we don't even have 1 factor authentication, as there is no authentication in the first place. So typical approaches to MFA won't work.
However that doesn't mean that it is impossible for us to do something that looks like MFA. There are roughly two approaches (each simpler than PKI). One of them is key splitting. That is the result of processing your Master Password doesn't actually get you a working key to decrypt further, instead that result would need to be XORed with another 128-bit key. So it is simply a case of storing that other "half" of the key on some other device. 1Password would need to be able to read that device, which may be tricky on iOS, but it isn't insoluble.
The other approach would be to move the keyfile. 1Password (on the desktop) has a file called encryptionKey.js. That file contains an encrypted key, which is what gets decrypted by the key derived from your master password. That file (and some backups of it) are part of your 1Password.agilekeychian (which is actually a folder bundle, which looks like a single file on the Mac). It would be possible for us to allow that file (and its backups) to reside on some device or location. Both that file and the Master Password are required to get any further.
We are more inclined to do key splitting rather than having a movable keyfile.
The real technical difficulty is getting this to work on every platform. Again, because this is all about data decryption and not authentication, we can't just implement this on one platform (if it were to be anything other than just for show). So while this isn't insurmountable it means that even the "simple" approaches that I described would be tricky.
But the real reasons that we haven't put in substantial effort in that direction is because for every case where someone reports that their computer or device has been stolen, we get probably a hundred more of "I forgot my Master Password" or "I damaged my data and didn't have usable backups". Our fear is that key splitting or keyfile moving wouldn't just double the rate of people getting locked out, but would increase it much more. The threat of data lose becomes very substantial.
Again, because we aren't running a system that people authenticate against, there is nothing we can do the help people recover their data if they damage a key or forget their Master Passwords.
Now of course we could make it an advanced option with lots of warnings, but we know that people will always dial up security settings to 11 whether it is in their interest or not. Remember that 1Password is a mass market product. It's great that security geeks use and respect it, but we don't want to give our users rope to hang themselves with.
I'm just spelling out why, do date, we have resisted calls for MFA. It's harder to get right for a decryption system than for an authentication system, and we think that it might do more harm than good.
None of this is written in stone. The threat landscape, patterns of usage, and device capabilities change. So while there are no immediate plans add this, we are leaving the door open in the design of our new data format.
Cheers,
I do appreciate your time and effort in writing your response. I have no doubt you've written this countless times in some form or another to others hoping this message becomes more clear - yet posts like mine pop up and sorry for adding to a conversation I'm sure is well more advanced in your hallways.
Key splitting and/or whatever solution is chosen for 1password in the future is very, very welcome. Especially considering the various scenarios above.
However, shy of going completely offline, 1password continues to be my best defence and I have recommended it to all my clients and will continue to do so. Look forward to hearing how this evolves.
Thanks again Khad.
Please do keep an eye on our blog for all the latest news on this and other interesting topics. I always love it when I wake up and there is a new post from Jeff there about Dropbox's two-step verification, "insecurity questions", password cracking, and even specific security updates to the apps themselves.
And thanks so much for your recommendations to others. There is no greater compliment we can receive.
Cheers,
While it does answer my question, it almost defeats the purpose - after all, it is called 1Password, not 1Password+1More.
In this case, enabling two-factor on Dropbox would not be such a bad thing.