Hacker News Reader

Comment by cletus | Hacker News Reader

I use a password manager myself (as IMHO everyone should). It's not ideal because if your master password gets compromised it's potentially catastrophic in away that any individual getting compromised isn't.

The problem with 1Password 2FA is, I believe, that the 2FA itself is still gated behind your master password, in that if that gets compromised so does your supposed 2FA.

The central idea of 2FA is it's something you know and something you have. If that 1Password master password is the only thing needed to gain access then you don't really have 2FA.

Again, I don't use this feature of 1Paswword so this might not be exactly how it works.

But if so, I'm sympathetic to Google not treating it as 2FA because, well, it isn't.

View on HN

I know 2FA is often described in this way but it's not the way I really use it or how your average person wants to use it IMHO. It's just a second piece of data that is needed to login, which does add significant security. Maybe I just don't oversee anything important enough but I don't actually want my digital security to be dependent on a single piece of hardware ever. Yes, I know about backup codes but where are you going to store those if not 1Password/alternative-manager? So for me I'm perfectly happy to keep my 2FA alongside my password in 1Password.

As for "If that 1Password master password is the only thing needed to gain access then you don't really have 2FA." it's not, unless they get access to a device you have logged into 1Password on in the past (and thus entered your secret key [0]). For me this stays true enough to "something I have". If someone has my phone/computer AND can guess my 1Password master password then things are already pretty bleak and they already have access to whatever other 2FA app I was using (Authy/GA).

Lastly 2FA falls apart if you share an account with a significant other (or a team). In 1Password I can just move that login to a shared vault or share that login individually and everyone can log in and use 2FA. I'm not sure what the alternative would be. Sure, if a product supports multiple accounts or even multiple 2FA's (I don't think I've ever seen the latter, at least in non-enterprise settings) there is a way to do this but most apps/SaaS/etc there isn't an alternative (other than disabling 2FA).

[0] https://support.1password.com/secret-key/

> backup codes but where are you going to store those

On a flash drive/SD card, or even printed out, and then stashed somewhere safe/secure (i.e. not in an unlocked drawer next to your desk)

Yes. I write them in a book. The book lives in a locked desk drawer.

My threat model does not include "Nation state adversary breaks into my home and... reads the contents of the book". If I annoy the Russians enough, presumably they would just try to outright murder me.

In contrast, "Person I annoyed online plans elaborate Internet revenge" is definitely a potential threat I want to cope with, as are "Scam email claiming to be from company I have account with", "Facebook lose everybody's passwords", and so on.

What about the “my house burns down along with all my devices” threat model?

In the event I die, most documents and other material are encrypted and so are now intentionally useless. My accounts are not intended to be "memorialized" or whatever. My net worth cashes out for a handful of people to split up as they choose, or if they can't/won't evenly between them.

If you meant somehow the building burns down and destroys all my possessions but leaves me miraculously alive, I lose access to a bunch of stuff. Nothing to be done about it.

But one of the Security Keys lives in my jeans pocket, so if I survive the fire in the regular way, by fleeing a burning building, I still have that Security Key. If I am wearing trousers. Not so many people actually flee naked, if the fire is going to kill you in the time it takes to pull jeans on you're probably just not making it out at all.

The only use case I've identified for 1Password 2FA is an account that _must_ be a shared login. There are a few business services we use that don't support multiple users on an account.

Our choice is either:

* No 2FA

* Virtual, 1Password 2FA

It's better. But it's not great.

Is there any reason why you couldn't set up the same TOTP authentication on multiple devices?

It's a pain and would require setting it up on nearly every employee's device.

The way I see my password manager, is that its password store in itself is "something I have", while the password to it, is "something I know".

The problem is that “something I have” is generally supposed to imply that it’s a physical object whose functionality cannot be feasibly copied to another object. Some data, especially data stored in the cloud, isn’t really a good candidate, even if it’s protected by a password that only you know.

