Earlier quoted context omitted.
You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
I have had trouble convincing people before, would you happen to have a link ?
[deleted]
Password Requirements: Myths and Madness
61–70 of 257 posts
Re: Password Requirements: Myths and Madness
#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 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=0123456789ABCDEFGHIJKLM...
Re: Password Requirements: Myths and Madness
#63Earlier quoted context omitted.
> > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. > Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use…
Correct, but the recommendation in the article is still wrong. If I get a password that has four Unicode characters in it, it's possible that it's a strong password that chose truly randomly from the available Unicode characters, but it's much more likely that someone just picked four that they like. In the latter case, the bits per character is going to be much lower, but I can't tell the difference just looking at…
> but it's much more likely that someone just picked four that they like
Or as I would call it, the fallacy of uniformity. The author assumes that hackers would only try a dictionary attack using lower case letters, but this is no longer true since mid-2010s. Some dictionaries geared for international services also have non-Latin characters since not all countries restrict passwords to alphanumerics.
Re: Password Requirements: Myths and Madness
#64In 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…
You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.
NIST is pretty good to convince people
Re: Password Requirements: Myths and Madness
#65In 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.
Re: Password Requirements: Myths and Madness
#66In 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…
B2B is worse because EVERYONE shares business accounts with other people at the business. And so the usernames passwords and even two factor setups are passed around like coffee.
“Oh use bobs login for that, the standard password but add a ! for reasons”
Re: Password Requirements: Myths and Madness
#67Re: Password Requirements: Myths and Madness
#68> when trying to login, the "enter your password" field isn't got the same limitations, and you cannot login because you're using the wrong (too-long) password
> You cannot paste into this field
If I may self-promote, my web browser extension StopTheMadness solves both of these problems. https://underpassapp.com/StopTheMadness/
Re: Password Requirements: Myths and Madness
#69In 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)
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.
Re: Password Requirements: Myths and Madness
#70In 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.
[deleted]