Two-factor auth tokens in 1password & security
Hello, I'd be happy if someone could confirm that I'm thinking correctly about having two-factor tokens in 1password. So let me express my thoughts:
Having the tokens in 1password compared to having them in, say, Google Authenticator on a phone is:
- less secure against attacks directed at the 1password vault itself
- equivalent against attacks directed at physical access to the phone, because although more secure by itself, even if the attackers got access to the tokens in Google Authenticator, they wouldn't have the passwords and tokens themselves are useless (ineffective)
- equivalent against attacks directed at the passwords such as keyloggers or network tapping (ineffective)
Have I missed something? (2) and (3) happens all the time. If I'm not wrong, (1) hasn't happened yet. With a locked vault (this includes breaking to Dropbox), 1password is pretty much theoretically unbreakable. With an unlocked vault, it depends to some degree on the security of the OS and some obfuscation as per keeping the master password in the memory and/or communication between the extension and mini (both iOS and desktop), but is theoretically breakable. Now given that the theoretically possible vectors are extremely difficult to perform, even if someone discovers such an attack, I'm safe if the net worth of my 1password vault doesn't count in millions.
Am I right?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Having the tokens in 1password compared to having them in, say, Google Authenticator on a phone is: less secure against attacks directed at the 1password vault itself
@azag0: I may be misunderstanding, but it sounds like what you're getting at is it feels like putting all of your eggs into one basket. But it is important to note that Google Authenticator isn't secure at all. If someone has access to your phone with the app, they have access to the current TOTP. So if someone gets access to your 1Password vault, they can even more easily access the TOTP in the authenticator app.
With an unlocked vault, it depends to some degree on the security of the OS and some obfuscation as per keeping the master password in the memory and/or communication between the extension and mini (both iOS and desktop), but is theoretically breakable.
1Password doesn't decrypt your data en masse; rather it decrypts only what is needed at any given time. But yes, ultimately anything you can access yourself may be accessible to an attacker who has gained control of your system. You are your own worst enemy.
With a locked vault (this includes breaking to Dropbox), 1password is pretty much theoretically unbreakable.
Pretty much. Again, you will be the weak link here: either due to a bad Master Password, or a guy with a wrench that is able to, well...wrench it from you. Other than that, the only enemy to the security of your 1Password data is the steady march of technology, since probably someday in the far-distant future it will be trivial to brute force AES. The good news is that we'll all be too dead to care.
Let me know what you think! :)
0 -
@brenty: Thanks for a reply. This wasn't really a clear question, more like my musings. And you to some degree confirmed that I'm thinking correctly about this stuff.
As for Google Authenticator, it is true that it doesn't have any security (besides the phone's PIN, which is actually pretty good in iOS, I think). On the other hand, if the attackers get just the 2-auth tokens, they don't have anything, so just having my phone stolen is equivalent with 2-auth both in GA or in 1P. On the other hand if someone really hacks my computer and get's to my 1P, having 2-auth in GA could save me.
As you say, it is impossible for 1P to guard against an attacker with full access to my computer, so pretty much any defense against that is having some part of the security off the computer.
But yes, I realize all these are highly unlikely scenarios.
0 -
As for Google Authenticator, it is true that it doesn't have any security (besides the phone's PIN, which is actually pretty good in iOS, I think).
@azag0: I encourage you to use a passcode rather than a 4-digit PIN, as that greatly increases combinations that would either have to be guessed or brute forced to gain access to your phone.
As you say, it is impossible for 1P to guard against an attacker with full access to my computer, so pretty much any defense against that is having some part of the security off the computer.
That's kind of what I thought you were getting at. It's important to note that it is perhaps likely that you'll generally have your computer and phone in the vicinity of each other. At least, that's the case for me.
But yes, I realize all these are highly unlikely scenarios.
Unlikely, but still important to consider. 'Unlikely' is just a friendlier way of saying 'possible', so it doesn't pay to be lax. Security is a process, and it's clear that you're giving it some serious thought. Don't stop. :)
0 -
@brenty, I wouldn't mind some thoughts about what AgileBits is thinking in this space and its technology roadmap.
Right now, I am conscious of a threat that is more likely than most people are aware. The threat I am concerned about is the trojan. A malign piece of code which doesn't do anything malicious to my computer but is used usually in the second or third phase of a hack where the hacker is trying to gain system level access or have already gained system access and is looking for richer "repositories" for escalated attacks or beyond.
These trojans, due to their nature as being malign and not doing anything malicious from the word go, may pass through antivirus, antimalware and IDP technologies undetected. They will then generally sit on your computer and if possible, capture keystrokes, or anything that might be copied/pasted. Even with a short duration in human terms, a piece of code can extract that password thousands of times before the password cache is cleared.
These threats are currently classified under APT but I think they are not that advanced. Its just that no one knows to look for them because they never allow themselves to be "caught".
Is there any way to offer a second factor to 1Password? It doesn't have to be something I have although thats possibly the easiest path to increasing security (if only a little). I for one, would be happy to buy an RSA token or whatever if thats what it takes.
Is there any thinking beyond this to improve the overall security of the 1Password vault? I for one, don't trust Dropbox entirely.
0 -
@brenty, I wouldn't mind some thoughts about what AgileBits is thinking in this space and its technology roadmap.
@laugher: Understood, but I really, really like working here, so I'm afraid I'm going to have to leave you with a boring "No comment." :blush:
My teammates work really hard to not only make awesome stuff, but also keep it under wraps until it's ready, so I don't want to be the weak link here and spoil everything for everyone. Not to mention that anything I say now may not pan out, and then you'll be disappointed, the team will be mad, and I will look like an idiot. And I can manage that just fine without going out of my way. ;)
Right now, I am conscious of a threat that is more likely than most people are aware. The threat I am concerned about is the trojan.
Is there any way to offer a second factor to 1Password? It doesn't have to be something I have although thats possibly the easiest path to increasing security (if only a little). I for one, would be happy to buy an RSA token or whatever if thats what it takes.No. And no amount of factors or authentications or whathaveyou can protect you if your system has been compromised. To be clear, your Master Password is needed to decrypt your 1Password vault, so simply being infected doesn't put you at risk...so long as you're not doing their work for them by decrypting your data. But at some point you're probably going to access your data, and once someone else owns your machine, they can see everything you do. Nothing can protect you if you essentially grant the attacker access to your data.
They will then generally sit on your computer and if possible, capture keystrokes, or anything that might be copied/pasted. Even with a short duration in human terms, a piece of code can extract that password thousands of times before the password cache is cleared.
Yep. Once your computer is owned by someone else other than you, all bets are off.
And at this point we're essentially talking about antivirus software, which 1Password is not. And probably never will be. That just isn't what it was designed to do. And anyway, no antivirus software can, by definition, protect against zero-day vulnerabilities and other unknown exploits. They can only scan for known malicious code or try to pattern match to 'guess' what unknown code might act in a malicious fashion. And we are intimately familiar with the effectiveness (or lack thereof) of matching algorithms, as 1Password is frequently on the receiving end of false positives and gets flagged as malicious.
Is there any thinking beyond this to improve the overall security of the 1Password vault? I for one, don't trust Dropbox entirely.
You don't have to. That's the whole point of end-to-end encryption. 1Password simply doesn't depend on the sync service to protect your data. 1Password is secure by design, not by chance.
Ultimately when it comes to security, each of us will be either own own greatest asset or biggest liability, since it's up to us to not hand over our sensitive information (or otherwise grant access to it) inadvertently. They will try to trick us into compromising ourselves and our secrets, but we can guard against this by only installing software from known, trusted sources, and being circumspect about who we trust in the first place. But when it comes to your 1Password data, the only person you need to trust is the one with the Master Password. And hopefully that is a short list that includes you alone.
0 -
@brenty - If I have that extra factor that's separate to my computer, would it not protect the vault from the scenario I described? Only through a home invasion or if someone should happen to steal my additional factor (token), know what its for, gain access to my 1Password vault and understand how the vault's data could be broken as a result would my vault be vulnerable.
I would have thought that as I have multiple keyfob tokens lying about because my banks likes to hand them out, it would introduce an additional level of complexity if the hacker only gained access to my computer system.
Or am I missing something?
0 -
@laugher: In our hypothetical scenario, having second factor only helps if the attackers are trying to decrypt your data themselves, as then they will need
1your data,2your Master Password, and3some other token. There are a couple crucial problems that prevent the second factor from saving you:- If they already have access to your device (physical or remote), they can simply lie in wait for you to do their work for them as you yourself access your data. Then they either capture it piece by piece on the fly (likely) or hijack your session and use your data/password/token to decrypt it themselves and get the whole lot (more likely).
- With a second factor, you're effectively dependent on a 3rd party to authenticate you, and possibly tied to a network service to do so (at least some of the time), which is another layer of complexity and possible point of failure.
And with 1Password this is not possible, as it's entirely independent of AgileBits, the internet, and, well...everything, really, except your device(s) where you choose to store and access your vault. For many people (myself included), this is part of 1Password's appeal: "Simple, Convenient Security". :)
0 -
I have been thinking about this ever since 1Password had OTP in the app. I love that its protected, but wonder at times because it's all together. It's nice that it syncs across things, and I shared stuff with my wife, it's in there too on her end in her 1Password app.
Pros and cons about this, but it's nice I have a choice :)
0 -
Pros and cons about this, but it's nice I have a choice :)
@prime: Indeed. I think you hit the nail on the head there. But one benefit of using 1Password for TOTP is that even if it means keeping all of this information in one place, it's a really secure place. Most TOTP apps don't even require a PIN. :unamused:
0 -
Thanks @brenty for your views. They have been helpful.
I would still like to see some form of OTP complementing my vault master password at some stage. I wouldn't necessarily dilute the strength of my master password but it would deter "listeners" on my device as I do not trust;
- firewall/IDP/antivirus/antimalware implementations out there in the corporate world
- iOS, Android or Windows Phone ecosystems to protect my master password being captured (or scavenged from a cache of some sort)
Any additional layers of security to strengthen the security of the vault with more than just a master password would be a welcomed addition.
My apologies to the OP for hijacking the thread for a slightly different topic - TOTP support in 1Password is definitely a great addition to an already fantastic password manager. The topic of OTP in general just triggered my desire to use that to strengthen the security of my own 1Password vault with its own OTP layer.
0 -
Thanks @brenty for your views. They have been helpful.
@laugher: You're welcome! I really enjoy these kinds of discussions, so I appreciate you and the others here sharing your thoughts!
I wouldn't necessarily dilute the strength of my master password but it would deter "listeners" on my device as I do not trust;
Your 1Password data is end-to-end encrypted, so someone wouldn't be able to simply 'listen'. They would have to capture your data as you used it (copying and pasting between apps, for instance), and in that case nothing can protect you, as anything viewable by you will also be viewable by anyone else that 'owns' your device.
OS, Android or Windows Phone ecosystems to protect my master password being captured (or scavenged from a cache of some sort)
This is already happening. I don't know what it's called on Windows or Android, but iOS uses Secure Input for password fields.
I would still like to see some form of OTP complementing my vault master password at some stage.
For this to happen, you'd have to have us storing your data, as a central authority to authenticate you. Your data is only stored on your device, so this isn't something that 1Password can support without a complete shift in its model — which not everyone would be on board with. Having it set up this way also means that someone could theoretically use a man-in-the-middle attack to try to capture your Master Password, so there are pros and cons both ways. If we were to go this route in the future, we'd need to be very careful — and also provide other options for those who prefer 1Password because it's self-contained.
0 -
@brenty - As I indicated in an earlier reply, I'm not worried about my 1Password data from being listened into. I totally get the fact that my individual login, passwords, secret notes, etc are all encrypted on disk until I access them. I'm more worried about someone listening in while I type in my master password to unlock my 1Password vault. Having an extra factor (OTP, as an example) as a part of the process of unlocking my vault would help reduce the risk profile somewhat.
But you did mention something I wasn't aware of; Secure Input for password fields. Is there more information related to this that I can read about on one of the blogs?
I am guessing you are referring to Secure Desktop on Windows. I would love to understand this a little bit better.
Thanks.
0 -
But you did mention something I wasn't aware of; Secure Input for password fields. Is there more information related to this that I can read about on one of the blogs?
@laugher: I am ashamed to admit that I almost said, "No, but that's a fantastic idea!" However, instinct prevailed, and I double-checked and found that we did have a blog post about this last year which I'd forgotten:
Watch what you type: 1Password’s defenses against keystroke loggers
Effectively, Secure Input (OS X) and Secure Desktop (Windows) are different approaches to accomplish the same thing: preventing other processes from intercepting keyboard input. And it's a good read (especially in regard to keyboard loggers and accessibility devices), even a year later. :)
0 -
@brenty - There's a lot of information you pro's have to be on top of so I get it when you might have missed something or forgotten something altogether.
The saying, “Once an attacker has broken into your computer [and obtained root privileges], it is no longer your computer.” is not entirely true if the vault is protected with a master password (which might have been compromised with the attacker taking over) and a second factor. My priority is to protect the vault that has all the other passwords/secrets in it so that second factor still helps or at least gives me time (if I am alerted) to change my master password pronto.
I did notice something which might be a bug in the master password implementation recently. Let me know if I need to report it through official channels but when I changed my master password recently, I needed to reenter the new password on my devices except my iOS and Android devices! The latter mobile devices were still accepting my old master password! This is despite the fact that after unlocking the 1Password vault (connected to Dropbox) on those devices, I did a sync then I exited the Android and iOS versions of those apps and try to go back in using the old master password. If all my records were re-encrypted with the new master password which I assumed would have happened, then why would the old password still be accepted and allow me to look at my secured records? Something to look into especially when this should have been taken care of by the 1Password master password change procedures.
Back on the topic of Secure Input and Secure Desktop. What does AgileBits leverage to do something similar on iOS and Android devices? The blog doesn't go into mobile devices. I'm evaluating the potential risks and vulnerabilities of the master password mechanism across all attack surfaces at the moment and wouldn't mind a blog about the dreaded mobile devices we are all expected to carry around these days.
0 -
The saying, “Once an attacker has broken into your computer [and obtained root privileges], it is no longer your computer.” is not entirely true if the vault is protected with a master password (which might have been compromised with the attacker taking over) and a second factor.
@laugher: The statement is entirely true, so much so that I think it bears repeating: once your computer is compromised, someone else owns it and all of your data therein. I think where we're getting hung up is on this point: the attacker owns your computer and all your data, but not the Master Password, which is (hopefully) stored only in your brain; therefore your computer being compromised means that the attacker has all of your encrypted data, but it does not necessarily give them the means to decrypt it.
My priority is to protect the vault that has all the other passwords/secrets in it so that second factor still helps or at least gives me time (if I am alerted) to change my master password pronto.
Yes...but if someone has your vault and your Master Password to unlock it, they can get whatever they want out of it. In this case, changing the Master Password probably does no good, as they will also likely have access to your backups which are encrypted using the old Master Password. Choose a long, strong, unique Master Password, guard it jealously, and no one will be able to get into your vault until long after its usefulness has expired. There is no need to change it.
I did notice something which might be a bug in the master password implementation recently. Let me know if I need to report it through official channels but when I changed my master password recently, I needed to reenter the new password on my devices except my iOS and Android devices! The latter mobile devices were still accepting my old master password!
This is pretty confusing, but it is by design: since your Master Password is never stored in your vault, it cannot sync along with your data.
This is despite the fact that after unlocking the 1Password vault (connected to Dropbox) on those devices, I did a sync then I exited the Android and iOS versions of those apps and try to go back in using the old master password.
This sounds like something was either not syncing, or there was a delay for some reason. Only the "correct" Master Password will be able to successfully decrypt the data since there's no authentication being done. If you're still having this problem, we'll need to investigate further to see why your data (or part of it) is not syncing.
If all my records were re-encrypted with the new master password which I assumed would have happened, then why would the old password still be accepted and allow me to look at my secured records? Something to look into especially when this should have been taken care of by the 1Password master password change procedures.
Equally confusing, your 1Password data is not encrypted with your Master Password itself. This would take forever, both to re-encrypt everything when you make a change and when adding or accessing data. Rather, the encryption keys are derived from your Master Password using PBKDF2 to strengthen it and slow down brute force attacks, and then the encryption keys are used to encrypt/decrypt your data. Whew. The alternatives would be to not use PBKDF2 to defend against crackers, weakening your data against attacks, or use PBKDF2 and render 1Password virtually unusable in browsers and mobile devices (and probably many computers as well).
Back on the topic of Secure Input and Secure Desktop. What does AgileBits leverage to do something similar on iOS and Android devices? The blog doesn't go into mobile devices. I'm evaluating the potential risks and vulnerabilities of the master password mechanism across all attack surfaces at the moment and wouldn't mind a blog about the dreaded mobile devices we are all expected to carry around these days.
Great questions! This is actually much simpler on iOS and Android: application sandboxing is mandatory on these platforms. Both have the benefit of being built from the ground up to avoid the security nightmares we've all experienced on desktop operating systems, which were simply not developed with security in mind from the start (alas, Windows XP).
So on Android, you have to actually grant apps permissions, or they can't actually do much of anything at all. For example, 1Password for Android fills directly rather than using the clipboard. The same is true for iOS, but of course you can choose to copy data to the clipboard if you wish. And on iOS, well...inter-app interaction is the exception rather than the rule; currently only limited functionality can be shared in the form of app extensions, and these too are sandboxed.
On both Android and iOS you would essentially have to grant an app the ability to log your keystrokes, pwning yourself by installing and using a keylogging keyboard, and even then apps themselves can limit these from being used (in the case of iOS, 3rd party keyboards cannot be used in secure text fields at all).
Honestly, the reason we haven't documented the security of 1Password for iOS and Android more extensively is because this is all inherent to the platforms themselves, and iOS and Android are well-documented. Unlike desktop operating systems, which were designed with a sort of "let's make it work" philosophy and carry a lot of legacy baggage, iOS and Android have been born of the internet age, and share a philosophy of "let's make it secure" as a result. :)
0 -
"Yes...but if someone has your vault and your Master Password to unlock it, they can get whatever they want out of it. In this case, changing the Master Password probably does no good, as they will also likely have access to your backups which are encrypted using the old Master Password."
Forgive me if I am still learning about this but could you not incorporate the security of the master password and add in an OTP passcode as an additional layer of security? I imagine that even if someone has my master password, they will still not be able to get into my vault until they also have the OTP. Or is the OTP limited because it absolutely has to be separate to the vault encryption rather than have it complement it as an additional encryption layer or as an additional salt to hash the vault master password? Either before the master password encrypted layer or after it.
Thanks for the explanation about the master password though. I assumed for a moment the master password was used to encrypt all records.
"This sounds like something was either not syncing, or there was a delay for some reason. Only the "correct" Master Password will be able to successfully decrypt the data since there's no authentication being done. If you're still having this problem, we'll need to investigate further to see why your data (or part of it) is not syncing."
Well...I just popped back into my Android device. I typed in the OLD master password and the 1Password App synced all my recently created records. I am able to see the passwords and secrets of all recently created records that were created AFTER I had changed to the NEW master password. So I don't think there is any corruption. It is just letting me access to my vault and to all my newly created records using the OLD master password.
It looks like the encryption keys derived using PBKDF2 is valid for all my secrets with all my previous master passwords somehow.
Let me know if I need to submit a formal incident ticket.
With regards to iOS and Android sandbox security, does the master password get cached anywhere which will allow it to be sniffed/salvaged off the device?
BTW, how do you quote from my reply? I can't seem to find the feature in the editor!
0 -
@laugher: No need for forgiveness! I'm always happy to answer! I'm only sorry if my previous response was a bit confusing. It's a bit complex, I'm afraid! :blush:
Forgive me if I am still learning about this but could you not incorporate the security of the master password and add in an OTP passcode as an additional layer of security?
This would require AgileBits (or another 3rd party — someone other than you) to be the gatekeepers of your data. Of course, some people are comfortable with this, but many aren't. It's certainly something we can consider in the future, but just understand that this is contrary to the way 1Password currently works.
So I don't think there is any corruption. It is just letting me access to my vault and to all my newly created records using the OLD master password.
This indicates that something hasn't sync'd — perhaps only the encryption keys. It could be that this was saved as a conflict in Dropbox. In any case, the best thing to do would be to use the 1Password Troubleshooting tool to generate a diagnostic report and send it to support+forums at agilebits dot com so we can look at the logs to determine exactly what is happening. Just be sure to include a link to this forum thread and your username in the email so we can 'connect the dots'. We will get to the bottom of this! :)
With regards to iOS and Android sandbox security, does the master password get cached anywhere which will allow it to be sniffed/salvaged off the device?
If you use Touch ID in 1Password for iOS or 1Password for Android's PIN or accessibility features, the OS stores the Master Password (which is always needed to decrypt your data). In both cases, this is protected by your device passcode and encryption (definitely on iOS, and hopefully on Android, depending on the version). No sniffing, unless you've installed a malicious app and are handing over your Master Password to it.
BTW, how do you quote from my reply? I can't seem to find the feature in the editor!
Sorry! It's a bit hidden there if you don't know where to look for it:
Honestly, I had to look myself, because I typically just manually add>at the beginning of the line to quote. :pirate:0 -
@laugher: I apologize that it's taken this long for me to follow up here. Now, you may not have been expecting another followup, but I wanted to take the time to discuss these issues more thoroughly with the Android team to make sure I understood all of this fully to add some more detail here, and also add more of this information to our knowledgebase. Whew! :lol:
Master Password security on Android
The Master Password field is protected, with two limitations:
- OS: If you've rooted the device to bypass sandboxing restrictions, then any other app may be able to capture input.
- Keyboard: If you're using a 3rd party keyboard, it can receive your input, so only use a trusted keyboard.
1Password for Android doesn't store the Master Password in memory. Instead, the decrypted key is obfuscated and stored temporarily in memory. After you enter your Master Password to decrypt it, it stays in memory while 1Password is running so it can be used to decrypt an item when you tap it to view its details. When the app exits, the memory is cleared, so the key is no longer available to decrypt items. Therefore, you'll need to enter your Master Password again to decrypt the key any time the app is launched (as opposed to simply switching back to it when it's already running). This also means that the PIN Code is only accepted after you enter your Master Password and the app remains in the background.
Master Password "syncing" on Android
In regard to the Master Password issue you've encountered, currently 1Password for Android isn't able to sync changes to the encryption keys, which of course are themselves encrypted using your Master Password. So when you make a change there it doesn't sync to propagate to other devices (the encryption keys, mind you, not the actual Master Password, which isn't stored) as it does on other platforms. The solution is to either manually change the Master Password in 1Password for Android itself to match the other devices, or simply reinstall the app and sync the data back over from another device — which will of course include the new encryption keys, encrypted with your new Master Password.
I'm really sorry for the confusion caused by this, and the development team is working to improve this to bring it in line with other platforms in a future update. That way it will work as expected everywhere.
And again, thanks so much for your patience and taking the time to ask the tough questions and provide feedback! :chuffed:
ref: OPA-386
0
