0

I'm currently testing password policies on websites to get a feeling for what might be an acceptable policy/trade-off that provides good protection for our users without frustrating them.

I was surprised to find out that each and every website I tested allowed me to set a password that was equal to my username or e-mail address. If it couldn't be set to the username, it was only because it didn't meet the minimum length requirement. Equal to e-mail address worked every time. Even on sites that had rather strict policies otherwise.

Instinctively, I would think that this is no more secure than using a stupid password, such as "1234" or "password". I'm also pretty sure that NIST SP 800-63B advises against such context-specific passwords (i.e. containing application name, username or user e-mail address). Unfortunately, I cannot verify this claim, as the NIST publication seems to be currently unavailable due to the US government shutdown.

Am I wrong in thinking that such context-specific passwords should be treated in the same manner as "stupid" passwords? If yes, what am I not seeing?

ETA: I'm thinking technical reasons that might make one case not feasible for attackers. I understand there may be non-technical reasons for this, e.g. a product team wanting to allow users to copy & paste their e-mail addresses into both fields to quickly proceed and make a purchase.

Improve this question
3
  • 1
    I'm not sure what you are asking. Are stupid passwords stupid? Yes. Is a website stupid for allowing this type of stupid password? No. Is it a security risk? Yes, but a risk to whom?
    – schroeder ♦
    Jan 18, 2019 at 13:45
  • @schroeder I'm asking why, in many cases, one set of stupid passwords seems to be treated differently than another set. Perhaps there is a technical difference between the two cases that makes one case not feasible for attackers. I personally can't think of any such technical reason, which is why I'm asking. I will amend the question.
    – jgxvx
    Jan 18, 2019 at 14:13
  • 2
    There is no reason except for the development and testing costs.
    – schroeder ♦
    Jan 18, 2019 at 14:16

1 Answer 1

Reset to default
1

You are correct in that the NIST SP 800-63B does advise that verifiers check secrets "against a list that contains values known to be commonly-used, expected, or compromised: .... Context-specific words, such as the name of the service, the username, and derivatives thereof."

From personal experience, I do remember interacting with services which have had this requirement: a Google search for a typical error message ("Passwords must not contain your username") does show that services out there are following NIST advice.

On the topic of implementing NIST, it also recommends against "repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’)". I don't see this implemented as often as other secret verification.

tl;dr: You're not wrong about the NIST specification.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .