4 ms·

Hand-harvesting data is a perfectly legitimate solution, although it comes with a steep initial cost and an ongoing maintenance cost. However, this enables the

Hand-harvesting data is a perfectly legitimate solution, although it comes with a steep initial cost and an ongoing maintenance cost. However, this enables the data to be curated and validated. For this, they wanted to accurately capture the exact rules each site uses, which makes sense to do out-of-band -- ahead of time, and validated by humans -- than to try to discover from the site dynamically, especially because the latter solution, in a world without sites making their own requirements available in a programmatically readable format, would have been complex and brittle. In a program, this sort of data may be hard-coded directly in the code, or dynamically loaded from config files. That's largely an implementation detail.

Bromskloss 9y ago
> a world without sites making their own requirements available in a programmatically readable format About that, is there a standardised way to do it?
- chrismorgan 9y ago
  Not well for arbitrary rules, but for simple syntactic rules at least, regular expressions in the `pattern` attribute of the <input type=password> will do it. Bonus points for using look-ahead assertions for more complex restrictions. The following, for example, creates a password field that requires exactly six ASCII letters, including at least one uppercase and one lowercase letter, and forbidding having the same character twice in a row: <input type=password pattern="(?!.*(.)\1)(?=.*[a-z])(?=.*[A-Z])[A-Za-z]{6}">
  - blattimwind 9y ago
    If your stateless password rules are stronger than a backtracking RE engine, I have bad news for you.
    - deleted 9y ago
      [deleted]
    - chrismorgan 9y ago
      Few password rules can’t be expressed in such a regular expression, but there are definitely some where doing is impractical or absurd. To take an example I’m familiar with, on FastMail and Topicbox we use Dropbox’s zxcvbn (a truly excellent library embodying a sound approach to password security), and flat-out deny passwords that are expected to take less than 10⁶ guesses, as too weak. I shudder to think how many megabytes long a regular expression to validate that would be, and how atrociously it would perform. (Other rules may embed restrictions on use of names, dates, &c. associated with the account. Those may be painful to shoehorn into a regular expression, but doing so is probably generally not too impractical.) Fortunately, the likes of zxcvbn are very password-generator-friendly, as they’re encouraging the sorts of strong passwords password generators like to make; so long as they also have similar accidentally-weak-generated-password protection, zxcvbn is unlikely to cause any trouble and can probably be ignored in defining a pattern for the generator to use. So long as the form uses setCustomValidity to do its complaining when pattern isn’t enough, and the browser’s password generator knows to look at that and try again, you’re good to go. (This is all hypothetical—I don’t believe any tools actually look at password field validation to see if they did the right thing.)
    - rocqua 9y ago
      Isn't best practice to: 1) have a minimal password length 2) check all passwords against a set of known bad passwords I don't see a decent way to do 2) based on a backtracking RE engine.
      - chrismorgan 9y ago
        It’s a terrible approach, but it is easily feasible. Here’s a simplified pattern that forbids “password”, “123”, “1234”, “12345” and “123456”: (?!password$)(?!123(?:4(?:56?)?)?$).*

Bromskloss 9y ago

> a world without sites making their own requirements available in a programmatically readable format About that, is there a standardised way to do it?

chrismorgan 9y ago
Not well for arbitrary rules, but for simple syntactic rules at least, regular expressions in the `pattern` attribute of the <input type=password> will do it. Bonus points for using look-ahead assertions for more complex restrictions. The following, for example, creates a password field that requires exactly six ASCII letters, including at least one uppercase and one lowercase letter, and forbidding having the same character twice in a row: <input type=password pattern="(?!.*(.)\1)(?=.*[a-z])(?=.*[A-Z])[A-Za-z]{6}">
- blattimwind 9y ago
  If your stateless password rules are stronger than a backtracking RE engine, I have bad news for you.
  - deleted 9y ago
    [deleted]
  - chrismorgan 9y ago
    Few password rules can’t be expressed in such a regular expression, but there are definitely some where doing is impractical or absurd. To take an example I’m familiar with, on FastMail and Topicbox we use Dropbox’s zxcvbn (a truly excellent library embodying a sound approach to password security), and flat-out deny passwords that are expected to take less than 10⁶ guesses, as too weak. I shudder to think how many megabytes long a regular expression to validate that would be, and how atrociously it would perform. (Other rules may embed restrictions on use of names, dates, &c. associated with the account. Those may be painful to shoehorn into a regular expression, but doing so is probably generally not too impractical.) Fortunately, the likes of zxcvbn are very password-generator-friendly, as they’re encouraging the sorts of strong passwords password generators like to make; so long as they also have similar accidentally-weak-generated-password protection, zxcvbn is unlikely to cause any trouble and can probably be ignored in defining a pattern for the generator to use. So long as the form uses setCustomValidity to do its complaining when pattern isn’t enough, and the browser’s password generator knows to look at that and try again, you’re good to go. (This is all hypothetical—I don’t believe any tools actually look at password field validation to see if they did the right thing.)
  - rocqua 9y ago
    Isn't best practice to: 1) have a minimal password length 2) check all passwords against a set of known bad passwords I don't see a decent way to do 2) based on a backtracking RE engine.
    - chrismorgan 9y ago
      It’s a terrible approach, but it is easily feasible. Here’s a simplified pattern that forbids “password”, “123”, “1234”, “12345” and “123456”: (?!password$)(?!123(?:4(?:56?)?)?$).*