4 ms·
> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. Is there a standard metric for “strength” tho
by janalsncm 4y ago
> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length.
Is there a standard metric for “strength” though? I built my own random password generator and considered adding a strength meter but all of the functions I could find online seemed like they had pretty arbitrary logic. Length is probably the most objective proxy for strength.
- chadlavi 4y agoThe author links to a recommended library in the blog post https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
- lucb1e 4y agoI was looking, last week, what to recommend to a customer and ended up at https://github.com/zxcvbn-ts/zxcvbn https://github.com/zxcvbn-ts/zxcvbn because the one from Dropbox seems to be completely abandoned and does not recognize e.g. 2020 as a year. Other alternatives are also welcome if there is an even better one I missed! This was the best password strength estimator I could find.
- cirrus3 4y agoCheck out https://www.grc.com/haystack.htm https://www.grc.com/haystack.htm
- LeoPanthera 4y agoThis particular tool is misleading at best. It counts only characters, and so misleadingly overrates passwords which are strings of words. Compare it with this one, which actually identifies words and other patterns, for a more accurate guess of the search space: https://www.bennish.net/password-strength-checker/ https://www.bennish.net/password-strength-checker/
- cirrus3 4y agoI only said check it out, there is a lot of content there useful to the wider topic and the page clearly states what it is and isn't. >>> IMPORTANT!!! What this calculator is NOT . . . It is NOT a “Password Strength Meter.” Since it could be easily confused for one, it is very important for you to understand what it is, and what it isn't: The #1 most commonly used password is “123456”, and the 4th most common is “Password.” So any password attacker and cracker would try those two passwords immediately. Yet the Search Space Calculator above shows the time to search for those two passwords online (assuming a very fast online rate of 1,000 guesses per second) as 18.52 minutes and 17.33 centuries respectively! If “123456” is the first password that's guessed, that wouldn't take 18.52 minutes. And no password cracker would wait 17.33 centuries before checking to see whether “Password” is the magic phrase. Okay. So what IS the “Search Space Calculator” ? This calculator is designed to help users understand how many passwords can be created from different combinations of character sets (lowercase only, mixed case, with or without digits and special characters, etc.) and password lengths. The calculator then puts the resulting large numbers (with lots of digits or large powers of ten) into a real world context of the time that would be required (assuming differing search speeds) to exhaustively search every password up through that length, assuming the use of the chosen alphabet. How can I apply this to my daily life? Answering that question is the reason this page exists. The whole point of using padded passwords is to adopt a much more you-friendly approach to password design. On June 1st, Leo Laporte and I recorded our weekly Security Now! podcast as part of Leo's TWiT.tv (This Week in Tech) audio and video podcasting network. You may download a shortened, 37-minute, excerpted version presenting the padded password and Haystack calculator concepts:
- LeoPanthera 4y agoMy point is that a "search space calculator" isn't useful. The only thing it will ever achieve is misleading people. Especially as that definition is also wrong, because the search space of a dictionary is achieved by counting words, not letters.
- captn3m0 4y agoNIST standard suggests checking a list of leaked passwords, and setting a length requirement: > Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets. https://pages.nist.gov/800-63-3/sp800-63b.html#sec4 https://pages.nist.gov/800-63-3/sp800-63b.html#sec4
- lucb1e 4y agoPassword strength cannot reliably be measured by looking at a password. To take one common trick: is VpttrvyJptdrNsyyrtu a strong password? It looks pretty okay, definitely less of a pattern than CatName1985, and an estimator like zxcvbn might also not know that it's just CorrectHorseBattery offset by one character on a qwerty keyboard. Now that you know this, you can start to guess my other passwords. Would you still say it is strong now? What if I'm not the only person on the planet using this trick, does that affect it? The strength calculator you're looking for is (technically) the method of generating the password. If you generate 6 random words on a dictionary size of 15'000, that's log(15e3⁶, 2)≃83 bits of entropy. You can only know this by asking the user how they came up with the password, or by telling them to do it a certain way. The rest is just guessing, though I will say that something like zxcvbn does a surprisingly good job at it. The caveat is that the generating method should not have any plausible chance of overlapping with other (insecure) in-use methods. E.g., if you roll a die between zero and a hundred quadrillion and use that as password, most of the time you'll roll a really long number. But if you roll 123123 or 12345678 and use that as password, you can expect it to be cracked. Technically, by excluding "weak" choices from the list of possible values, you are reducing the strength of the password because there are fewer remaining valid guesses, but given how attacks actually work, it makes sense to do this.
- Zamicol 4y agoThere is no way to tell if a password is strong since it may be reused. Instead services should provide a random password so the strength can be known. For example, this is a 128 bit password: CR4EOJ5ZYQRKCGQV4OLN2ZRFS. Since that is a random number provided by the service it has a guaranteed strength of 128 bits. Some in this thread seem to gloss over a vital point: security is measured in bits. The whole character set stuff, "this many characters, special character, must include a number" is meaningless. Instead, a target strength in terms of bits should be specified. That can be represented in whatever base or alphabet as desired. This tool help makes that point: https://convert.zamicol.com/#?inAlph=0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ&in=CR4EOJ5ZYQRKCGQV4OLN2ZRFS&outAlph=01 https://convert.zamicol.com/#?inAlph=0123456789ABCDEFGHIJKLM...
- janalsncm 4y ago> There is no way to tell if a password is strong since it may be reused. Very good point. From that perspective any reported strength can be extremely misleading. As far as bits go, this is where I get a bit lost. Calculating the number of bits only makes sense if the attacker knows what your character set is. Otherwise they will need to iterate over the full set of characters. So a 20 character password of Xs and Ys is just as strong as a 20 character password with lowercase, uppercase, digits, and 10 symbols (72 options) as far as I can tell. The other issue is, even if I have the entropy of the password I don’t know what “strong” really means. Presumably something like logarithm > some value, but that value also seems completely arbitrary.
- Zamicol 4y agoA random 20 character password in base 72 is equivalent to a 124 character password in base 2. They have the same amount of security: 124 bits. https://convert.zamicol.com/#?inAlph=0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz%21%23%24%25%26%28%29%2A%2B-&in=--------------------&outAlph=XY https://convert.zamicol.com/#?inAlph=0123456789ABCDEFGHIJKLM... If a service didn't want to store 124 _bytes_ in a database to represent the above base 2 password, it can use a hashing algorithm to like SHA256 to reduce the storage requirements to 32 bytes. The password still has 124 _bits_ of entropy even though 256 bits are stored. >Calculating the number of bits only makes sense if the attacker knows what your character set is. Assume that the attacker knows the character set in both cases, as this is the worse case scenario. The equivalence is then apparent. >I don’t know what “strong” really means Strength in information theory is entropy, and entropy is measured in bits. https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength https://en.wikipedia.org/wiki/Password_strength#Entropy_as_a...
- throwaway0x7E6 4y agokinda. you can calculate the number of bits of entropy in the password 8 character long alphanumeric lowercase password: (26+10)**8 = 208827064576 possible passwords. 11000010011111000100000010000100000000 in binary = 38 bits of entropy 20 character long upper+lower+numeric+other ASCII password: (26+26+10+32)**20 = 2901062411314618233730627546741369470976. 132 bits of entropy 128 bits of entropy is considered to be enough for all purposes
- janalsncm 4y agoSure, but given a password I have no idea what character set it pulled from. I could have an alphanumeric character set and still randomly generate “aaaaaaaaaa” which is obviously insecure.