That's not been true ever since the development of good password managers. There are fewer than 10 passwords I remember. One of them is my password manager's master passphrase (5 misspelled-and-with-random-punctuation words). The others include stuff like my work and home laptop/disk passwords, which I can't autofill, my 3 important banking passwords which I do not even entrust to my password manager, and my AppleID password because iOS is annoying enough at asking for that that I'm using one I can remember.
The other ~600 entries in my password manager are 25 random characters (or whatever the upper limit if password length is for sites/services that are 'doin it wrong').
A lot of people (do not trust password managers, case in point the recent last pass scare.
You want passwords to your key accounts to be 1) memorable 2) strong 3) only in your head. For these, I think the article is fairly relevant.
That's no excuse. KeePass allows having the database file locally where it's you duty to manage it.
It might be less convenient, maybe. But I don't see valid excuses for people to not start using a password manager, even less the less tech savvy people.
1. Closed source, so you cannot audit a critical peice of security infrastructure. 2. Perverse incentives - they want to make money, so they are naturally going to encourage new versions over old and deprecate support for old programs. 2a. If your company of choice has not great business they have an active incentive to sell your data (including bank passwords) on the black market. 3. A need to keep "Up to date" i.e. jam whatever hot takes into your app to up the selling appeal - you want your security to be very boring, having a bunch of new features mixed into every release is a recipe for insecurity and disaster. 4. Cloud access - this leads on from the last point, but as soon as you store your stuff on a third party server, even encrypted, your potential leaks go from your computer, to every device between you and the remote, and then some (all third party integrations). Which has the side effect, said companies must start (complex) security auditing practices with all the fun and failure points that brings...
Now, even on the open source side:
1. As soon as you have to update your password manager, you might as well throw away all passwords and start over: a) Can you really trust that no source was beached during the update? b) How do you know it is even a legitimate update? Better not have put your password for updating things in your password manager... c) It's open source, great, so you can audit it but...will you? d) Or will you just trust it and because some guy who wasn't getting paid and is trying to get through school and hold a part time job missed a critical bug, you end up with all your passwords compromised anyways. 2) Deserves status as its own point, Open Source is auditable but not necessarily trustworthy, not without a lot of active oversight.
As such, one can conclude that such programs are mostly collosal wastes of time, if not actively endagering security.
Even as a 'better than nothing', they are a bad idea, to the layfolk who don't know any better its just another potential bad practice they are getting drilled into them.
I would argue that writing down passwords on paper is usually a better practice than using a password manager, at least that can be locked up in your home (and if you can get into my home I have other bigger worries).
Instead we should focus on giving back some responsibility to the user - most sites don't need passwords, if you are using a password manager for those sites you should presume that password is low security.
It would be better if we could codify the importance of a password somehow.
One big advantage of a password manager is you _can_ audit accounts/passwords. I do a once a year sweep of my personal ones in KeePass, and use it as an opportunity to close accounts on services I no longer use. (Not that I believe any 3rd party service can be trusted to actually delete your data when you close your account, but spending 5 minutes updating your profile with junk data before deleting it improves your chances of not ending up on spam lists or automated credential stuffing attacks when that service gets popped.)
For the work shared passwords we use 1Password, which while I prefer their old standalone app over their new cloud thing, they do two very useful things - 1) integrate with HIBP's password checking service so it warns you when you have a password that's been published in a dump, and 2) provides an audit trail of which credentials each team member has ever accessed, so you can revoke only what's needed instead of rolling all shared passwords every time a staff member leaves.
Why misspell and add random punctuation?
Granted, 5 words chosen truly randomly from an English dictionary is already insanely strong, but why not make it slightly stronger?
Simple analogy - if the goal was to protect your house from a 9-foot-deep flood, would a dike with an average height of 10 feet do the job?
I won't tell you what decade it was, when I found that some "bright" user had picked his/her own office phone # (10 digits, 2 hyphens) to use as a "high security" password.
My own mental model - with a decent compression algorithm, and compression dictionary pre-loaded with popular passwords and personal information, how many bits would the specific password in question compress to? That also catches the clever folks who pick stuff like "abcdabcdabcdabcd" or "3.1415926535".
Instead of continuing to debate what makes a good password, we need to put our energy into better techniques altogether! No more shared secrets! Let’s talk about one-time codes, asymmetric key cryptography, hardware tokens, anything but passwords!!
I then went with one-time 6-digit sign in codes that are emailed to the user. These are secure enough if done right, but now I'm wondering if they will feel secure to the users.
P.S. I might change it to a one-time alphanumeric code, which should feel more secure.
Additionally my security is now tried to the email I use which may be undesirable.
So I see why this exists, but please consider also supporting username+password at least until something else browser-integrated comes along.
But like password resets, you're hosed if your email is hacked (unless you have 2FA).
> I'm wondering if they will feel secure to the users
I don't know about secure, but most users will feel extremely irritated for sure.
> one-time codes
One-time codes rely on a password: either it is stored in your 2FA App, or they rely on your email password, or they rely you storing a password somewhere else. OTP rely on stored secrets.
You can make these secrets be much larger than the humble password and call them "private keys" :
> asymmetric key cryptography, hardware tokens
If these are not protected by a passphrase they can be stolen. Which seems like a variation of "nobody can store passwords securely". To mitigate the effects of them being stolen, you need to protect them with a password.
I sympathize with your desire, but it's not that easy, although I do think that we can reduce password usage.
But fundamentally a password is a trust anchor in your brain. I have yet to find a way around this limitation.
How we use them, is very much broken. What is the point of a password that a bit of social engineering can bypass? Why are passwords required to get info on my ice cream rewards? Shouldn't I just get a coupon instead?
You should only use passwords that mean something and they should not be resetable, otherwise you have something closer to a one time token with a replay attack. Forget the password? Tough luck. Either it should not have needed one, or it should have some tangible effect which causes the user to highly value forgetting or getting it stolen.
We have engineered a state where we can't remember passwords because we are actively encouraged to ignore them, passwords are fine, how and when we use them is not.
In other words, something you have (until you forget it). But also something you have to give to someone else after which all security bets are off.
A private key is also something you have (until you lose it). It is not something you ever have to give to anyone else. If you protect it with a password you don’t have to give that password to anyone else.
Big difference!
Consider, if I leave my hardware token at home when I go on vacation, I'm basically locked out of all of my accounts. This is fine, as I typically plan for this to be the case. But it is an attack vector. I can't even audit my protected assets while away.
Passwords were adopted when comuting was something that occurred at a specific facility and the goal was to keep the people, largely the users one already knew of, out of one-another's accounts and data.
The persistence of passwords in a world of global access and billions of devices is ... ludicrous.
And the failure of both enterprises and governments to identify better standards and practices is criminal.
Turns out passwords aren't great at most things but the alternatives often have big downsides.
https://www.microsoft.com/en-us/research/wp-content/uploads/...
This is an argument I can't find anyone making: an aggregate average entropy of the set of all passwords you use is fine for password security, rather than the entropy of each individual password.
As far as I can tell this seems to be a (possibly intentional?) misunderstanding on the author's part.
A single password should instead be treated as a sample from a (plausible) attacker’s distribution, and the complexity of that password can be used to estimate the size of the sample space required for that plausible attacker (as in, how many guesses/how much work they’ll have to do). This is, AIUI, the approached used by libraries like https://zxcvbn-ts.github.io/zxcvbn/
The entropy of a distribution for generating passwords matters when generating them in bulk, such as OTPs or implementing a password manager. This doesn’t seem to be the situation being discussed in the article, which is more about rating a user-provided password.
In fact, the author's article makes this very point, which is why I pointed out the logical flaw in the thinking.
I'll reduce N to 6 for simplifying the author's absurd example but it can expand to any N.
If we take the argument to hold that you roll a random die of N length (6 in our case) and the upperbound represents one strong password, while all other values equate to the word "password", the flaw is in how this logic is applied.
Imagine this is our set of possible values:
password, password, password, password, password, hj5^@l2jl9GGk;Clkm(0]
It makes little difference if you look at this as either the bytes involved in the entire set, or the average of all passwords within the set, it's going to come out looking like you are secure.
This means what they're attacking is all permutations of the following set of characters:
a, C, d, h, j, k, l, m, o, p, r, s, w, G, 0, 2, 5, 9, ;, ], @, ^, (
What an attacker must know though, is the character set used within, as well as the length. This is the logical flaw the author made in their analysis. For an attacker, the entropy of an individual string is taken as possible character permutations required to discover the true password and NOT permutations of the entire strings themselves.
If you look at the values for each string presented in our set, what an attacker has to attack is:
a, d, o, p, r, s, w
C, h, j, k, l, m, G, 0, 2, 5, 9, ;, ], @, ^, (
But in order to attack these, they need to try the full set:
a-z
a-zA-Z0-9;:[]!@#$%^&*(){}
One of these will be VASTLY easier to break.
A password of "aaaaaaa" will have a much lower entropy than "axipeY7".
What am I missing?
Seems like this might be a use case for "dispersion" (the second moment of entropy) [1].
[1] https://math.stackexchange.com/questions/1626522/higher-mome...
He seems to be saying, if your password selection strategy skews towards really weak passwords, and you measure the Shannon entropy of the distribution, it won't reveal that this is a bad strategy.
I don't know anyone who would actually do this and declare a win "because Shannon".
At best, it's mildy interesting that Shannon entropy on its own isn't going to give you a useful answer if you have a weak strategy.
We care about the distribution from which you drew the password, because that lets us analyze how difficult it would be for an attacker who knew your password selection process to brute-force the password. Just knowing the password itself isn't enough information to determine that (though of course you can judge how hard it would be for an attacker once you know their brute forcing strategy).
MathsDegree@StamfordWasABigWin [1] RanThroughAPlateGlassDoorWhenTen [2]
with some esoteric obfuscation rules.
1. I don't have a maths degree from Stamford. 2. Did happen, not one of my passwords.
Use words as your characters with a dictionary of a few thousand words. Assume an attacker knows the dictionary. Make passwords that are too long to brute force (40+ characters). Use enough words that a dictionary attack is also infeasible (4+). Add a salt if you're feeling extra spicy.
Entropy is sufficient if you use the right language model.
It makes entropy requirements explicit, and you can even roll your own dice to supply the required entropy to generate your passphrase.
Try it, it's fun!
Inspired by this, there's a package https://github.com/dropbox/zxcvbn to estimate entropy and give suggestions.
