5 ms·

According to NIST's memorized secret (aka password) guidelines [1]: > When processing requests to establish and change memorized secrets, verifiers SHALL compa

According to NIST's memorized secret (aka password) guidelines [1]: > When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. If Zoom had enforced that passwords can't be from a list of already compromised passwords as this guidance suggests, this attack wouldn't have been nearly as successful. This is just what happens when you don't have a decent security policy, and everyone that doesn't follow basic security best-practices should be called out for it. [1] https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html

mandelbrotwurst 6y ago
Does that guidance get into how such a list should be sourced?
- PureParadigm 6y ago
  It does not name specific sources, but it is not hard to find some. For example, in my programs I check passwords against the API provided by haveibeenpwned.com. More context from the guidance below from https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html > When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to: - Passwords obtained from previous breach corpuses. - Dictionary words. - Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’). - Context-specific words, such as the name of the service, the username, and derivatives thereof. If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.
- thanksforfish 6y ago
  A minimal compliant implementation could likely be ["passw0rd"]. Hopefully most compliant systems try a little harder, but with time and budget pressures... Ideally a modern system should use haveibeenpwned or atleast one of the various lists you can find in password cracking forums.

mandelbrotwurst 6y ago

Does that guidance get into how such a list should be sourced?

PureParadigm 6y ago
It does not name specific sources, but it is not hard to find some. For example, in my programs I check passwords against the API provided by haveibeenpwned.com. More context from the guidance below from https://pages.nist.gov/800-63-3/sp800-63b.html https://pages.nist.gov/800-63-3/sp800-63b.html > When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to: - Passwords obtained from previous breach corpuses. - Dictionary words. - Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’). - Context-specific words, such as the name of the service, the username, and derivatives thereof. If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.
thanksforfish 6y ago
A minimal compliant implementation could likely be ["passw0rd"]. Hopefully most compliant systems try a little harder, but with time and budget pressures... Ideally a modern system should use haveibeenpwned or atleast one of the various lists you can find in password cracking forums.