Here’s what I do for passwords. Thoughts? Secure enough, or no?

In My Humble Opinion
1

I’d be interested in learning what the wise sages here think of this.

Similar to the @Schnitte thread but I didn’t want to hijack it, here ➜ Plase recommend a solution for my password management needs ■

I don’t use any password service. I use a schema that’s been working quite well for many years, and I rely on my memory (and my wife’s memory)

I basically use only two passwords, everywhere. For the sake of discussion let’s call them shortQuickEasy, and longerAndSecure.

Only two passwords, and I don’t write them down anywhere.

shortQuickEasy — I use this on most of my logins where there are no finance or security concerns, such as here on the SDMB, my motorcycle forum, and also on my Safeway grocery store login, accounts like that. If the password gets compromised, I really don’t care. Most of my logins use this password. Make it easy to remember, and include special characters like shortQu1ck&3@$y. Mine is about 10-12 characters long.

longerAndSecure — I use this only for emails and banking and my retirement investment accounts. It needs to have more than 15 characters. 17-20 would be better. Similarly, mix in special characters: eg, longer@nd$3cur3

There’s more. longerAndSecure is a root of the real password, so that its variations can include:

longerAndSecureFacebook
longerAndSecureLinkedIn
longerAndSecureGmail
longerAndSecureBanking
longerAndSecureRetirement

Those addendums are literal. It is the length of the password that really matters. The special characters are in the root.

And obviously, I use these for the specific accounts.

If you want fewer variations you can do something like:

longerAndSecureSocialMedia
longerAndSecureEmail
longerAndSecureMoney

But since my retirement investments have all the money I have to live on for the rest of my life, I really want a separate password for those logins.

longerAndSecureRetirement

This schema is easy to remember. My wife uses the same schema so that we help each other remember, and also she has access to my logins and vice-versa.

It’s basically only two passwords.

2

A quick word about Facebook. I used to use shortQuickEasy but FB accounts are frequently hacked and used for spurious purposes so I needed a longer password there. So awhile back I moved that account into my longerAndSecure schema.

3

The downside with your scheme is that if any bad actor comes across one of your longer and secure passwords, the pattern is obvious and they can easily break into another one of your accounts that follows the same pattern.

To wit, if they find a password that is “longerAndSecureLinkedIn”, I think the thought that your password to Facebook is “longerAndSecureFacebook” is pretty obvious.

So only marginally better than using the same password everywhere.

I do follow a scheme like this for usernames, usually when my preferred username is already taken. So my username for Facebook might be PreferredUsernameFB and my username for LinkedIn might be PreferredUsernameLI.

As for passwords, I use a password manager that generates single-use random-character passwords for all of my accounts. Even the built-in ones for a web browser or from Google or Apple are better than nothing, and certainly better than using the same password everywhere—or even a variation of the same password everywhere.

4

This is not an original idea, and you’ll find warnings against this kind of password reuse—even with modifications—from any online security expert. All it takes is one password hash leak from an insecure site and the security of your online presence is compromised.

[ninja’d by @robby who provided a more nuanced explanation of why this is a bad scheme.]

Textual passwords in general are not very secure, and the two-factor authentication schemes which have become popular aren’t actually much better against a concerted attack. For accessing some work systems I actually have to do a triple two-factor auth validation, which is not only irritating and time consuming but because authorization is done over completely unsecured SMS it may as well just be passing a private note through a classroom of curious fourth graders.

We’ve had public key encryption for half a century, and most computers and devices today have some kind of biometric scanning capability. The ‘security by obscurity’ approach and use of textual passwords for anything but the most minimally secure applications should be deader than Dillinger.

Stranger

5

Thanks guys. Thoughts for imminent consideration.

6

We had a thread a while back about a commercial product that was essentially the same idea: Qwertycard password assistance cards - how good/bad an idea is this?

7

You could consider switching to passkeys, an emerging standard to improve logins. It is much easier to use than passwords and time-based 2FA. Passkeys are broadly supported across operating systems, browsers, and devices now, but website support is still hit-and-miss. For the websites that support them, however, it is a good balance between security and convenience.

