Your Password Algorithm Sucks
There are two sorts of people in the world; those who know they are stupid and those who think they are clever.
Stupid people use a password manager. They know they can't remember a hundred different passwords and so outsource the thinking to something reasonably secure. I'm a stupid person and am very happy to have BitWarden generate and save fiendishly complex unique passwords which are then protected by the app's MFA. Lovely!
But people who think they are clever decide to bypass that and use their own super-secret algorithm.
Every clever person's algorithm boils down to the same thing:
- Have a single strong main password.
- Add to it some information related to the service.
For example P@ssw0rd!_facebook and P@ssw0rd!_linkedin. On the surface, that's quite an attractive proposition. You remember one thing and you don't need to trust a password manager.
People who are extra clever use the same algorithm but wrap it in a command-line function which XORs both pieces of data, creates a SHA-512 hash, takes every prime numbered bit, converts to ASCII, and uses that to generate a password. Smart!
Either way, these algorithms suck! Let me explain why.
Password Leaking
One day, LinkedIn decides to LeakedOut its users' passwords. Anyone who can see P@ssw0rd!_linkedin can make a pretty good guess at your password for Facebook, banking, dating, and shopping etc. This means you now need to change every password that you have.
Even if you have used some amazing cryptographic powerhouse of an algorithm, there's still a chance you'll accidentally leak it or get so paranoid that you decide to invalidate it. Now you need to change your password on hundreds of sites.
Password Rotation
We all know that it is a bad idea to ask your users to regularly change their passwords - yet sites often persist in doing so.
How does your algorithm cope with this?
Do you have to remember that it is P@ssw0rd!_facebook_1 and P@ssw0rd!_linkedin_23?
Perhaps you'll write down all the suffixes and find a way to store them securely - like, say, a password manager?
Password Requirements
One site says "Your password must contain a special character and a number" another says "You can use any special character except % or ?" another refuses to let your password contain two consecutive identical characters, or it must start with a number, or it cannot be longer than 12 characters. Yes, I know password rules like this aren't sensible - but they are common.
How does your algorithm cope with that?
If you manually have to tweak a couple of dozen passwords generated by your algorithm, you are going to tie yourself in knots remembering the arcane requirements for each one.
Be Stupid - Use A Password Manager
Humans are stupid0. Humans get tired, forgetful, or sick. Our delicious meaty brains are not optimised to remember long strings of complex information or hundreds of rarely used combinations. Knowing that you know not is a super-power. It allows you to offload things that you don't understand to something more competent.
Pick a password manager. Secure it with a reasonably strong password and multi-factor authentication. Let it do the hard work of remembering.
-
Not you, of course. You're mummy's extra-special boy who never makes mistakes. ↩︎
@Edent This is very good. I wonder where you stand with storing your TOTP/2FA tokens in Bitwarden? https://james.cridland.net/blog/2021/should-you-store-your-2fa-totp-tokens-in-your-password-manager/
Should you store your 2FA/TOTP tokens in your password manager?
| Reply to original comment on bne.social
@james I'm a bit worried about cyclic dependency. If I can't get in to BW how do I get the MFA code for BW?
| Reply to original comment on mastodon.social
qgustavor says:
Three suggestions:
In my view, services that require a password shouldn't let users create one, or at least discourage it, and instead generate one for them (obviously client side and from strong randomness). Of course, without breaking password managers for those that do use them.
| Reply to original comment on bsky.app
@Edent The problem with using your own cryptography is that you’re not a cryptographer. Even if you are, your scheme may not have been peer-reviewed.
Kerckhoffs's principle - Wikipedia
| Reply to original comment on fe.disroot.org
Dagmara Czajkowska says:
One more thing: split your personalities. Use different email addresses and fake names and addresses wherever possible. Even if one service leaks data, it won't be possible to connect it to anything else.
@Edent I tried sending a comment on the form, but it didn't appear, so I'm posting it here. My three points:
LessPass
| Reply to original comment on urusai.social
@Edent Third point: while we have to acknowledge that many websites and compiles still rely on outdated password policies (like password rules and password cycling, both no longer recommended by NIST), many important services like banks and e-mail services now support better alternatives to passwords like WebAuthn, and its extension, Passkeys. By design it uses cryptographic keys which can't be weak (like passwords can) and can't leak (because they are stored safety and data stored in servers can't be used on others) and are phishing resistant (something many password managers don't protect against). WebAuthn had the issue of people having to buy keys (which can be expensive for some people) but Passkeys made this process way cheaper (you can use the devices you already own).
| Reply to original comment on urusai.social
@Edent That being said, one thing I should note is that both password generators (like LessPass) and managers have the single point of failure issue, but password generators are worse since, in case someone leaked their master password, one can access all passwords up to the moment they got the database file - for password managers - but all future passwords for password generators (at least, until the leak is known and the person resets all passwords to all accounts). So, by mentioning LessPass, I'm not condoning it, I'm just saying the arguments given in the post against password generators were been solved a long time ago by LessPass but there are other concerns to care about (like those being a single point of failure).
| Reply to original comment on urusai.social
@Edent And, a final last point after seeing a comment on the website: for the sake of whoever you love in this world, anyone building a new website, please don't force random passwords on people, people using password managers might be fine, people using password generators will hate you, and the rest of people will write your random password on some unsafe storage medium (like a .txt file, or Google Docs, or Google Keep, or a post-it), WHICH IS WORSE.
Implement WebAuthn instead using a safe and well-tested library and enable support for Passkeys (IIRC roaming authenticators? I don't remember the technical wording right now). Just do that. If you are afraid some users might not know how to use it, use a safe authentication library. Don't reinvent the wheel.
| Reply to original comment on urusai.social
@owenblacker @Edent @james the 2 factor helps prevent replay attacks. Also the password manager should have a much stronger security for preventing access to your password vault than other systems, so should be more secure.
| Reply to original comment on mastodon.green
@Edent Yeah, I'm dumb too
| Reply to original comment on mastodon.social
@qgustavor @Edent Doesn’t this have the same problem as password managers? I use, and like, passkeys. But they are currently even more prone to a single-point-of-failure.
They are generally kept within a device, browser, or OS vendor’s secure storage and are usually not exportable. That preserves their security guarantees, but prevents you from making a backup. I feel like there’s a much higher chance that I lose my passkeys than that I lose multiple encrypted copies of my password manager DB (and for consumer-facing password managers, those multiple encrypted copies are held by the cloud service on your behalf; you don’t need to be a tech expert).
Consumers absolutely do not understand how passkeys work. To the extent there’s adoption, it’s because services have migrated users to passkeys when they log in, often without the user understanding what’s happening.
| Reply to original comment on hachyderm.io
@Edent
I've seen a compelling argument that, for "regular" users - that aren't guarding corporate secrets or crypto wallets - you can do a lot worse than writing important passwords down in a notebook.
Keep important passwords in the physical notebook. Keep the notebook at home. Perhaps make a copy for your safe deposit box if you have one, or stash a copy with a trusted relative.
Much easier to understand than a PW manager or passkeys.
| Reply to original comment on fosstodon.org
I think this distinction is decidedly unfair on people like me - the fundamentally inept.
| Reply to original comment on bsky.app
ah, but you fail to understand that i have been using my Really Cool Password Algorithm since 1985, and after all of the mandatory password changes i am up to: Passw0rd84299!
that's way outside of the bounds checking for hacking algorithms! #safeAsHouses
| Reply to original comment on bsky.app
James A says:
When I was younger and had fewer login credentials to remember (and perhaps less data personal data accumulated in general!) I did attempt to keep them in mind. As you note, this doesn't scale beyond a certain number of details to remember.
To me it feels that migrating to a Username And Random Password Manager is something of a one-directional process: I'd guess that it is unlikely that a significant proportion of people migrate from managed logins back to a more manual or memory-based approach.
Partly that's because it seems extremely convenient to login to websites thanks to having both the Username And Password automatically populated, regardless of how long it has been since those credentials were last used.
The blog articles I read and liked this week, collected for you.
| Reply to original comment on blog.jimgrey.net
More comments on Mastodon.