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.
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.
...and, those are the only things that really matter for an attacker. Encrypted data (assuming reasonably strong encryption) is useless without the key.
> 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.
Sometimes the devil you know, you know?
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.
Edit: Looks like some Yubikey work via nfc for mobile.
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).
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.
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 [...]"
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.
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.
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.
This seems like the main blocker. Why is that required? In theory all the site needs is a public key to verify against.
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).
The Yubikey OTPs work if Yubikey is connected to a phone via USB (Type-C). Not sure about Fido/U2f etc though.
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.
Attacker with MP + email access is pretty severe.
I wish more services used email as a 2FA instead of SMS.
Some of our skulls are so thick you’d need at least a $10 wrench
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.
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.