Live data from Hacker News

Password Requirements: Myths and Madness

franzoni.eu

91–100 of 257 posts

Re: Password Requirements: Myths and Madness

#91
post #58

Earlier quoted context omitted.

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.

Expiring passwords are the bane of my existence when the period is short. I can live with changing a password once a year, but every three months is only encouraging me to pick weak passwords.

Why can I accept it? I constantly see colleagues sharing passwords and constantly have to say "please don't" when they try to share their password with me. While forcing people to change their passwords doesn't eliminate the underlying problem, it does limit the scope of the damage.

Re: Password Requirements: Myths and Madness

#92
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…

It’s much easier than ever before. You centralize identity to an IDP and require SAML or OAuth for applications. Then you manage it once. Typically you can get rid of most of the password bullshit by adding MFA, with some exceptions. Unless you’re a DoD contractor or handling taxpayer data the came from the IRS on behalf of a client, MFA should meet or exceed compliance requirements.

I’m a small company and the problem with SAML is that it requires the “enterprise” plan for each app. Slack goes from 0 to $11.75/month/user, Miro goes from $8 to $16. Then you have to pay for Okta (Isn’t it $15/u/m?) For a 5-person business it’s $1185 difference + $900 for Okta, and that doesn’t make me SOC2 compliant (There is a bunch of other requirements, secure access to physical offices, logs, etc.).

Re: Password Requirements: Myths and Madness

#93
post #62

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

There 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…

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

Re: Password Requirements: Myths and Madness

#94
The article is correct, most password policies are dumb. But it's arguing about one tree while standing in a forest.

The real problem with passwords is not individual policies, but rather their shere volume. In my password manager I noticed I have got literally hundreds of the things.

Clearly reusing a password on multiple systems is bad. Clearly memorizing more than a handful is impossible. Since I therefore am using a password manager anyway, I simply get it to generate long, random, strings. Which inevitably contain enough to satisfy most daft policies.

There are some I still type. Basically the ones I use everyday, like machine login, but 99% are generated.

I get the article, and for those everyday passwords I advocate the same - make it long, make it easy to type, don't change it.

But if a Web-site wanted to be really secure, require a password manager. (how? I've no idea...)

Re: Password Requirements: Myths and Madness

#95

> 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 e…

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

Re: Password Requirements: Myths and Madness

#96

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…

I know passphrases are better. But, the problem is there's much more to type every time you want to unlock your computer. And thus also many more chances to make a typo. Of course there's TouchID and Windows hello but they don't work if your laptop is closed in a dock. Or in my case a Mac mini at home. This is why I still stick to the truly random sorry password, I have no issues remembering arbitrary strings for som…

Typing a passphrase is so much easier. You already have muscle memory for typing English (or whatever your first language) words. I can type probably type a 60 character passphrase consisting of real words at least as quickly as than I can type a 15 character password with special characters, if not faster.

Re: Password Requirements: Myths and Madness

#98
post #96

Earlier quoted context omitted.

I know passphrases are better. But, the problem is there's much more to type every time you want to unlock your computer. And thus also many more chances to make a typo. Of course there's TouchID and Windows hello but they don't work if your laptop is closed in a dock. Or in my case a Mac mini at home. This is why I still stick to the truly random sorry password, I have no issues remembering arbitrary strings for som…

Typing a passphrase is so much easier. You already have muscle memory for typing English (or whatever your first language) words. I can type probably type a 60 character passphrase consisting of real words at least as quickly as than I can type a 15 character password with special characters, if not faster.

For you maybe, not for me. I'm pretty good with arbitary strings. And I'd only use specials that don't require shift :) It's really much faster and I have RSI so I don't want to type too much.

Luckily my work still allows 10-char with specials or passphrases of 16 and longer without. And don't forget passphrases only benefit in very specific situations such as hash brute forcing. Online attacks already block after a handful of attempts.

Also, the incessant screen locking really annoys me, every time I step away for a coffee my PC is locked again, and this is also at home where my environment is completely secure and I'm the only one living there. I actually work in security but sometimes there is just no reason and it becomes just a barrier.

In the past I used an app to jiggle the mouse every once in a while but that doesn't work anymore. I now made a digispark that does the same in hardware. :) I only use it at home though and it auto-locks my desktop when I leave the house (all my personal ones do too)

If they'd just allow us to use our yubikey + pin it would be so much easier and more secure...

Re: Password Requirements: Myths and Madness

#99
> There's no technical reason for restricting any character from appearing in any password. The usual approach for handling a password is:

> - encode with a specific, well-defined encoding (e.g. utf-8)

Heads up – this is not enough for reliable operation. The same character from an end-user’s perspective can be encoded in multiple ways in UTF-8. So they might register with one platform and then a while later log in with a different platform, and you might receive different string data for their password even though they typed the same thing in both cases.

You might want to consider following RFC 5198 which has more specific requirements, such as encoding to normalisation form C to eliminate issues like this:

https://www.rfc-editor.org/rfc/rfc5198

Re: Password Requirements: Myths and Madness

#100
post #62

Earlier quoted context omitted.

There 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…

> 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 Y…

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

Post reply on HN