Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Password Requirements: Myths and Madness

franzoni.eu

Post reply on HN
Print view View original

71–80 of 257 posts

Re: Password Requirements: Myths and Madness

#71

Post by Bilal_io »

varenc wrote: post #58
lelandfe wrote: post #53

Earlier quoted context omitted.

https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret They refer to it as a “Memorized Secret“. The appendix, “Strength of Memorized Secrets” is informative rather than a guideline, but I would recommend quoting it too in such discussions: > composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, an…

From this doc: https://pages.nist.gov/800-63-3/sp800-63b.html There’s also this great quote: Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). There’s other great stuff in there as well like that…

Expiring passwords are the bane of my existence. My current job does that. It was originally a requirement by Microsoft and they've been recommending against it, but it catches up slowly.

Re: Password Requirements: Myths and Madness

#72

Post by throwaway0x7E6 »

janalsncm wrote: post #8

> 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.

kinda. 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

Re: Password Requirements: Myths and Madness

#73

Post by Zamicol »

Password strength is:

    Unknown entropy - known entropy = password strength
Where "unknown" entropy is known only to the user and service and "known" entropy is any entropy known by a third party. Since this is an information problem, it should be treated with the tools of information theory, where security is measured by "unknown" entropy. Services have no way to know if a provided string is entropic, since it may be 100% "known" by others. The only way for a service to verify that a password is secure is for the password to include entropy provided by the service. If the user also wanted to validate entropy, it too could provide entropy for mixing in.

This is just a special case of Kolmogorov complexity, and the highest algorithmic entropy for this problem is a random number.

Re: Password Requirements: Myths and Madness

#75

Post by water-your-self »

Zamicol wrote: post #73

Password strength is: Unknown entropy - known entropy = password strength Where "unknown" entropy is known only to the user and service and "known" entropy is any entropy known by a third party. Since this is an information problem, it should be treated with the tools of information theory, where security is measured by "unknown" entropy. Services have no way to know if a provided string is entropic, since it may be…

3 //chosen by dice roll

Re: Password Requirements: Myths and Madness

#76

Post by dalyons »

nulbyte wrote: post #69
csydas wrote: post #52

Earlier quoted context omitted.

> The problem is that the demand isn't being made by security professionals, it's being made by risk management people I'm actually not sure how true this is. There is a huge "security checklist" industry backed by persons with some fancy Security title that provide security analysis checklists for companies to follow, often citing very interesting interpretations of best practices from actual security orgs. These ch…

> - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.

I think you missed the word “similarity”. You can’t check similarity with hashes, only exact matches

Re: Password Requirements: Myths and Madness

#78

Post by koolba »

csydas wrote: post #52
_dan wrote: post #32

In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them…

> The problem is that the demand isn't being made by security professionals, it's being made by risk management people I'm actually not sure how true this is. There is a huge "security checklist" industry backed by persons with some fancy Security title that provide security analysis checklists for companies to follow, often citing very interesting interpretations of best practices from actual security orgs. These ch…

> Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious)

Most systems that allow you to change your password require the current password as a verification. This means the software performing the validation of the new password also has access to your old password and could perform a comparison of the two to see how many characters differ or the overall edit distance.

If only the new password is available, it’s still possible to perform this analysis against older password hashes by simply manipulating the new password and checking if it validates against the old hashes. Possible transformations are replacing any numbers with other digits, e.g. “foobar2” would check “foobar1” through “foobar9”.

Re: Password Requirements: Myths and Madness

#79

Post by Tildey »

water-your-self wrote: post #75
Zamicol wrote: post #73

Password strength is: Unknown entropy - known entropy = password strength Where "unknown" entropy is known only to the user and service and "known" entropy is any entropy known by a third party. Since this is an information problem, it should be treated with the tools of information theory, where security is measured by "unknown" entropy. Services have no way to know if a provided string is entropic, since it may be…

3 //chosen by dice roll

“Your assigned password will be two random words and 2 random numbers”

“Pass”, “word”, “12”, “34”

Re: Password Requirements: Myths and Madness

#80

Post by jlund-molfese »

nulbyte wrote: post #69
csydas wrote: post #52

Earlier quoted context omitted.

> The problem is that the demand isn't being made by security professionals, it's being made by risk management people I'm actually not sure how true this is. There is a huge "security checklist" industry backed by persons with some fancy Security title that provide security analysis checklists for companies to follow, often citing very interesting interpretations of best practices from actual security orgs. These ch…

> - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.

How would that work for password similarity?

If they’re using some special hash algorithm that retains most of the information of the original password and allows them to determine that “password1” and “password2” are similar and “blahblah7” is not, their approach is hopelessly broken too.

Post reply on HN