Hacker News new | ask | show | jobs
by jrm4 1396 days ago
For all of its warts, at least crypto has managed to come up with a clever little motto that correctly states the issue, in the form of "not your keys, not your crypto."

Putting your passwords in the hands of a third party drastically increases your threat surface and no amount of hand-wavy "but it's not as convenient" will change this fact.

Now, it may be true that the convenience factor is very strong right now, but the solution will never be "let's keep hoping real hard that the third parties are good at this." Not unless any of the third parties are willing to take on indemnification or liability.

The proper thing to do is to figure out how we can best empower people on their own. I know it's difficult, but that doesn't fundamentally cut into the fact that "this is what SHOULD be done."

5 comments

Not sure I follow. As stated in the article LastPass does not have the "key" (Master Password) in this case, so a straightforward reading of your comment suggests there's nothing to be worried about here. However I think what you're saying is that even trusting encrypted bundles of secrets to third parties is a bad idea?

Even on this point I have to disagree because that's precisely what 2FA is for. Even if LastPass (or Bitwarden in my case) stole my vault's password and posted my credentials on pastebin, no one could log into any of my 2FA protected accounts. (Ironically this account on HN is one of the few that doesn't support 2FA. Oh no my internet points!)

"not your keys, not your coins" may apply in the cutthroat 2FA-less decentralized world of cryptocurrencies, but most of the rest of the world has much more nuanced threat models.

I thought the 2FA all the big services have is so that they will deliver you your encrypted vault, rather than another layer of encryption? (I know FIDO can theoretically do that, but AFAIK it really wasn't designed for it).

The threat isn't the service having the encrypted vault anyway; we kind of trust the encryption to be decent (though of course you can't know what technological threats are looming).

The real threat is that you're putting your password for decryption into a proprietary blob with an internet connection and auto-updates enabled. It might be sending your password random places now or maybe at some later point.

Note that even a source-available password manager doesn't really solve this issue if it's not self compiled - and most of the time you'd probably want automatic security updates enabled on something security critical. But they can put anything they want to or are pressured into putting in there.

> I thought the 2FA all the big services have is so that they will deliver you your encrypted vault, rather than another layer of encryption?

Correct, 2FA is protection in addition to your password manager. So if someone gets your unsealed vault they cannot log into any services without also compromising your second factor. 2FA is not for further cryptographic hardening of the vault itself.

> The real threat is that you're putting your password for decryption into a proprietary blob with an internet connection and auto-updates enabled. It might be sending your password random places now or maybe at some later point.

If you use Chrome and Safari your passwords are going through a proprietary blob with an internet connection and auto-updates enabled. If you use extensions for your browser they likely can steal all of your passwords.

Nothing can protect you if you don't trust any of the code you're putting your secrets into, although 2FA with some USB devices cover a mind boggling range of threats. A keylogger and screen capture combined wouldn't be sufficient to bypass them.

> Note that even a source-available password manager doesn't really solve this issue if it's not self compiled

Are you compiling your browser from source after verifying every line of code it contains? If so what makes you think you can trust your compiler?

You have to trust something. Choose your threat model. Choose your risks. Live your life.

Actually -- a "web of trust" idea for the browsers is quite sufficient.

Google et al... have already proven that they are at least decent at security and that they care about things owing to their success in the market. They've proven that they've handled this reasonably well and following their lead on how to do security in software is probably pretty good. They have both experience and skin in the game, lots of it, in the form of lots of money et al.

NOW, these password companies? NOPE. They simply don't have the right incentives in place to be trustable. (or more specifically, that they're going to be much better at securing my stuff than I will) They're too young and don't have sufficient "punishment" at the ready for me to be able to trust them much. They don't do indemnification, and liability for them isn't going to be great. I can't presume the same level of skill or care because the infrastructure/incentives aren't as presumably solid.

(Put differently, the Lifelock guy was a hero, he was at least willing to put something real on the line.)

Yes, 2FA/MFA is almost always just an access control measure over who can retrieve the (in this case encrypted) data from the server.

TOTP is based on a shared secret that client and server both know (so inherently a compromised server can just skip it). For webauthn and similar, the token will sign a specific challenge, incorporating the site name and a counter value etc. The server stores the public key, but the check can be disabled.

