Nope.

Keeping my secrets store on someone else's computer is simply not compatible with my threat model.

Yes, they say it is encrypted, and I believe them and believe they're competent.

But competent people write vulnerable code all the time, disastrously bad hires happen (see Unifi), and companies go bad. You can't un-disclose information stored with them, only laboriously invalidate it.

1password has been audited a bazillion times. They're E2EE. They're cheap. Your master passwords aren't stored on their servers. Neither is your key information.

The only thing I pay for is the managed hosting, but in theory it's not much different than anything else properly designed (e.g. bitwarden) aside from the obvious things, such as OSS-ness.

The only relevant CVEs are relatively mild compared to LastPass.

Give them some credit.

> Your master passwords aren't stored on their servers. Neither is your key information.

...and, those are the only things that really matter for an attacker. Encrypted data (assuming reasonably strong encryption) is useless without the key.

Some encrypted data is worthless. Some isn't. Depends on what value it has when down the road the encryption is broken.

If AES being broken is in your personal threat model, you have far more to worry about than passwords.

What if its broken in 10 years? Or in 50 years? Eventually it will be.

I’d wager you could survey 100 cryptographers and at least 90 would say the AES-256 primitive itself will never be practically broken, even by large-scale quantum computers. Related-key attacks aren’t realistic or practical.

Properly encrypted data is worthless unless you intend to get the keys somehow. Breaking industry standard encryption schemes shouldn't be in your threat model.

Happy to give them credit. I just refuse to give them my passwords.

> The only thing I pay for is the managed hosting

Funny, I was happy to pay them until they removed my ability to store it myself.

edit:

> CVEs are relatively mild compared to LastPass

LP is not the relevant comparison. The relevant comparison is an encrypted store on my laptop.

I still use an older version of 1Pass specifically so I can run things locally. Sometimes, I wish I was ignorant to all of this stuff and could just be a plebe out in the wild using all of the convenient software out there. Just take the blue pill and put me back in the matrix. The knowing of all of this stuff just makes life so much more difficult.

Maybe look at BitWarden

Easy thing to suggest. However, in my experience, as soon as I decide to use a program after researching it, take the time to switch over to it, that company will then switch to a cloud based whatever. Here we are again at the same spot different name.

Sometimes the devil you know, you know?

I'm in the same boat. I've used lastpass for years and tried a few alternatives over the time but they fell down when it came to providing access to my "vault" on different systems or architectures. The biggest benefit is lastpass generating and storing random passwords for every site and application without me having to cut and paste a thing, and having it easily accessible.

That said, if their closed-source browser extension is leaking my master password to random websites I'll cut them out of my life tomorrow.

What's your personal threat model? I'm always trying to balance the risk of a party focused on security vs the minimal effort I'm likely to put into it. I don't want to be a story about the guy that lost their password to a wallet or anything else important. I used to be able to reliably remember complex passwords reliably but finding that's no longer the case, now only shorter intermittently used ones based on how often I have to use "reset password".

