5 ms·

I think this is a great question and would love to hear a thoughtful, measured, non-snarky response

jawns 9y ago
I wrote a snarky response above, but here's my non-snarky response: It's hard to answer a question phrased this way because there can be any number of reasons why a useful feature is not implemented. Time constraints, budget constraints, process constraints, organizational constraints ... and then somewhere in this long list is, "Gee, we just never thought about it." Perhaps a more interesting question is: Among those of you who believe that providing password requirements up-front is a useful feature, did you implement that feature in past projects? If not, what prevented you from doing so?
- darkerside 9y ago
  For me, it's a combination of "never thought of it" and the difficult of convincing the organization it's not a security risk (yes, it sounds silly).
rockostrich 9y ago
The hypothetical of a manager asking for the feature by the next day is pretty accurate. Besides that, it might be a product or design person that thinks the requirements would clash with the current product/design and don't want to go through another iteration. A better answer to the problem is to not have password requirements because it's the user's responsibility to choose a secure password. If their password is compromised because it was their dog's name or "password1234" then it's their fault. A way to engineer against brute-force hacking is to limit the number of attempted logins per username and IP. If they hit the limit then their account should be locked or their password should be automatically be reset with an email.
- darkerside 9y ago
  > it's the user's responsibility While I agree with you on some level, this is quite contrary to the spirit of our times. Plenty of otherwise smart people have pretty dumb passwords. I'm similarly ignorant of enough things that I don't judge them as simply deserving what they get.
romdev 9y ago
Here's one reason we don't show password requirements on public pages: If a bad guy has to experiment to find the list of available characters and lengths of a password, it's easier to for us good guys to track that behavior. Alternatively, listing the password requirements makes it easier for him to truncate the dictionary for his brute force attacks. If he knows we don't accept ampersands in passwords, he'll remove all passwords with ampersands from his list of 10,000 most common passwords when attacking our site.
- darkerside 9y ago
  He can easily find this out by creating a single account
  - romdev 9y ago
    Most sites require a email address to create an account, leaving a larger footprint for forensics. The sites I work on require much more personal data that is validated against other systems to confirm identity. Out-of-session page requests are scrutinized for patterns that look like a bad guy checking the locks. Granted, many sites will have client side validation for passwords, but that should be considered a user convenience - not a security measure, and doesn't necessarily have to be as strict as the server side validation. New users won't 'accidentally' enter Unicode escape sequences in passwords, but we need to prevent that on the server side validation and show a generic error "your enrollment failed for some reason" so the bad guy doesn't know if it's input validation or personal data validation that failed.
BrinDaxter 9y ago
In my experience, it boils down to these assumptions: 1: if your site is uncluttered -- that is, it hides non-essential information -- it will be more appealing to the user; 2: if your site is following practices common to other sites, the average user will have already learned those practices before coming to your site; 3: if a specific user demonstrates a need for guidance/non-essential information, that information should be made explicitly available. Applied to password requirements: - Show the password field without requirements (uncluttered initial state) - If they enter a valid password, all is well (happy path) - If they enter an invalid password, surface the requirements (explicit guidance)

I wrote a snarky response above, but here's my non-snarky response: It's hard to answer a question phrased this way because there can be any number of reasons why a useful feature is not implemented. Time constraints, budget constraints, process constraints, organizational constraints ... and then somewhere in this long list is, "Gee, we just never thought about it." Perhaps a more interesting question is: Among those of you who believe that providing password requirements up-front is a useful feature, did you implement that feature in past projects? If not, what prevented you from doing so?

darkerside 9y ago
For me, it's a combination of "never thought of it" and the difficult of convincing the organization it's not a security risk (yes, it sounds silly).

rockostrich 9y ago

The hypothetical of a manager asking for the feature by the next day is pretty accurate. Besides that, it might be a product or design person that thinks the requirements would clash with the current product/design and don't want to go through another iteration. A better answer to the problem is to not have password requirements because it's the user's responsibility to choose a secure password. If their password is compromised because it was their dog's name or "password1234" then it's their fault. A way to engineer against brute-force hacking is to limit the number of attempted logins per username and IP. If they hit the limit then their account should be locked or their password should be automatically be reset with an email.

darkerside 9y ago
> it's the user's responsibility While I agree with you on some level, this is quite contrary to the spirit of our times. Plenty of otherwise smart people have pretty dumb passwords. I'm similarly ignorant of enough things that I don't judge them as simply deserving what they get.

romdev 9y ago

Here's one reason we don't show password requirements on public pages: If a bad guy has to experiment to find the list of available characters and lengths of a password, it's easier to for us good guys to track that behavior. Alternatively, listing the password requirements makes it easier for him to truncate the dictionary for his brute force attacks. If he knows we don't accept ampersands in passwords, he'll remove all passwords with ampersands from his list of 10,000 most common passwords when attacking our site.

darkerside 9y ago
He can easily find this out by creating a single account
- romdev 9y ago
  Most sites require a email address to create an account, leaving a larger footprint for forensics. The sites I work on require much more personal data that is validated against other systems to confirm identity. Out-of-session page requests are scrutinized for patterns that look like a bad guy checking the locks. Granted, many sites will have client side validation for passwords, but that should be considered a user convenience - not a security measure, and doesn't necessarily have to be as strict as the server side validation. New users won't 'accidentally' enter Unicode escape sequences in passwords, but we need to prevent that on the server side validation and show a generic error "your enrollment failed for some reason" so the bad guy doesn't know if it's input validation or personal data validation that failed.

BrinDaxter 9y ago

In my experience, it boils down to these assumptions: 1: if your site is uncluttered -- that is, it hides non-essential information -- it will be more appealing to the user; 2: if your site is following practices common to other sites, the average user will have already learned those practices before coming to your site; 3: if a specific user demonstrates a need for guidance/non-essential information, that information should be made explicitly available. Applied to password requirements: - Show the password field without requirements (uncluttered initial state) - If they enter a valid password, all is well (happy path) - If they enter an invalid password, surface the requirements (explicit guidance)