7 ms·

A couple more: 1) Do not limit the length of the password to some arbitrarily small number. 2) Do not validate email beyond the simplest, "includes an @ and a

by lbayes 5y ago

A couple more: 1) Do not limit the length of the password to some arbitrarily small number. 2) Do not validate email beyond the simplest, "includes an @ and a period. Email is validated by sending a confirmation link. 3) Don't get so stupid with the "secure password" special character crap. Some of us use super long, but memorable passwords, which are more secure than your bull#@!+&$

Jenk 5y ago
PCI DSS compliance is shit at this. Enforced 90 day cycles, mixed casing, alpha, numeric, and "special" characters. The only halfway sane policies they enforce are must not match username, and mustn't be a dictionary word (singular), and minimum length of 7.
- gjvnq 5y ago
  Simple solution: have a password but allow your users to login via TOTP only.
- Terretta 5y ago
  Push back on PCI DSS by showing you’re NIST compliant, which is generally considered higher grade and acceptable. Sharing details, as many “sacred cows” are slain: - User-generated passwords should be at least 8 characters in length - Machine-generated passwords should be at least 6 characters in length - Users should be able to create passwords up to at least 64 characters - All ASCII/Unicode characters should be allowed, including emojis and spaces - Stored passwords should be hashed and salted, and never truncated - Prospective passwords should be compared against password breach databases and rejected if there’s a match - Passwords should not expire - Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters - Two-factor authentication (2FA) should not use SMS for codes - Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used - Users should be allowed 10 failed password attempts before being locked out of a system or service - Passwords should not have hints - Complexity requirements should not be used, ex. requiring special characters, numbers, uppercase, etc. - Context-specific words, such as the name of the service, the user’s username, etc. should not be permitted https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html
  - Silhouette 5y ago
    That's not a bad list and for regulatory purposes maybe it makes sense to use it, but it has its own limitations. - Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters This one can be counterproductive for the same reasons as the complexity requirements that this list prohibits. It reduces the space of available passwords and might block a strong but memorable password that coincidentally has an invalid subsequence somewhere in it. - Two-factor authentication (2FA) should not use SMS for codes This has its problems but depending on the situation you might have few alternatives available and some form of 2FA might still be much better than none. Apparently my government, my bank, and several well-known online services all share this view.
    - Terretta 5y ago
      Apparently doesn’t mean secure. Most likely, the bank is doing it wrong because of bad old policies and lack of security education in the security and risk groups. The well known online services use your number to tie to data broker feeds. Not sure about your government, but likely inertia and misinformation. Disclosure/disclaimer: megabank CTO opinions are my own
      - Silhouette 5y ago
        The question isn't whether it's secure. Complete security is a work of fiction anyway. The real question is whether it's significantly more secure. As of today, probably 3/4 or more of the online services I use that have serious security requirements are favouring SMS-based 2FA over just using ID and password as they used to. This can get a bit annoying, but it's obviously more secure than not doing it.
cnlevy 5y ago
3) obligatory xkcd https://xkcd.com/936/ https://xkcd.com/936/
- 026bfdf903b15 5y ago
  That's one of the worst comics they have. Even though they might be correct with the theoretical entropy, but I doubt that Tr0ub4dor&3 is much easier to crack than correcthorsebatterystaple since dictionary attacks exist. Why not make it long AND hard (h3h3h3h3^_^xD)? Password managers are easy to use and very comfortable. If you want to go further get a Yubikey. I love keepassxc
  - dogface01 5y ago
    We must secure the existence of our people and a future for white children.
  - InitialBP 5y ago
    I don't think correcthorsebatterystaple is easier to crack than the Troubador variation. Hash cracking often includes the use of a wordlist and a ruleset which builds variations on the words from a wordlist. Some common ones I use for my job are OneRule and Hob0Rules. Notably I did run the word "troubador" through these and did not get the final result of "Tr0ub4dor&3" but they did both produce "Tr0ub4dor". These rulesets both produce > 50k passwords from a single word to guess so it's not outside the realm of possibility to have more/better rulesets that are used. On the other hand, while it's definitely feasible to take a wordlist and make random permutations of sticking words together, I think in general that sort of password is used less often. 100% Agree password managers are the way to go, but for people that aren't using them I would definitely suggest long/multiple random words together over short LEETspeek with special char number tacked onto the end style password. https://github.com/NotSoSecure/password_cracking_rules https://github.com/NotSoSecure/password_cracking_rules https://github.com/praetorian-inc/Hob0Rules https://github.com/praetorian-inc/Hob0Rules
GrumpyNl 5y ago
Better, dont use passwords at all.
- colinclerk 5y ago
  As a counterpoint here, email- or sms-based passwordless flows can be quite slow to complete. We (clerk.dev) are seeing ~35 seconds for passwordless, ~8 for passwords, ~5 for Social Sign In: https://www.clerk.dev/blog/designing-fast-sign-in-forms https://www.clerk.dev/blog/designing-fast-sign-in-forms We're excited for other factors to gain more prominence (e.g TOTP, face id, touch id), but in the current world it's hard to recommend against a password factor, as long as you're following NIST guidelines to compare against password breach corpuses.