I disagree. The "have" factor can be soft or hard. It just needs to not be memorable (because then it's guessable, which is a primary weakness of a "know" factor).

For example: if you have an application protected by password+yubikey with "remember device" enabled, after prompting for your password it may decide not to also prompt you for the yubikey, and that can be because a cookie (perhaps ANDed with some other heuristics) is taking its place. A cookie which can be trivially copied to another device, but can't be trivially memorized nor guessed, and is for that reason not a "knowable" thing. If it was considered a "know" factor, then the "remember device" feature would effectively be a "conditionally disable 2FA" feature (two "knows" are 1FA), but it's really not that, outside of describing the interim UX.

I think that a "remember device" feature is a totally orthogonal concept. That's really just another word for a session, and it's quite common for authentication to apply to an entire session rather than to each and every message in a session.

It's true, of course, that once you have created an authenticated session on a device, anyone who has compromised that device (with physical access or a software hack) can likely gain access to that session. But the authentication method still prevents unwanted initiation of sessions, which is the whole point.

Any service provider obviously needs to choose their session policies to match the sensitivity of their service, their own threat models, and the threat models of their clients. So e.g. an online bank probably shouldn't issue cookies that last for a year and are portable across IP addresses. For some services, it could be a good idea for the session to only grant less sensitive access (e.g. only read access), and still require fresh authentication for sensitive actions (e.g. transferring money).

I avoided using my password manager's 2fa for quite some time for the same argumentation...

But when I realised the 'something you have' is the password manager (actually, the data store) itself, and the 'thing I know' is my master password (and not the individual site's password) I've started using it for 2fa. I can still see how the subscription version of 1password stretches that definition though (because you don't actively have unique ownership of the data itself), which is why I use keepass now.

Just like a dongle, your pc is not immune to evil maid if left unattended. My threat model isn't inclusive of that (my threats come from the internet - I live rurally).

Requiring your phone for 2fa (google auth or sms 2fa or other) isn't a panacea either, especially if that's the device you're logging in with.

I wish Google would allow setting 2fa without a phone number...

> the 'something you have' is the password manager

The problem is, assuming your master password is unique (I hope so!), all of the likely vectors for exposing it also expose the database, even if it's only kept locally. Having the database only stored in one place is also quite inconvenient, of course, and any sync mechanism adds even more opportunities for it to be exposed.

My computer could very easily have a zero-day vulnerability get exploited. So could my phone. Either one would expose anything I do on it (for example: access my password database using my master password).

(My solution to this is to use a security key for as much as I can. If you're not concerned about this risk, great, but it definitely is a threat.)

> The central idea of 2FA is it's something you know and something you have. If that 1Password master password is the only thing needed to gain access then you don't really have 2FA.

Well, this is not exactly true. You need to know the master password, and you need to have the device that has the 1Password database on it. Even with the knowledge of the master password, you can't login into your $random_website account from my laptop. So even without the additional one-time 2FA codes, using a password manager that has a master password and doesn't synchronize its database, de-facto, _is_ a form of 2FA. Yes I understand that this view is controversial and that auditors will disagree.

1. 1Password requires a secret key[1] in addition to the master password to gain access on a new device - specifically to protect against weak/reused/leaked master passwords

2. You can add 2FA (well, technically 3FA if you need the secret key, master password, AND a rotating token) to your 1Password signin as well (I auth Authy for that purpose)

[1] https://support.1password.com/secret-key/

By implementing #1 and #2 seems like you would still have a layer of protection even if your master password get key-logged.

The second factor for login to 1Password (or other password managers) protects you from people logging into your account officially, but not from vulnerabilities or inside action of the vendor.

1Password also seems able to bypass the secret key ("If you still can’t find your Secret Key, contact 1Password Support.") which means social engineering, phishing, and/or credential stuffing attacks are viable.

Totally agree, it’s crazy to have your 2FA and password manager be the same application. You can actually disable 1Password’s 2FA and tie a different 2FA. I’m not sure if it’s just a business/teams feature, but we are able to require everyone at the company install and use Duo as their primary 2FA as part of their 1Password activation.

> It's not ideal because if your master password gets compromised it's potentially catastrophic in away that any individual getting compromised isn't.

If you care about this, consider security through compartmentalization provided by Qubes OS. I store my passwords in plain text in an offline VM (with hardware virtualization).

There are vulnerabilities disclosed in VMs and containers almost weekly.

None of which affect VT-d hardware virtualization in a meaningful way [0].

[0] https://www.qubes-os.org/security/xsa/

A password manager itself should be protected with 2FA already. Especially in terms of 1Password since you mentioned it, you need to have both master password and private key to decrypt a vault. It is a pretty strong 2FA as long as you know how to protect the private key.

Granted that if you put your TOTP seed somewhere else outside the password manager, you technically achieved "3FA"(1Password master password + 1Password private key + TOTP token) and it is more secure. But I don't think putting TOTP seed and password together in the same password manager weakens 2FA?

To login to a website:

- Without a password manager, your 2 factors are account password + account TOTP.

- With 1Password, your 2 factors are 1Password master password + 1Password private key.

somthing you have and something you know. a password can be hacked remotely. something you have is more involved. these are layees if security. some are better than others and there are gimicks like some forms of recovery.

Your example is correct, but your 1Password account can be protected by MFA that's separate from 1Password itself. They also support U2F.

I personally have all my MFA codes in 1Password, but 1Password is protected with my Yubikey. In the unlikely event that a bad actor did acquire my master password, they wouldn't get far unless they also physically had my hardware security key.

Reply on news.ycombinator.com