Underneath all the layers of security and encryption and footguns is still almost always a password...

We've invented better things, but they inherently have the problem of: What if I lose/break/etc my hardware token? What if it gets stolen? Plus of course the vendor lock-in potential.

The closest we really have is biometrics but even those have complexities, particularly with deep-fake style tech getting really near perefect.

I'd rephrase. Underneath it all is a secret. Classically, passwords were shared secrets with someone. Everything since has come down to a way to not require direct sharing.

Agreed.

I introduced several times password managers to my friends and family, and more often than not, it was a disaster.

Because eventually, either they set a very simple master password they reused elsewhere, defeating the entire purpose of the whole exercise, or they lost the master password.

The latter meant they lost a lot of accesses (unless they have backup discipline, which of course they can't have by nature) because there is no recovery.

So the alternative was for me to hold the backup passwords or recovery passphrase/seed. So much for making them independent.

Bottom lines: security sucks and ergonomics sucks because most users are not tech saavy enough to handle complicated cases.

Making E2EE even an option is nice, and the best you can do for now.

> they lose the master password

The threat model for every lambda user having a password manager does not cover breaking and entering[0]: they should write down their master password and keep it at home in their bedroom drawer.

Use biometrics where possible (e.g. bitwarden on Android has that option)

[0] maybe it does for you, working on some DoD-confidential docs, but your computer-illiterate aunt doesn't.

I did that for my mother.

She lost it anyway. TWICE.

As for bio-metrics they are not possible on all devices, and some software will require you to enter the master password once in a while even if it's activated.

But even if it was not the case, if you loose your device, you need to setup the new one, and for that, you need the master password or have backups.

Back to square one.

For the few keys I need to remember (external drive bitlocker key, windows password, etc) I do reuse a few passwords but I used passwords that have never been used on the internet, so I should be preventing the password reuse risk from breaches. Is there something I’m missing in this strategy?

Depends of what problem you are trying to prevent.

If you are trying to prevent most attacks from the internet, this is perfectly fine.

If you are trying to prevent a close person to gain access to your whole system, this could be improved.

Yeah my concern is theft or hacking more so than evil maid. I’ll keep it in mind if that changes.

The way I've done it with close family is that I kept a copy of their master password in my own vault (or the shared family one) to remind them when they inevitably forgot.

It's not ideal, but it's better than the alternative of them reusing extremely easy to guess passwords.

I've given some family members small paper pads and encouraged them to write down important passwords, and keep them in their home office. This way they can at least have a chance with semi-reasonable unique passwords, vs falling back to using the same trivial password for everything, and still needing to reset it twice a year ...

sneak's law: users can not and will not securely manage ( = {generate, backup, authenticate} ) key material.

Any system that expects users to preserve keys is going to fail.

Any of us are just a medical incident away from forgetting all of our passwords.

A friend of mine had a stroke unexpectedly in his 40s which ruined his language memory. Regaining access to much of his digital life was somewhere between difficult and impossible.

That's because users don't have to suffer the permanent effects of their carelessness. There will always be someone they can scream at and blame for things going wrong. Because they're the customer, and the customer is entitled to satisfaction.

So all technology ends up being designed for careless and irresponsible people because it's generally profitable to do this. If you don't, someone else will.

So much contempt..

> So all technology ends up being designed for careless and irresponsible people because it's generally profitable to do this

So all of technology ends up getting designed for life, which generally will throw obstacles in your way. And therefore people will build escape hatches.

It's not difficult to learn how all this stuff works and be careful not to lose hardware keys. But most people would rather think about other things and just call customer service if they get locked out. That's understandable, but I wish people would take more responsibility for their own security.

Aren't the Chrome passswords part of the (optionally) E2EE encrypted data? It might not be the default but AFAIK they definitely _can_ be E2EE encrypted.

Yes, this is an option (that you definitely should turn on).

I think Google shipped another underbaked product here. They have E2EE implemented for Chrome sync data already. They should have just used that rather than going with whatever system they decided. Adding Google Authenticator to the Chrome Password Manager is probably much more useful than having it as a standalone app.

I can see Google's rationale for keeping them seperate. It is supposed to be the 2nd factor after all, and if your 2FA secrets are stored and synced right along with your passwords that really makes it not much of a second factor. The same can be said for any cloud based 2FA secret syncing, but I believe for most users they still only have 1 phone with Authenticator and the 2FA secrets on them, and this cloud syncing is just about allowing someone that gets a new phone to restore their 2FA secrets. That's pretty different from actively syncing your passwords between all of your mobile and desktop devices like Chrome's sync does.

Also I'm sure there's many use cases for Authenticator when you're not already in Chrome or even in a web browser. Stuff like entering a 2FA key when logging into your VPN. It'd be awkward in that situation to pull up Chrome and find some obscure menu just to get your VPN's 2FA code.

> If you use Gmail, all your password resets will go to your Gmail which also isn't E2EE

But it sort of is since it's sent over https, no?

Merely being sent over HTTPS does not guarantee full E2EE.

End-to-End Encryption means that nobody between you and the person you're communicating with can decrypt the data, not even the middle-man service facilitating the communication.

In the case of Gmail, the content itself is not encrypted. Google can read the e-mail. It's likely encrypted at rest, but Google has the key.

No. End-to-end encryption means: only the sender and recipient can read the content, not any intermediate party or service provider.

And Google is not the sender of your password reset emails, they are a service provider, and they have full unencrypted access to the content.

Authy does a neat thing where it prompts you to re-enter your password every couple weeks even though it doesn't need it, just as a practice to keep it fresh in your mind

Honestly everything should do this. If it's saved in a password manager, it ensures you still have access to it, and if it's memory, it serves as a kind of spaced repetition to keep those neural pathways strengthened.

> If you keep all your passwords synced in Chrome, for instance, none of them are behind E2EE either.

correction: You can enable E2EE on your Chrome passwords by setting up a passphrase! To your point, this is a great feature but allows more oblivious users to shoot themselves in the foot, so it's not the default.

Here's Google's docs on how to setup a passphrase/E2EE on Chrome sync: https://support.google.com/chrome/answer/165139?hl=en&co=GEN...

> It's not like syncing Authenticator data is less secure than anything else

This is false. Android backups are end-to-end encrypted with the ability to recover after device loss. Google already solved this problem years ago. Now instead of letting Authenticator use that solution (which it should have been using since the start, and would be the simplest thing in the world to implement) they had to build a whole new custom thing that is worse. But hey, I bet someone got a promotion for shipping a new feature.

> ...but only for the minority of users for whom the necessity of extra security outweighs the risk of losing access entirely.

The problem is, Google can and does hand over user data to law enforcement. By handling MFA secrets without e2ee, Google is not doing any one any favours. I mean, it isn't like Signal and WhatsApp (apps with more users than Google Authenticator) haven't figured out a good UI for it for years now!