5 ms·
Ask HN: Which password is more secure?
If I ask my password manager to generate a 20 character password with lowercase, uppercase, symbols, and numbers... it gives me a password like:
`nNqP4nnvMs!HCL@*z3cm`
In real world use-cases, is that a more secure password than:
`aaaaaaaaaaaaaaaaaaaa`
Theoretically speaking, does it have a lower entropy than the first password? How does the entropy calculation know that the 20 'a' characters weren't randomly generated from the same set of characters that generated the first password?
- pwg 5y ago#2 is less secure, not because of entropy per se., but because it will already be present in existing password test files and/or is trivial to create and test (i.e., JohnTheRipper's ability to generate test candidates based upon patterns).
- _justinfunk 5y agoAccording to haveibeenpwnd.com my 20a password has been seen 2,154 in data breaches and the random one my password manager created has not.
- whatatita 5y agoThat link should be to https://haveibeenpwned.com/ https://haveibeenpwned.com/ . Notice the extra "e" before the last "d".
- Tomte 5y agoThe entropy is calculated with knowledge of the process that generated the password.
- _justinfunk 5y agoThis means that the same string can have a near-infinite number of entropy values? What is the value of entropy then from a password-strength point of view? If I understand you correctly, the entropy of "H@ckerN3ws" is 1, if the process that generated the password is defined as: "The first letter is a capital H, the second letter is an at-sign, etc"?
- deleted 5y ago[deleted]
- glial 5y ago> This means that the same string can have a near-infinite number of entropy values? Yes. Entropy is a subjective measure (like confidence) rather than objective one (like length). Entropy measures an agent's uncertainty about the value of a variable. The entropy of the word "password" would be different for an English speaker and a non-English speaker. Your question of which password is more secure depends entirely on someone's method of guessing passwords. If someone just tries all single-digit passwords, then all 2-digit passwords, etc, then your passwords would be roughly equally secure. But if they use some other method that guesses more likely passwords first - checking against a database of pre-existing passwords, or first checking passwords with lower Kolmogorov complexity - then your '20a' password would be much less secure. By ordering passwords according to "likelihood", the second approach is essentially also ordering them with respect to entropy.
- mananaysiempre 5y ago> This means that the same string can have a near-infinite number of entropy values? Yes. (Any value ≥ 0, in fact.) Strictly speaking, what you want is not even the entropy, it is the information, and it is a characteristic of an outcome in a given probability space, so is crucially dependent on the probability distribution you assume; if the model is that this particular outcome always happens, the information is 0 (no information, you experienced no surprise, the optimal coder needs zero bits to convey this outcome) (not 1). Entropy is the expectation value (average) of the information over the outcome (average bits per outcome in a stream of independent outcomes so distributed), so characterizes a probability distribution. Now, if only there was some sort of universal probability distribution or model expressing objective perfect ignorance (over strings of characters, say); then we could say, given any string, how much information it carries and so how difficult it is to guess. The good news is, there is in fact such a thing. Set probability of string s to sum of 1 / 2^(bits to write program) over all programs that produce s then halt. The distribution is known as the Solomonoff prior, the resulting information of s as the Kolmogorov complexity of s, and the normalization constant you need to divide by to actually make the probabilities sum to one as Chaitin’s constant. The seemingly bad but actually fairly tolerable news is that this obviously depends on how you encode your programs into bits, that is the programming language, because obviously you can always put this one sequence in particular into the standard library and give it a short name; but this is not that important for most strings because you can bound the difference between the two complexity values by a string-independent constant (implement each language in the other). I also lied a bit by failing to distinguish all programs (the common definition for Solomonoff) and the shortest program (the common definition for Kolmogorov), but it turns out that this difference can be absorbed into an additive constant as well (a fairly non-trivial theorem AFAIK). The actual bad news is that none of these goodies is computable for halting-problem reasons. For example, the obvious approach would be to enumerate programs in order of length and check if they produce what you want, but then you need to know if an arbitrary program is hung or just really slow in producing the desired string! The ugly news is that, pleasant as this theory is, it isn’t actually all that relevant to human-generated passwords, because, well, at the very least you know a human generated them, and that is in fact quite a lot of knowledge. So, no free lunch is forthcoming as far as answering your question using pure mathematics with no natural-sciences input is concerned. Whether “love, sex, secret, and god” or a more sophisticated model, you are going to need one if you want to go this route. (Password-cracking tools have them.)
- PaulHoule 5y agoIt depends on the threat. If you randomly generated passwords like the first one you will get passwords like 'a'20 unless the system has a filter to prevent that. (My quasi-random passwords something fail arbitrary tests because they might be lacking a number or having a \ or " character that isn't allowed or something...) Practically the 'a' 20 password is only going to be a problem if a password cracker tries it. Really I don't know what the state of the art for cracking is today. Back in the 1990s, before shadow passwords were widespread, I used to try decrypting unix passwords all the time and used a few different lists. The two things that worked were the empty string and password same as the user name. I used the "Phrack 200" and another list of 8000 and don't think I ever got a hit.
- eimrine 5y agoIf this is a password for online service with captchas after each wrong try, #2 is enough strong.
- pwg 5y agoThat is now how passwords are cracked in today's environment. In today's environment, someone obtains (via hacking or bribes) the internal password hash list, and then runs the list through a system such as this one: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... A captcha on the login page does nothing to slow this monster down.
- landa 5y agoThe second password can be compressed almost to nothing, whereas the first password can't be compressed at all. This to me says that the first password is a lot more secure. https://en.wikipedia.org/wiki/Kolmogorov_complexity https://en.wikipedia.org/wiki/Kolmogorov_complexity
- _justinfunk 5y agoPractically speaking, why does compressibility matter in terms of password security? Side note, in the comments the second password is being referred to the 20a password while the first password has no monicker, which validates the compressibility of 20a password
- pwg 5y ago> why does compressibility matter in terms of password security? It does not. The amount to which it can be compressed is a proxy for internal redundancy. And a 'password' with a lot of internal redundancy is easier to generate and test against the real password. I.e., code to generate all possible 25 character and less passwords consisting of only a single repeating letter would be trivial to write, and it would not need to generate that many candidates compared to the full possible password character space. Which means password cracking tools would already try all these possibilities to score "quick wins".
- arh68 5y agoIn theory, they could be seen as equivalent. In practice, they're not. Your "2,154" speaks to that.
- Slow_Hand 5y agoI have a question about brute-force password cracking or any method that involves rapidly testing a hundred or more possible passwords: What prevents someone from securing the system by putting a limit on the number of login attempts before the application requires a cool down time before it will allow additional attempts? I can't be the first person to have thought of this, so would someone please explain why is this not a viable security strategy?
- phone8675309 5y agoThis is useful strategy in a "yes, and" capacity - take other action AND tarpit login attempts. In some situations, the requirement might be locking the ability of an account to log in after X failed attempts over Y amount of time - say, 3 failed attempts in 5 minutes. Then it's necessary for the user to contact support/the sysadmin to unlock their account.
- pwg 5y ago> What prevents someone from securing the system by putting a limit on the number of login attempts Because, as I stated in another comment in this thread: That is not how passwords are cracked in today's environment. In today's environment, someone obtains (via hacking or bribes) the internal password hash list, and then runs the list through a system such as this one: https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40 https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27... A "try limit" on the login page does nothing to slow this monster down.
- joshxyz 5y agoDefinitely the one with 2fa.