Password Managers... revisited (a "talk me down" request)

[ericgeater]

Let me say up front that I prefer hardware tokens.  Now that I've gotten that out of my system, we'll not speak any more about it.

I'm reading the four principal points presented by CISA for Cybersecurity Awareness Month 2022, and the additional notes related to "using strong passwords" focuses on using password managers.

I have never been thoroughly comfortable with these tools, because

• it's all the eggs in one basket
• they're protected by a singular password
• their design encourages adding new private information for "safe keeping"
• oftentimes they're available to users for no cost -- which means there may be no liability for design problems downstream
• principal vendors have now demonstrated their own weaknesses

I'd like to hear your exposition on the value and detractions of password managers, and some of your best practices or key takeaways on the subject.  Or, talk me into them! Tell me why you like them from a security standpoint. 

[tmekelburg1]

---

@ericgeater wrote:

Let me say up front that I prefer hardware tokens.  Now that I've gotten that out of my system, we'll not speak any more about it.

---

It's biometrics for me (this is where we need the ability to add polls to our threads).

Anyway, I wouldn't say I'm thoroughly comfortable with it either but I think it's a necessary evil until the password goes the way of the Dodo bird. Here's what I do to my password manager to help me sleep better at night:

• Use a long complex passphrase
• Enable MFA with an auth app
• Enable trusted devices, e.g., I get notified if it's okay to login on a device I've never logged in with before

Something I don't do but I heard was a good practice was to add an additional 2-3 characters at the end of the passwords saved in the password manager. For example, the password saved in the password manager is Password123 but after the password manager fills in the credentials, you would add your additional characters making it Password123#@!. So if your password manager would ever get compromised, you wouldn't have to worry about your other accounts. 

[JoePete]

A distinction I would make is between device-based managers and the online/service-based ones.

With an online service, you have to assume it is only a matter of time until that database is attacked. However, unlike your typical online repository of credentials that holds hashes for passwords, these online managers must hold your collected passwords in some encrypted (i.e., retrievable) form. While there are a range of possibilities for securing whatever key is used to decrypt such data, no consumer knows for sure what is going on behind the scenes. You have to assume an attack on that database will expose all your credentials.

While something device based is of the same design, you at least have more control over that device. To me, that is a preferable approach.

I think it was Schneier who pointed this out. Forget the "don't write down a password" advice. It's better to have a sufficiently random and complex password that you write down and stick in your wallet than to have only simple passwords that you can remember. Yes, if someone steals your wallet, you may be in trouble. But that is a rarity (compared to the pilfering of online databases), and when it does happen, you know it and get a step ahead of the attacker. We find out about data breaches, months, even years, after they happen.

So I look at a device-based password manager like writing passwords and putting them in your wallet. While there is a risk, it is less than and more addressable than the alternatives of easily remembered passwords or some online service.

[ericgeater]

I'm sorry, but I did not realize there was such a thing as an "online password manager".  I would absolutely be too afraid to use such a tool.

So let's set that aside and discuss device-based managers.  How would some readers describe the improvement to the security posture with a device-based manager, over a password-protected excel spreadsheet on a bitlocker-encrypted USB drive?

edited because I sounded like a pompous jackwagon in my original reply

[ericgeater]

My heart leapt a little bit when you described using MFA / external authentication with your password manager.  Would you share who your vendor is?

The last idea, by the way, has some merit as well.  About the only place where I would see a problem are sites and resources where one cannot clearly determine the longest allowable password length at its creation or change.  At least twice in my career, I have had to troubleshoot this with users who correctly created long passwords, but found out later that their password creation process accepted the first 16 characters, rejected the 17th and 18th characters without any warning.  Later, the resource forbade access to the accounts because they were signing in with 18 character passwords.

[denbesten]

---

@JoePete wrote:

So I look at a device-based password manager like writing passwords and putting them in your wallet. While there is a risk, it is less than and more addressable than the alternatives of easily remembered passwords or some online service.

---

This is a great observation.  Thanks for sharing.

The other risk to consider is "encrypted cloud storage" for the safe, which sits half-way between  device-based and AAS-based.  Aspects to consider include attack surface, preventing data loss, and utility of password sync between devices (plays into user-acceptance).  

[denbesten]

---

@ericgeater wrote:

MFA / external authentication with your password manager.  Would you share who your vendor is?

---

Bitwarden allows me to require MFA for attaching a new device to my password safe, to biometrics-check when unlocking the safe on my devices and auto-lock the safe when I log out of the device.  These and more nerd-knobs can be adjusted up-or-down to match your risk preferences.  For $10/yr, Bitwarden can also be used as the MFA device itself, but there is a chicken-vs-egg problem in doing so if you also require MFA to access Bitwarden.  And, of course using a single app for passwords and MFA creates an eggs-in-one-basket risk with which one would need to get comfortable.

IMHO, The biggest "security posture" improvement is auto-fill.  Beyond making it even easier to encourage length and uniqueness, auto-fill stymies homonym-attacks because the browser auto-fills based on the hostname/URL.  I personally use "click to auto-fill" instead of "always auto-fill" simply to ensure that I am not unnecessarily exposing my password to all the forms on a web-site.

...where one cannot clearly determine the longest allowable password length is...

---

I too have encountered a few sites that enforce different limits when setting vs using a password.  In those cases, I did call customer-service and file a bug report recommending that if "set" silently truncates to 16, "use" should do likewise).

[tmekelburg1]

I use LastPass.

---

@ericgeater wrote:

The last idea, by the way, has some merit as well.  About the only place where I would see a problem are sites and resources where one cannot clearly determine the longest allowable password length at its creation or change.  At least twice in my career, I have had to troubleshoot this with users who correctly created long passwords, but found out later that their password creation process accepted the first 16 characters, rejected the 17th and 18th characters without any warning.  Later, the resource forbade access to the accounts because they were signing in with 18 character passwords.

---

I've been there! It's been a few years since I've last experienced it though. Most, if not all sites, I use regularly now will tell me when the length is too long or the special character type can't be used. I think it was one of my local utility companies now that I think about it.   

[wimremes]

https://lock.cmpxchg8b.com/passmgrs.html

I don't think I can say it better than Tavis does 🙂

[denbesten]

---

@wimremes wrote:  https://lock.cmpxchg8b.com/passmgrs.html

---

Selection of password managers is a matter of personal risk acceptance.  Blanket recommendations (as Travis's article makes) don't work because they do not all "provide the same functionality".

The article would be much more useful if it were to expand on "actually evaluating vendor claims", ranking competency of each vendor in each area of concern.   Or, to truly "raise the bar", Tavis's employer (Google) could open up the APIs to 3rd party password managers, making it easy for everyone to have a competent implementation.