The SDMB, for example, DOES support them. (They call it a Physical Security Key, which is actually something different, but that same feature actually does support passkeys. You can access it at https://boards.straightdope.com/u/your_username/preferences/second-factor (or Preferences → Security → Two-factor authentication → Physical Security Keys).

What is a passkey?

  • It is a “shared secret” between your device (computer or phone or tablet, typically) and a remote server (the website you’re visiting). This shared secret is automatically generated and cryptographically strong. There is a lot of fancy math involved, but it basically boils down to public key cryptography similar to how HTTPS and SSH keypairs (for developers/sysadmins) work.

  • For you as a user, the big thing is that there is nothing to remember and there is nothing to steal. Each passkey is only good for one website/app. Your device automatically communicates with the remote server to securely transmit the passkey, and only to its intended recipient. Neither you yourself nor any rogue apps can steal or accidentally leak the passkey (generally speaking).

  • So your device/browser manages all this complexity for you. In exchange, all of you have to do is remember either 1) your device master login (like your phone PIN/pattern or your computer password OR 2) use your biometrics (like Apple Face ID or your fingerprint sensor) to authenticate yourself. The nuance here is that you are only authenticating yourself TO YOUR DEVICE, same as you do every day — neither your password nor your biometrics are ever sent to a remote server. Once you authenticate to your device, your device deals with the passkey situation automatically on your behalf, sharing only that particular passkey for that one particular server (and only the public part).

Compared to passwords:

  • They are much safer, hundreds or thousands of times stronger
  • Are never reused between websites
  • Don’t need you to remember anything
  • Just like passwords, can be stored locally on your device OR synced to the cloud (via Windows Hello, Apple Keychain, Chrome/Firefox sync, 1password or another password manager, etc.)

Compared to time-based 2FA:

  • They don’t require you have another device or app handy
  • They don’t need you to type in anything that expires in 30 seconds
  • They can be easily synced across devices (if you so choose)
  • They don’t have their own set of recovery keys that you need to print out to keep track of (they fall back to your passwords if you lose a passkey)

All in all, it’s a hugely convenient way to deal with website and app logins. Create one passkey for service and you can 1-click login to it from all your synced devices, in a way that’s much stronger than password alone. It is a little weaker than true 2FA, since it’s no longer two-factor… you are replacing “something you know and something you have” with “one very strong secret that only your device/password manager knows”, but for most practical purposes, it is a much better balance of security and convenience.

2FA and long complex passwords mostly protect the user from themselves, which is also what passkeys do, just in a far simpler way. It’s literally one click to log in after you set it up.

But… it can’t really replace passwords altogether (because you still need one if you ever lose a passkey), so that means your password is still ultimately the source of truth, and ideally would be strong and randomly generated (which means you would still need a password manager). But even with a password manager, a passkey login is much faster than a password + 2FA + email/text auth.

8

I frequently read FB accounts are hacked. I dug into this and found it’s because of a weak password with the email account attached to the FB account and a weak password for the FB account itself. Often both use the same password.

But the real problem is using an email account that has a contact list and used for other things.

If you want to ensure your social media is almost impossible to hack:

Use an email account for each social media account, and nothing else. So if you have several social media accounts, then you need separate email accounts, one for each. Every password must be unique and every email account must contain no contact lists.

9

You don’t really need that as long as you have a separate random password for each social media account, and preferably 2FA on them too.

10

If nothing else, your email should have a long, unique password that’s not used anywhere else. If your email is a duplicated password or is a simple pattern, it’s that much easier for a hacker to get in. If they have access to your email, they can get access to many of your other accounts. So make sure your email has a very secure password at least.

11

Or, maybe, just don’t use Facebook and similar social media platforms that are insecure and primarily serve to exude toxic disinformation and far-right propaganda and conspiranoia.

Stranger

12

To be fair, that’s most of the internet… and society… these days.

13

If passwords are implemented properly, all of that is true of passwords, too. Now, passwords often aren’t implemented properly, but I’d bet that that’s true of systems that call themselves passkeys, too.