jmilloy 5y ago
I at least need a reminder of what your specific special character and length requirements on the login page.
_0ffh 5y ago
Also, don't restrict allowed characters unnecessarily. It's just stupid to have "Use special characters, but only !$() and _ are allowed!". God, why?
- daveFNbuck 5y ago
  Also, do restrict allowed characters when necessary. If one of your apps doesn't allow me to input a particular special character in the password field, don't allow me to have that character in my password.
  - InitialBP 5y ago
    What kind of situation occurs where you can't input special characters in a password field? I think in general the advice is that there should not be any limitations on special characters anywhere in the tech stack at all. (Including a broken UI that won't let you input special characters.) The situation you described sounds more to me like a very poorly written application.
    - unilynx 5y ago
      There's one restriction you should do, trim spaces from the start and end of a password (or any input field, for that matter, unless there's a good reason not to). People copy/pasting from emails or Word documents are good at accidentally picking up spaces.
    - daveFNbuck 5y ago
      Sometimes the device you're logging in with doesn't have the full range of character sets available. This has happened to me with set-top boxes in the past.
- technotarek 5y ago
  I’ve always assumed this was a reserved character escaping issue that a dev didn’t want to tackle.
- jedberg 5y ago
reaperducer 5y ago
1) Do not limit the length of the password to some arbitrarily small number. I got bit by this recently. I decided to update my Bank of America password, and so generated a 30-character password. Bank of America's password change page accepted the 30 character password. But then I couldn't log in because Bank of America's login page won't allow passwords longer than 20 characters. I ended up having to call Bank of America on the phone and the rude web site tech guy said that he's been there 10 years, and 20 characters has always been the limit. 1 - If that's true, then don't let me change my password to 30 characters. 2 - Why would a bank insist on a password scheme that is clearly LESS secure than a reasonable alternative.
ecesena 5y ago
To expand on 3), if you really need it, make sure your rule works with Chrome/Safari autogenerated passwords.
shezi 5y ago
There was a django security issue where password length lead to a possible DOS attack against the server. So now they limit passwords rather arbitrarily to 4096 bytes. https://www.djangoproject.com/weblog/2013/sep/15/security/ https://www.djangoproject.com/weblog/2013/sep/15/security/
cratermoon 5y ago
> Do not validate email Full stop. Require email confirmation to complete signup. If the address can receive email, it's valid, it doesn't matter what's in it.
quesera 5y ago
> "includes an @ and a period ... Periods are not required, either!

by lbayes 5y ago

Jenk 5y ago

PCI DSS compliance is shit at this. Enforced 90 day cycles, mixed casing, alpha, numeric, and "special" characters. The only halfway sane policies they enforce are must not match username, and mustn't be a dictionary word (singular), and minimum length of 7.

gjvnq 5y ago
Simple solution: have a password but allow your users to login via TOTP only.
Terretta 5y ago
Push back on PCI DSS by showing you’re NIST compliant, which is generally considered higher grade and acceptable. Sharing details, as many “sacred cows” are slain: - User-generated passwords should be at least 8 characters in length - Machine-generated passwords should be at least 6 characters in length - Users should be able to create passwords up to at least 64 characters - All ASCII/Unicode characters should be allowed, including emojis and spaces - Stored passwords should be hashed and salted, and never truncated - Prospective passwords should be compared against password breach databases and rejected if there’s a match - Passwords should not expire - Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters - Two-factor authentication (2FA) should not use SMS for codes - Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used - Users should be allowed 10 failed password attempts before being locked out of a system or service - Passwords should not have hints - Complexity requirements should not be used, ex. requiring special characters, numbers, uppercase, etc. - Context-specific words, such as the name of the service, the user’s username, etc. should not be permitted https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html
- Silhouette 5y ago
  That's not a bad list and for regulatory purposes maybe it makes sense to use it, but it has its own limitations. - Users should be prevented from using sequential (ex. “1234”) or repeated (ex. “aaaa”) characters This one can be counterproductive for the same reasons as the complexity requirements that this list prohibits. It reduces the space of available passwords and might block a strong but memorable password that coincidentally has an invalid subsequence somewhere in it. - Two-factor authentication (2FA) should not use SMS for codes This has its problems but depending on the situation you might have few alternatives available and some form of 2FA might still be much better than none. Apparently my government, my bank, and several well-known online services all share this view.
  - Terretta 5y ago
    Apparently doesn’t mean secure. Most likely, the bank is doing it wrong because of bad old policies and lack of security education in the security and risk groups. The well known online services use your number to tie to data broker feeds. Not sure about your government, but likely inertia and misinformation. Disclosure/disclaimer: megabank CTO opinions are my own
    - Silhouette 5y ago
      The question isn't whether it's secure. Complete security is a work of fiction anyway. The real question is whether it's significantly more secure. As of today, probably 3/4 or more of the online services I use that have serious security requirements are favouring SMS-based 2FA over just using ID and password as they used to. This can get a bit annoying, but it's obviously more secure than not doing it.