The real risk is the auto updating client and the integrity and supply chain of the code it runs - unless you actually audit the client code, there's limited value in compiling it yourself. If the attacker can ship you a compromised signed binary, assuming the company is competent in their setup, they've compromised a development environment, code review environment, code signing environment, perhaps a CI/CD and testing environment, and then the release distribution environment. To get you to compile and install their dodgy source only requires a compromise of their development environment, as very few organisations will slow down their routine development cycle enough to add significant barriers to this one layer being compromised (as it has to be done for every commit checked in, every dependency changed, etc.)

> Ironically this account on HN is one of the few that doesn't support 2FA. Oh no my internet points!)

Is the source for the live site public? 2FA could be added in an afternoon.

What does empowering people on their own even mean in this context? I thought password managers were how you empower people, in view of the constraints of:

- passwords need to be strong, and that is inconsistent with being memorable

- passwords shouldn't be repeated

- people use multiple devices

What is the user empowering solution to those three constraints other than password managers that store in the cloud, or flat-out ending passwords in favor of biometrics or something?

Again, there is no "cloud," there is only "other peoples computers." It's time to start taking seriously ideas like "home servers."
Well it's a good thing LastPass doesn't require you to put your passwords in the hands of a third party! Just the locally encrypted passwords. This is vastly different than, say, a crypto exchange, where the meme originated because in that case, the exchange can literally sign blockchain transactions for your wallet, because they share a key.
My problem is that as an unskilled person - will I be any better at securing my own system?
If the password journal my mom left at my house while visiting is any indication: absolutely not.

Use a password manager, remember a 2nd password for your email yourself, and then use a second factor for as many things as possible. USB keys are best, but anything is better than nothing: SMS, Authy, Google Authenticator, phone call, whatever. Chrome and Safari both have password managers these days, and some Chromebooks even have a builtin second factor. 2FA is still a hassle for sure, but it's getting better all the time.

People like to dunk on the password journal but I find it hard to believe that someone is going to break in to your mom's house as the way to access her bank or facebook account.

It's a horrible idea to leave the password for the database sitting next to the admin's workstation. But physical access is a vastly different concern for a corporation than an individual.

Threat surfaces are different for different people. I'd _love_ if my parents kept a separate password notebook instead of an unlocked note on their phone.

2FA is obviously good but different. But a notebook is an entirely offline password manager and it immediately lets people do one of the most important things which is not repeat passwords.

Yup. Writing passwords on paper, at home, is just about as secure as it gets.
Self hosted, on-prem, 2FA (something you have and somewhere you are). If your handwriting's bad enough you're almost pushing into some kind of biometric lock.

:)

The password journal is probably the safest providing the passwords themselves are strong. The likelihood of someone compromising your mom's passwords online are an order of magnitude greater than someone breaking into her house and copying her journal.
Unless she picked bad ones, or is prone to leaving it places, what exactly is the problem with the journal?
And my answer, as someone who doesn't work for a password company but is into this sort of thing, is "Yes, I believe one can be." -- or more precisely, "When you do it yourself, as opposed to a no-real-liability password company, you can get a better read on what the issues are."

Consider a classic "grandma" solution. A little notebook with good passwords kept in the purse or wallet. The issues here are more knowable than with LastPass or whatever.

> classic "grandma" solution

> with good passwords

Well, which is it?

In all seriousness though, the two main benefits of password managers are they only autofill on the correct domain and they’ll suggest actually good passwords.

No, but there are easy-to-use, reliable and secure solutions, such as Bitwarden.
I don't particularly see why Bitwarden would be any better at defending against this kind of attack, unless you're talking about self-hosting (and I would trust a hosted service more than a non-technical person self-hosting in this case).
And even if you run self-hosted, you're still needing to either audit every line of the web vault (and changes made each time it's updated), or the browser extensions or client applications.

Self hosting can help insulate you from a server side bulk compromise (with adequate security measures in place yourself which, as you say, not everyone will do), but it won't deal with the more pervasive software supply chain issues of compromised development environments etc.

I find the saying very trite, but it's self evidently true - the cloud is just someone else's computer.
:) :) :)

I literally have this posted on my office door at the university where I teach.