14

One big security feature of passkeys that @Reply didn’t mention is that it also authenticates the remote site to you. Phishing a password and (most forms of) 2FA/MFA is pretty easy. Something as simple as a look alike website can collect both passwords and the 2FA and immediately use them.

The only way to steal a passkey authentication is to steal the website’s private key, and if a service has lost their private key, then they have some major problems.

15

Human-readable passwords are inherently limited by the length that a human user can recall and enter into the interface. To match the permutational ‘complexity’ of a 2048 bit passkey, a password would have to be 256 characters long; even if a human user could remember passwords of that length, typing in the equivalent of a long sentence every time they need to log in would be frustrating. In addition, transmitting passwords inherently suffers the weakness of a man-in-the-middle (MITM) attack (unless the authorization occurs via a hashing client on the user side), whereas public keys between system can be passed in cleartext and even if they are intercepted don’t compromise the security of the communication since neither side has information about the private key which is used (with the complementary system’s public key) to authenticate the system.

This scheme is, short of quantum computing systems that can rapidly calculate large pseudoprime factors, inherently more secure that sending passwords back and forth. And actually, most internet communication on the internet uses this transparently without the user even being aware. Any website with an ‘https’ in the URL is by default using Transport Layer Security (TLS) to provide at least a basic level of encryption to prevent ‘easy’ MITM surveillance of plaintext data being transmitted through open networks.

Stranger

16

Yeah, it’s really hard to “improperly” set up a passkey in a vulnerable way. It’s a technically well-designed spec, and a lot harder for both users and implementers to screw up — especially since it’s often handled by the OS and secure enclaves these days.

However… one major downside to them (and I mentioned this, but kinda buried the lede until the last paragraph…) is that they still ultimately depend on a password. If you add a passkey to a service but still keep a weak password, then your security isn’t any stronger than before. Anybody who guesses your weak password (or if it gets leaked by a website hack) can still access your account without your passkey, unless you set it as a 2FA requirement.

And that’s another downside to them… the marketing and consumer education around passkeys hasn’t been great, and people often confuse them with time-based 2FA codes or physical security keys like YubiKeys. Passkeys are neither of those things, but they can be used as (or with) those things… confusing, innit? =/

17

Also — and I probably should’ve emphasized this earlier — a good password manager + 2FA is already very good security.

  • Same password on multiple sites = very bad idea
  • Same password on multiple sites, with slight modifications per site = still a bad idea
  • Password manager with randomly generated passwords for each site, encrypted with a master password that only you know = pretty good. It doesn’t really matter then if a particular site’s password gets stolen, because hashed or not, it was only ever good for that one website.
  • That same password manager + independent, device-specific 2FA like Google Authenticator = very good, but extremely annoying if you lose your phone. If you also lost your recovery codes, you may be locked out forever. The risk is not worth it for many use cases, IMO.
  • That same password manager used as 2FA on the same device = still pretty good, but way more convenient. Less prone to access loss since the 2FA is just saved alongside your password, and it’s the same master password you use multiple times a day.
  • Passkeys are pretty much as secure as that scenario, just a lot easier to use and a lot harder to fuck up. Though proper high-entropy crypto is technically superior, true, nobody is going to bother trying to brute force your randomly generated 10+ character password anyway.

TLDR it all really boils down to having strong, random, site-specific passwords. 2FA, passkeys, physical security keys… all of that is just icing on the cake, neither necessary nor sufficient for good security.

18

While I use a password manager, none of the passwords are complete: each contains at least one key to a piece of information that only makes sense to me. For — not real — example, {LP79} would refer to the license plate of the car I bought in 1979 (yes, I do remember it because it was my first new car). Just a little bonus for anyone who might get access.

19

{sending my bot army to scour state DMVs for the license plate number of @OttoDaFe’s first vehicle}

Stranger

20

I invite you to query the Washington State DMV all you want. You don’t even have to let me know what you find.

Besides, I said it wasn’t a real example.