cnlevy 5y ago

3) obligatory xkcd https://xkcd.com/936/ https://xkcd.com/936/

026bfdf903b15 5y ago
That's one of the worst comics they have. Even though they might be correct with the theoretical entropy, but I doubt that Tr0ub4dor&3 is much easier to crack than correcthorsebatterystaple since dictionary attacks exist. Why not make it long AND hard (h3h3h3h3^_^xD)? Password managers are easy to use and very comfortable. If you want to go further get a Yubikey. I love keepassxc
- dogface01 5y ago
  We must secure the existence of our people and a future for white children.
- InitialBP 5y ago
  I don't think correcthorsebatterystaple is easier to crack than the Troubador variation. Hash cracking often includes the use of a wordlist and a ruleset which builds variations on the words from a wordlist. Some common ones I use for my job are OneRule and Hob0Rules. Notably I did run the word "troubador" through these and did not get the final result of "Tr0ub4dor&3" but they did both produce "Tr0ub4dor". These rulesets both produce > 50k passwords from a single word to guess so it's not outside the realm of possibility to have more/better rulesets that are used. On the other hand, while it's definitely feasible to take a wordlist and make random permutations of sticking words together, I think in general that sort of password is used less often. 100% Agree password managers are the way to go, but for people that aren't using them I would definitely suggest long/multiple random words together over short LEETspeek with special char number tacked onto the end style password. https://github.com/NotSoSecure/password_cracking_rules https://github.com/NotSoSecure/password_cracking_rules https://github.com/praetorian-inc/Hob0Rules https://github.com/praetorian-inc/Hob0Rules

GrumpyNl 5y ago

Better, dont use passwords at all.

colinclerk 5y ago
As a counterpoint here, email- or sms-based passwordless flows can be quite slow to complete. We (clerk.dev) are seeing ~35 seconds for passwordless, ~8 for passwords, ~5 for Social Sign In: https://www.clerk.dev/blog/designing-fast-sign-in-forms https://www.clerk.dev/blog/designing-fast-sign-in-forms We're excited for other factors to gain more prominence (e.g TOTP, face id, touch id), but in the current world it's hard to recommend against a password factor, as long as you're following NIST guidelines to compare against password breach corpuses.

jmilloy 5y ago

I at least need a reminder of what your specific special character and length requirements on the login page.

_0ffh 5y ago

Also, don't restrict allowed characters unnecessarily. It's just stupid to have "Use special characters, but only !$() and _ are allowed!". God, why?

daveFNbuck 5y ago
Also, do restrict allowed characters when necessary. If one of your apps doesn't allow me to input a particular special character in the password field, don't allow me to have that character in my password.
- InitialBP 5y ago
  What kind of situation occurs where you can't input special characters in a password field? I think in general the advice is that there should not be any limitations on special characters anywhere in the tech stack at all. (Including a broken UI that won't let you input special characters.) The situation you described sounds more to me like a very poorly written application.
  - unilynx 5y ago
    There's one restriction you should do, trim spaces from the start and end of a password (or any input field, for that matter, unless there's a good reason not to). People copy/pasting from emails or Word documents are good at accidentally picking up spaces.
  - daveFNbuck 5y ago
    Sometimes the device you're logging in with doesn't have the full range of character sets available. This has happened to me with set-top boxes in the past.
technotarek 5y ago
I’ve always assumed this was a reserved character escaping issue that a dev didn’t want to tackle.
jedberg 5y ago

reaperducer 5y ago

1) Do not limit the length of the password to some arbitrarily small number. I got bit by this recently. I decided to update my Bank of America password, and so generated a 30-character password. Bank of America's password change page accepted the 30 character password. But then I couldn't log in because Bank of America's login page won't allow passwords longer than 20 characters. I ended up having to call Bank of America on the phone and the rude web site tech guy said that he's been there 10 years, and 20 characters has always been the limit. 1 - If that's true, then don't let me change my password to 30 characters. 2 - Why would a bank insist on a password scheme that is clearly LESS secure than a reasonable alternative.

ecesena 5y ago

To expand on 3), if you really need it, make sure your rule works with Chrome/Safari autogenerated passwords.

shezi 5y ago

There was a django security issue where password length lead to a possible DOS attack against the server. So now they limit passwords rather arbitrarily to 4096 bytes. https://www.djangoproject.com/weblog/2013/sep/15/security/ https://www.djangoproject.com/weblog/2013/sep/15/security/

cratermoon 5y ago

> Do not validate email Full stop. Require email confirmation to complete signup. If the address can receive email, it's valid, it doesn't matter what's in it.

quesera 5y ago

> "includes an @ and a period ... Periods are not required, either!