Storing OTP together with password diminishes the purpose of 2FA, why not remove this functionality?
maximbaz opened this issue · comments
Having OTP functionality encourages people to use this functionality and store OTP together with password in the single pass file.
However given that OTP codes are mostly used for 2FA, promoting pass-otp sounds like a very bad idea to me: if you password store is compromised, both password and 2FA codes are leaked at the same time.
In browserpass I intentionally try to keep options to a minimum, make good decisions and promote good ways of doing security. And right now promoting OTP functionality via browserpass sounds like a bad idea.
So please, tell me where I'm wrong, why should I keep OTP button?
Don't worry, I'm not removing it right now, but I do want to be convinced with good arguments.
Will try to ping some folks known for use of OTP or love for security, apologies if I missed someone.
@erayd, @qbit, @ashkitten, @apiraino, @vincentbernat, @psliwka, @dustinwilson, @agboom, @duckbrain, @FiloSottile, @fernandoenzo, @532910, @myelsukov
In gopass, there is a blurb in the "features" doc that points out it might be a bad idea: https://github.com/gopasspw/gopass/blob/master/docs/features.md#adding-otp-secrets
It has become fairly standard for password managers to store the otp secrets as well.. Bitwarden, lastpass... etc.
I can't really argue for or against but I feel like the fact that pass / gopass (and others) support otp means it's moot if browserpass does / doesn't. The data will likely be there either way.
I usually see TOTP itself as nearly useless when using randomly generated passwords and a password manager. It's useful against password reuse, but that should not be an issue for a pass user, and it does nothing against phishing.
I suppose it's a reasonable second line of defense against whole-store compromise (say, a UXSS in browserpass, nightmare fuel), so yeah, I would not encourage to store the seeds where they can be reached through the same attack vectors.
Let's be honest, password manager is a huge security risk. It's a master key that opens all your doors. If you lost it, you're practically screwed. So password manager is as secure as your master key. I personally keep my master key on a device (yubikey) which is in a sense the second factor. So yes, if I lost my key and somebody is smart enough to guess the PIN in 3 attempts, then I am totally ruined.
The security is a spectrum. On one end you do not have security at all but have all convenience in the world. On the other end of the spectrum (all credentials are encrypted with individual keys and the one memorizes all those keys) you have absolute security (on your end of the pipe) but no possibility to practically use it. Everyone finds reasonable compromise for themselves :) So to answer Max's original question: OTP button is very convenient to me, I do not consider it a security problem (in my setup) and I don't want the browserpass to lose it :)
I know this is not ideal, but I also store my OTP seeds along with the passwords. Moving OTP on the phone doesn't seem ideal for me. I don't trust my phone much (mostly proprietary stuff, despite the better isolation between applications) and I would have to store the backup codes on my laptop anyway (notably to get a proper backup), most likely in the password store too. A browser compromise would still have to specifically target browserpass to steal the OTP and it is most likely it will try to steal the content of the password field to make it work with a wide range of users. So, 2FA is still a bit more secure than no 2FA in many cases, despite sharing the same storage.
Another benefit of OTP is that secret is never transmitted. If someone is able to intercept the transmission of my password and OTP code, the code can't be used to authenticate again; you need the secret to derive it. So it doesn't protect against the password store being compromised, but does protect against mishandling of the credentials after they are out.
Thanks for the comments guys 🙂
I personally keep my master key on a device (yubikey) which is in a sense the second factor... So to answer Max's original question: OTP button is very convenient to me, I do not consider it a security problem (in my setup) and I don't want the browserpass to lose it :)
Yeah but why do you use OTP if your second factor is Yubikey? If you achieved 2FA with having a pin-protected device that unlocks encrypted passwords stored elsewhere, all what OTP does for you is basically appends 6 digits to your anyway-random password, right?
A browser compromise would still have to specifically target browserpass to steal the OTP and it is most likely it will try to steal the content of the password field to make it work with a wide range of users. So, 2FA is still a bit more secure than no 2FA in many cases, despite sharing the same storage.
Heh, but that's my point exactly! What you call 2FA is not really two-factor, because executing one successful target attack on you is enough to get into your account. I don't want to trick people into believing that they have 2FA when in fact OTP via pass doesn't give them that, it only provides a randomized suffix to their password, which gives only minor benefits when folks already use random passwords.
I feel like the fact that pass / gopass (and others) support otp means it's moot if browserpass does / doesn't. The data will likely be there either way.
This part I'm not really worried about, if users want to keep using pass-otp, they can still use terminal/dmenu/etc. There are many things which are possible via pass but intentionally are not encouraged by browserpass (such as "github.gpg" intentionally not appearing in the popup on https://github.com, only "github.com.gpg").
Another benefit of OTP is that secret is never transmitted. If someone is able to intercept the transmission of my password and OTP code, the code can't be used to authenticate again; you need the secret to derive it. So it doesn't protect against the password store being compromised, but does protect against mishandling of the credentials after they are out.
Valid case for OTP, thanks for mentioning! However the "proper" 2FA has the same benefit plus many more, and as far as I know the vast majority of people are looking for 2FA first and foremost.
Moving OTP on the phone doesn't seem ideal for me. I don't trust my phone much (mostly proprietary stuff, despite the better isolation between applications) and I would have to store the backup codes on my laptop anyway (notably to get a proper backup), most likely in the password store too.
This is a perfect example of why I'm concerned about promoting the use of pass-otp via browserpass, there's a false sense of security in storing everything in password store and I want folks to reconsider such decisions when they stumble upon browserpass and ask "hmm why does it not support pass-otp?".
Storing passwords, OTP codes and backup codes in the single place is a bad idea, because one successful attack means your entire security is breached. Keeping OTP codes on your phone, telling them to your friends or even spraying them on a wall in front of your house is more secure, it's still impossible to get into your account by only knowing OTP codes, however this way an attacker not only needs to breach your password store, but also access your phone / find who you friend is / find where you live.
(please don't take this as a personal attack on you, I only want to share the reasons I think it's not a good general practice, your specific case might differ 🙂)
I personally keep my master key on a device (yubikey) which is in a sense the second factor... So to answer Max's original question: OTP button is very convenient to me, I do not consider it a security problem (in my setup) and I don't want the browserpass to lose it :)
Yeah but why do you use OTP if your second factor is Yubikey? If you achieved 2FA with having a pin-protected device that unlocks encrypted passwords stored elsewhere, all what OTP does for you is basically appends 6 digits to your anyway-random password, right?
Well, not exactly. I meant that I store my private encryption key on the Yubikey, so it's hard to compromise my password store. I do not use Yubikey as a second factor per se. To decrypt my passwords the one needs both: the Yubikey (what I have) and the PIN (what I know). Because of that I decided to store both password and OTP seed in the same file.
If some malicious code has taken over my browser, then I am screwed no matter whether I use browserpass (and/or pass) or not. The only thing bad guy needs to steal my account is either myself or browserpass to type in my user name, password and OTP.
To make browserpass more robust we should avoid loading and decrypting password files, but rather use native pass API to achieve the same functionality. In that case OTP seed would not be exposed neither to the browserpass nor to the browser itself, it would remain contained in the pass which runs in a separate process. But it is the same trade-off between convenience and security. Obviously, calling pass command line API would slow down the browserpass (and the pass must be installed too). On the other hand, if something bad happened it wouldn't be caused by the browserpass :). BTW it's very easy to write a simple pass extension that would return user name, password, site URL and OTP in one call. I had written a simple pass extension: https://github.com/myelsukov/field It can be easily adjusted to return several fields.
Hi,
moving the GPG encryption key onto a Yubikey is a good way to keep key and encrypted content separated.
But how to securely store 2FA secrets on an otherwise unsecure device like a smartphone? Some Yubikeys can interact via NFC with their Authenticator App.
One possible solution (giving up some ease of use) could be to recycle an old Android phone with NFC (or buy a really cheap one), keep it completely offlined and use it only as an OTP generator: have this device talk via NFC with the Yubikey. Like mentioned, 2FA secrets and backup codes offline in a secure storage (example: a LUKS encrypted USB device or printed on paper)
Not having OTP in browserpass would limit its usability to me as mentioned already pretty much every other password manager does it as well. If a service offers 2FA I have it turned on. OTP is already in my password store, so I might as well use it. I know it's less secure, and I might move to putting OTP in a separate password store like gopass suggests in the future. How would browserpass work with that? I don't have a dedicated OTP application on my phone as I use Pass for iOS instead. Like @myelsukov I also use something like a Yubikey which stores my keys.
Some of this discussion is over my head perhaps because I'm just getting up late on a Saturday and reading all of this, but if @myelsukov's suggestion would make browserpass more secure it'd be worthwhile to explore to see how much it slows down the extension. I guess doing so would require getting rid of the OTP webpage overlay, but that's okay. Can click the OTP button and copy to clipboard instead.
moving the GPG encryption key onto a Yubikey is a good way to keep key and encrypted content separated.
But how to securely store 2FA secrets on an otherwise unsecure device like a smartphone? Some Yubikeys can interact via NFC with their Authenticator App.
I have both, NFC based Yubikey and USB-C version. Both can be used on a phone or on a computer. Originally I decided to go with storing OTP secrets on the Yubiky and use their application to generate OTPs. Suddenly I realized that this is extremely insecure and extremely inconvenient.
Security problem:
When you store private keys on a smart card, such as Yubikey, they are PIN protected by the card. The PIN is needed for every decryption operation performed by the smart card. If a wrong PIN is entered three times in a row, the card should delete all content. So if I lost my Yubikey then the finder had just three attempts to guess my pretty long PIN. On the other hand, OTP application is absolutely insecure. In a sense, it's the same as storing OTP secrets unencrypted on a USB drive. Anybody can download Yubico Authenticator, plug in your Yubikey and they have all your OTPs.
Convenience problem:
Yubikey in a sense is a write-only device. There's no way to read data stored on the Yubikey, which means that you still have to have a backup of your OTP secret keys. Storing them on a LUKS partition next to the private keys backup is a pain in the neck because you are supposed to mount your LUKS partition on an air gapped machine only. :)
So after long considerations of possible ways to store OTP secrets: phone, Yubikey, separate file encrypted with a short password (I need to enter it manually, because it does not make sense to use an encryption key stored on the Yubikey, right?) and password store, I decided to proceed with the password store. This is the point where convenience meets security for me :)
If some malicious code has taken over my browser, then I am screwed no matter whether I use
browserpass(and/orpass) or not
Exactly, because in your case you don't have additional authentication steps between password and OTP, there's nothing extra that you "know" or "have" in order to reach OTP codes, so if one or another way someone manages to decrypt your github.com.gpg file in password store, the fact that you have 2FA "enabled" on Github doesn't help you. Browser is not the only vector of attack, by the way, any app on your laptop can be compromised (not only browserpass) and tricked into running gpg process to decrypt your pass file.
To make
browserpassmore robust we should avoid loading and decrypting password files, but rather use nativepassAPI to achieve the same functionality. In that case OTP seed would not be exposed neither to thebrowserpassnor to the browser itself, it would remain contained in the pass which runs in a separate process.
This won't happen, browserpass actually used to rely on pass in the past and it worked terribly for many people, but also not everyone uses pass these days (e.g. there's gopass), I imagine not everyone is using pass-otp extension, and finally in v3 we will allow to keep certain browserpass settings directly in pass files (for example, to enable autoSubmit only for specific websites), and this requires reading full contents of the password entry. Moreover, not exposing OTP seed is only half a problem, even if browserpass never knew the seed, malicious code can still try to force browserpass to request OTP code when an attacker needs it.
But you confirm my concerns, supporting OTP means browserpass not only tricks people into falsely believing that they achieved 2FA, but actually also becomes a sweet target for malicious people because they need to focus on one tiny extension to breach all lines of defense 😞
If a service offers 2FA I have it turned on. OTP is already in my password store, so I might as well use it.
But you don't have it turned on 😞 If your OTP codes lie next to your passwords, this cannot be called 2FA... at best we can say you have "randomized-password-suffix" turned on, but the reason I started this thread is that browserpass (as well as many other password managers, apparently) tricks you that this is 2FA, but it isn't. The example in my answer to the first quote applies here as well.
But how to securely store 2FA secrets on an otherwise unsecure device like a smartphone?
That's a very good question that deserves its own separate discussion, but the only point I want to make here is that storing OTP codes on any authenticator app comparing to storing them in pass already makes your more protected against a random attacker named Dean, because Dean has to not only break into your browser/laptop, but also successfully execute a second attack on your phone.
So, personally I would recommend everyone to migrate away from storing OTP codes in password store, for example switch to any mobile authenticator app with fingerprint lock.
But you don't have it turned on 😞 If your OTP codes lie next to your passwords, this cannot be called 2FA... at best we can say you have "randomized-password-suffix" turned on, but the reason I started this thread is that browserpass (as well as many other password managers, apparently) tricks you that this is 2FA, but it isn't. The example in my answer to the first quote applies here as well.
I completely understand that and have always understood that, but the setting on most of the services calls it "two factor authentication". It is turned on regardless of whether my own personal usage can be construed as 2FA or not. Why I've stored OTP and passwords in the same password store pretty much mirror @myelsukov's, so I don't see a reason to reiterate what they said. Gopass suggests using a separate password store for OTP secrets, and if my other software supported that I'd be gladly doing it that way.
If you want to remove OTP from browserpass then do it. I'll find something else for that.
From my perspective, the user experience design for OTP was designed on the assumption that a separate device is used for OTP, a device physically related to the user.
Admittedly, if your computed is completely compromised you are mostly screwed (MitM, auth cookie reuse, etc.). However OTP still protects you against a password lost without a compromised computer, no one can use it without compromising/stealing the OTP device as well, which is much harder to achieve without a physical attack.
So having the OTP codes with the passwords defeats the purpose.
Also, the variability of the OTP code does not add up to the security of a session, the auth protocols already rely on random numbers for the session keys and the password/OTP code have nothing to do with that.
Sorry for late response. On the one hand you're absolutely right. On the other:
-
OTP data can be store in the separate passwordstore repository. This makes passwordstore+browserpass an otp programm for the second factor (moreover significant more secure than other otp authenticators due to gpg).
-
There are more dangerous things in security like discard (TRIM) and disc encryption (but dm-crypt, cryptsetup and all other parts has this option support), tls and compression, but openvpn has support for it. In both cases there are a big warning (see man cryptsetup and man openvpn). You can't control people,
There are always people, who will write pin on bank cards and will put the second factor together with the first one. You can't control them.
You can't control them.
This is my overall feeling. One could spend the rest of their life trying to protect people from themselves.
My concern is that a good-looking OTP functionality (e.g. with auto-refreshing OTP codes) requires writing and then maintaining quite a lot of code (especially considering that browserpass v3 is being rewritten from scratch, and right now it doesn't contain OTP functionality at all), and I don't feel that this work will be beneficial for the majority of people, and maybe even harmful for some. Thanks to all your feedback I realize now that some of you are well-aware of the existing problems and ways of achieving proper 2FA (like by having a separate password store), but my current feeling is that this is too niche, and out of scope for browserpass.
Thanks again for your comments, at least for me it was quite an interesting discussion and I definitely learned something new!
v3, which has been delayed for so long, is almost ready and I'll open a separate issue for beta-testing in the coming days — it won't contain OTP implementation, sorry. If it's any consolation, the current v2 version will stay available on Github, both v2 and v3 are open source if someone decides to fork, but I imagine there are simpler alternatives for getting OTP, like a dmenu script.
hi, sorry i missed out on this discussion, @maximbaz. for what it's worth, i am strongly on the side of keeping some form of otp functionality in browserpass. i've not actually found the injected popover to be particularly useful, but having the otp copy button in the browserpass dialog seems like a reasonable compromise i'd urge you to consider. wouldn't require any interaction with the page at all, even.
No worries at all!
To be honest, with that button in v2 I've been particularly unhappy, because it's always visible, on all password entries, regardless if you have OTP configured for that entry, and if you use OTP at all (because in order to detect if OTP is present when drawing the popup, it is necessary to decrypt all the visible entries).
No I think it's better to provide no functionality at all and an argumentation in README (even if some disagree with it), than a half-baked solution than nobody is super happy about anyway. I will argue that nobody should use pass-otp without considering drawbacks mentioned in this thread, and when you make a conscious decision to use pass-otp, you will anyway implement a custom solution for yourself that will satisfy your security requirements.
i suppose there's not much room to argue otherwise. i may just end up maintaining my own fork where that feature exists, or even have it disabled by default but hidden behind a preference
Hey guys, please see a follow-up to this discussion in a new thread: Support OTP in Browserpass v3 (#333)
I wanted to add a little thing to the converstation. I decided to move all my OTP secrets on the Yubikey. In this way I have two ways to generate OTP codes:
-
(more secure) Using the Yubico authenticator on an offline spare Android device; The app is unlocked using the NFC proximity feature of the Yubikey
-
(more convenient) From cmd line using ykman (the Yubikey should be inserted and unlocked):
$ ykman oath code $( ykman oath list | grep <my_website> ) | xclip
@apiraino Using a Yubikey for OTP isn't really relevant to browserpass, so we're getting a bit off topic here - but be aware that if you don't have the OTP seeds backed up somewhere, and you lose the Yubikey, you will also lose access to those accounts unless you have some other way of logging in.
my apologies 🙏 I just thought it was the only way I could think to keep them off of browserpass and easily accessible as well. The seeds are obviously backed up elsewhere.
@maximbaz Hi, now that I've lost access to pass-otp in browserpass, I stopped to think about your decision, and I can see where you're coming from. Here's how I see the attack model:
passallows you to keep high entropy passwords, this is good.- If a password is leaked, and you have no OTP, it can be used at any time until you change it.
- If a password is leaked and you do have OTP, the leak is only damaging if it reveals a pattern you may have used in other passwords.
- If a password is stolen, you now rely on the security of your GnuPG password. If it is not hacked, the password is safe.
- If a password is stolen and hacked, and you also have OTP stored alongside it, you've lost both. You don't have 2FA anymore, you have 1FA.
- If a password is stolen or leaked and your OTP generation is locked to a specific device, then they need to have that device. This is 2FA.
So, for convenience, pass-otp creates a scenario where your second factor can be circumvented. It's still 2FA in the leaking case, but degrades to 1FA in the stolen and hacked case.
I think your reasoning is pretty strong, and you've convinced me to switch to using Duo for 2FA, as much as I liked the convenience of generating OTP codes from Emacs and Firefox. :-)