I’ve decided that besides a password manager, all of my passwords will also have a number at the end, like 8 (simple, easy to append manually in a password field. Now the password manager has to get defeated AND my own small personal salt value will have to be known.

Now we know

Now you know that there is some sort of salt. That isn't helpful to an attacker trying to cryptographically crack a password if they already have the password database.

This is a good idea that's never occurred to me. I guess you could also consider it like having one password for all your accounts, except salted with some random string from your password manager

Will it always be 8? Or will it vary?

Good idea, I would add a yubikey to that, for an additional step.

Agree. Moving from one proprietary online solution to another proprietary online solution isn't the answer.

How do you sync your passwords across all of your machines? Do you self host your passwords on your own server? Do you manually sync?

1Pass has the ability to sync via WiFi, Dropbox, iCloud, etc. I only use the WiFi as the other options are still cloud platforms I don't trust.

These have all been removed in 1password 8. It is cloud-only, subscription-only.

Not OP, but I use the standalone version of 1Password + Resilio Sync.

Your personal infrastructure is likely much more volatile than some Expert company. Unless of course you happen to be an industry expert ...

What if you’re in another country and your devices get stolen? Should you bring the Yubikey to travel? What happens if there’s a fire at your house and the Yubikey is destroyed?

You can add multiple keys to the account.

So is the recommendation to get something like 3 keys and keep them in different safe places and bring one when you travel? I’ve been considering getting a Yubikey. Do they work on mobile?

Edit: Looks like some Yubikey work via nfc for mobile.

Yes, you should always have at least two and keep one in a reasonably fire resistant safe. You may want to enroll multiple and keep them in other places too, but you can't enroll a key you don't have so things like a safe deposit box are not useful for the average case.

>You may want to enroll multiple and keep them in other places too, but you can't enroll a key you don't have so things like a safe deposit box are not useful for the average case.

That seems like a usability nightmare. Are there plans to improve this? Hardware wallets for cryptocurrencies seem to have it solved. You can keep multiple copies of the keys around (ie. multisig wallets) for maximum security, or you can write down the private key of the device you have and store it somewhere safe. In either case you can retain the public keys so you don't need access to the device if you want to send funds to them (or in the case of authentication tokens, enroll them).

Because each hardware key is unique, this is not a feature currently available nor likely to become available. Each token from the yubikey is not (readily) linkable to the key itself since the underlying secret is opaque and can't be exported, so tricks like Shamir's aren't readily possible.

Yubikeys do solve a lot of use cases very well but that is a downside to them. That is probably still a good tradeoff for most consumers.

>Because each hardware key is unique, this is not a feature currently available nor likely to become available.

You don't necessarily have to do it crypto wallet style and have the private key be exportable. Just adding a public key export (on the security token side) and a way to enroll a token by its public key (on the browser/website side) would allow you to enable 2fa without having to make a trip to the safe deposit box (either to store your backup codes, or to fetch your backup token for enrollment).

>Each token from the yubikey is not (readily) linkable to the key itself since the underlying secret is opaque and can't be exported

That's not an issue. You can derive more ECDSA public keys from a single master ECDSA public key[1]. The corresponding private keys can only be derived using the corresponding master ECDSA private key, and the generated public keys can't be linked back to the master ECDCSA public key. Bitcoin hierarchical deterministic uses this property to generate wallets that don't need regular backup (all your addresses are derived from one key) and apple's find my network uses something similar.

[1] exact mechanism is described here: https://bitcointalk.org/index.php?topic=19137.msg239768#msg2... starting at "Type-2 is a bit less obvious [...]"

For FIDO (and thus WebAuthn, and thus to make this actually practical beyond a toy that only works for some particular Yubico product) the keys are random per enrollment. This is intentional because it means that you can't be tracked, since "your" key on Facebook and "your" key on GitHub are no more related to each other than "my" key on Facebook is to "your" key on GitHub.

Google have apparently some plans to address this problem in the medium term. Adam Langley has written vaguely on this subject before. In the short term, their priority is the trick he wrote about most recently - if your Android phone is enrolled as a Security Key with Google, and it's signed in to Google because it's an Android phone, and you use Chrome on a desktop, which is also signed into Google, the Chrome can use Bluetooth to determine if the phone is physically nearby and if so propose to authenticate your desktop Chrome to a remote web site using the Android phone. Elegant, albeit not suitable for those who fear lock-in.

>This is intentional because it means that you can't be tracked, since "your" key on Facebook and "your" key on GitHub are no more related to each other than "my" key on Facebook is to "your" key on GitHub.

I get the motivation behind it, but the mechanism I proposed in the last comment still preserves those properties? Each site would still get its own derived ECDSA public key. The master ECDSA public key would only be shown to the user and is to be kept within the browser. If a user wants to enroll a not-present security token, the browser will take the ECDSA public key and derive a public key to present to the site, so the site still can't track users using security tokens.

To complete enrollment you need to know the corresponding private key, live.

The relying party says "I am some.example and I want to enroll a Security Key, but, not ones which recognise these huge random-looking IDs that are already enrolled: 12345678, 34561234. I also picked this random nonsense XYZXYZXYZ. Go for it" and your browser talks to your Security Keys until it finds one that isn't already enrolled, gets that one to sign the appropriate message and sends back, "I am a web browser, I checked that you are some.example. I picked my own random nonsense XXXZZZ, and a Security Key picked public key ABCDEF, then to prove it knows the private key it signed this message for some.example mentioning XYZXYZXYZ and XXXZZZ and with bitflags it understands enough to know what it's signing. It says the resulting credentials have random-looking ID 98765431. Thanks". /s/Security Key

If the Security Key cost less than a low-end Yubikey, it has no storage. That random-looking ID is in some sense your private key for the site, but suitably encrypted, e.g. with AES in Galois/Counter Mode, so that the device needn't remember it, when a site asks keys to authenticate, it must provide the ID they're authenticating against, and so they can do AES GCM, figure out if they minted this ID, and if so recover the private key and authenticate. This is fiendishly clever, but so far as I can see renders your idea impossible.

>you need to know the corresponding private key, live.

This seems like the main blocker. Why is that required? In theory all the site needs is a public key to verify against.

If you have questions about why the WebAuthn protocol works the way it does, it seems like you'd want to first read the protocol in detail and then if you still have questions ask its maintainers.

It looks like Yubikey supports ECDSA keys as of 5.2.3 (Yubikey 5+ devices) and will export the public keys and allows private key signing so this should be possible. It will be an irregular yubikey flow code wise but user wise will appear normal.

I guess try to follow 3-2-1 backups as closely as possible:

3 copies of your 2-factor, 2 different mediums (a Yubikey and recovery tokens printed on paper), at least 1 in a different location (safety deposit box, trusted family members house, etc).

> I’ve been considering getting a Yubikey. Do they work on mobile? > Edit: Looks like some Yubikey work via nfc for mobile.

The Yubikey OTPs work if Yubikey is connected to a phone via USB (Type-C). Not sure about Fido/U2f etc though.

I can sell you a picture of my pliers for 1eth

Replied to wrong comment I think

ah, my fingers are too big for using HN on my phone

Ever since 1password removed local vaults I am looking / waiting for a decent alternative. I also wonder what the impact of that move was on enterprise users, as they don‘t have hosted version.

This kind of feature is also available on BitWarden Premium

You can do this with LastPass.

I'm the OP from yesterday's story.

I had 2fa enabled on my LastPass account, but didn't have access to the phone anymore. I clicked a link, LP sent me an email, and I was able (through that email) to remove 2fa.

It doesn't make their 2fa completely useless, but it's not great.

That sounds fine to me tbh. It's worth knowing, but it's not weak. Email is a pretty good 2FA in terms of security, it's just not great in terms of usability, so it makes for a good fallback.

Attacker with MP + email access is pretty severe.

I wish more services used email as a 2FA instead of SMS.

Ah yes, the $5 wrench method.

I mean, if your threat model is such that you need to consider kidnapping and being hit with a wrench, as opposed to just a drive by breach, then you should in fact account for that appropriately.

Come on, this is hacker news.

Some of our skulls are so thick you’d need at least a $10 wrench

A simple rubber hose would do. https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis

Are you aiming for perfect or have you stopped at good enough?

Also known as the "So you think you can escape the FBI [/CIA/FSB]?" fallacy.

The xkcd author did a disservice to online security with that comic.

You can be forced to disclose your secrets but you will know they were compromised, that's encryption doing its job.

There's a world of difference in knowing.

Same in the world of lock picking.

I can smash your door in, or simply break a window. The difference is you’ll definitely know I did it. But unless you in the routine of checking your lock pins for scratchmarks, you probably wouldn’t know if someone picked the locks.