7 ms·

I think it is great that this proposal is almost done getting through the process. I also think there should be a similar file for the regular expression that

I think it is great that this proposal is almost done getting through the process. I also think there should be a similar file for the regular expression that expresses a site’s allowable passwords.

Someone1234 7y ago
If you had a machine readable definition for what is allowed within a password, wouldn't it make more sense to put that close to the password entry itself (e.g. on the input element/page)? Having a site-wide definition seems like it would require a lot of mechanics to target specifc pages or properties that may have different rules (e.g. consumer Vs. corporate logins). I still hope companies start following NIST guidelines and stop having password rules entirely.
- mjevans 7y ago
  I like the idea of a tiered approach so that this could be bolted on to legacy systems where necessary. Website wide obviously being over-ruled by local over-rides.
- lilyball 7y ago
  The input tag already has a 'pattern' attribute that is a regex that the input must match to be valid.
linsomniac 7y ago
I love this idea, though I'm not sure I want my password manager executing arbitrary regexes it finds on the Internet.
- saagarjha 7y ago
  If you restrict it to “formal” regular expressions you’ll stay out of “arbitrary code executing on a Turing machine”.
  - wahern 7y ago
    Regular expression engines are notoriously buggy. You definitely wouldn't want to pass random expressions to libpcre. Web browsers are already running random expressions from the internet, but their regex implementations have proven the rule by being fodder from exploit writers. In any event, requiring a password manager to pull the engine from Firefox or Chrome wouldn't be cool. They're more likely to use libpcre or re2, but see above. The NAPTR DNS record type uses regular expressions for domain rewriting: https://en.wikipedia.org/wiki/NAPTR_record https://en.wikipedia.org/wiki/NAPTR_record Not many DNS libraries support that record type as it adds alot of problematic bloat.
    - saagarjha 7y ago
      libpcre is exactly the implementation I’m not talking about, because it supports too much. I think re2 doesn’t do backtracking, so it’s probably a better choice.
      - wahern 7y ago
        You can still easily blow up memory with unions, which makes it easy to lock up Linux, which notoriously performs poorly under memory pressure.
        saagarjha 7y ago
        Just set a memory limit on the process.
        lilyball 7y ago
        A non-backtracking regex engine like re2 should be linear with respect to the regex size and can be configured with a memory budget.
        wahern 7y ago
        The number of DFA states can explode exponentially. It's a real problem, especially if you're compiling untrusted expressions off the internet. Evaluation is linear, but you're just evaluating your own password. In this scenario, it may make sense to just use a simple backtracking implementation, though as you alluded to early there aren't many simple ones around.
- daxelrod 7y ago
  Counterpoint: if you allow your browser to run JavaScript, it’s already executing arbitrary regexes it finds on the Internet.
  - closeparen 7y ago
    The browser is, the passwords manager is on the other end of an IPC mechanism with a hopefully small and well-defined interface.
    - daxelrod 7y ago
      My point is that it is possible for your password manager to sandbox regex execution at least as well as your browser does. I totally agree with your concerns about scope creep increasing the attack surface.
- ben509 7y ago
  But it's not executing a match, it's creating a random password picker. That's exactly equivalent to parsing the pattern where the actions on terminals are to generate random characters.
ibly31 7y ago
Wouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space. To save (potentially rate limited) requests, the ripper software could compare the regex against a candidate password and skip it altogether. It's like expressing in machine-readable form how many/which characters they can skip.
- hwbehrens 7y ago
  I would say in general, no. For a long time, American Express had something along the lines of `^[A-z0-9]{6,8}$`. Given a candidate string, evaluating even this extremely basic regex will take more time than comparing it against a hash table. I suppose you could flip it around and use it as a generator for an arbitrary dictionary, but then you'll run into memory limitations first. Plus, there's always the fact that an adversary can just, you know, go find the password requirements on the website and generate a matching regex themselves. Of course, if the regex is something like `^password$`...
  - Beldin 7y ago
    If you have the regex, you'd use it to generate candidate strings. Then, of course you don't have to check any more. For a more complex regex, you could resort to a simplified version (eg, with larger search space). But the space of all random strings is way too huge to just generate random bitstrings and hope they match the regex.
- Johnny555 7y ago
  Wouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space. If knowing the rules for acceptable passwords makes it significantly easier to brute force passwords, that sounds like more of an argument to not have those rules in the first place since it wouldn't take an attacker long to figure them out himself even if they aren't published. Hiding the password policy is a very weak form of security through obscurity. I guess it would make it easier to programmatically determine which websites have insecure passoword policies (like an alphanumeric passsword no more than 8 characters long), but the problem here is the password policy, not publishing the rules. Even the NIST recommends that sites stop requiring these arbitrary password rules as they don't actually improve password security: https://www.alvaka.net/new-password-guidelines-us-federal-government-via-nist/ https://www.alvaka.net/new-password-guidelines-us-federal-go...
deleted 7y ago
[deleted]
mtmail 7y ago
There's a similar proposal to allow password manager to change passwords. https://mikewest.github.io/change-password/ https://mikewest.github.io/change-password/ (https://www.kryogenix.org/days/2017/02/24/a-standard-password-change-api/ https://www.kryogenix.org/days/2017/02/24/a-standard-passwor...)
- prophesi 7y ago
  I was about to post that. I really hope this proposal goes through. It's still difficult to keep up with password rotation.
- Avamander 7y ago
  Where is the proposal being discussed more actively? Some mailing list?
packet_nerd 7y ago
> I also think there should be a similar file for the regular expression that expresses a site’s allowable passwords. I disagree. Password "complexity" requirements need to die and instead every site's password regex should be `.{12,64}` and then verify it's not in the dictionary or a list of leaked passwords.
all_blue_chucks 7y ago
The current thinking among the security community is that sites should allow all passwords that aren't found on a wordlist, so that would be one hell of a regex.
edent 7y ago
There doesn't need to be a file. The HTML5 specification allows the password input to include a validation regex. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/password#Validation https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Someone1234 7y ago

If you had a machine readable definition for what is allowed within a password, wouldn't it make more sense to put that close to the password entry itself (e.g. on the input element/page)? Having a site-wide definition seems like it would require a lot of mechanics to target specifc pages or properties that may have different rules (e.g. consumer Vs. corporate logins). I still hope companies start following NIST guidelines and stop having password rules entirely.

mjevans 7y ago
I like the idea of a tiered approach so that this could be bolted on to legacy systems where necessary. Website wide obviously being over-ruled by local over-rides.
lilyball 7y ago
The input tag already has a 'pattern' attribute that is a regex that the input must match to be valid.

linsomniac 7y ago

I love this idea, though I'm not sure I want my password manager executing arbitrary regexes it finds on the Internet.

saagarjha 7y ago
If you restrict it to “formal” regular expressions you’ll stay out of “arbitrary code executing on a Turing machine”.
- wahern 7y ago
  Regular expression engines are notoriously buggy. You definitely wouldn't want to pass random expressions to libpcre. Web browsers are already running random expressions from the internet, but their regex implementations have proven the rule by being fodder from exploit writers. In any event, requiring a password manager to pull the engine from Firefox or Chrome wouldn't be cool. They're more likely to use libpcre or re2, but see above. The NAPTR DNS record type uses regular expressions for domain rewriting: https://en.wikipedia.org/wiki/NAPTR_record https://en.wikipedia.org/wiki/NAPTR_record Not many DNS libraries support that record type as it adds alot of problematic bloat.
  - saagarjha 7y ago
    libpcre is exactly the implementation I’m not talking about, because it supports too much. I think re2 doesn’t do backtracking, so it’s probably a better choice.
    - wahern 7y ago
      You can still easily blow up memory with unions, which makes it easy to lock up Linux, which notoriously performs poorly under memory pressure.
      - saagarjha 7y ago
        Just set a memory limit on the process.
      - lilyball 7y ago
        A non-backtracking regex engine like re2 should be linear with respect to the regex size and can be configured with a memory budget.
        wahern 7y ago
        The number of DFA states can explode exponentially. It's a real problem, especially if you're compiling untrusted expressions off the internet. Evaluation is linear, but you're just evaluating your own password. In this scenario, it may make sense to just use a simple backtracking implementation, though as you alluded to early there aren't many simple ones around.
daxelrod 7y ago
Counterpoint: if you allow your browser to run JavaScript, it’s already executing arbitrary regexes it finds on the Internet.
- closeparen 7y ago
  The browser is, the passwords manager is on the other end of an IPC mechanism with a hopefully small and well-defined interface.
  - daxelrod 7y ago
    My point is that it is possible for your password manager to sandbox regex execution at least as well as your browser does. I totally agree with your concerns about scope creep increasing the attack surface.
ben509 7y ago
But it's not executing a match, it's creating a random password picker. That's exactly equivalent to parsing the pattern where the actions on terminals are to generate random characters.

ibly31 7y ago

Wouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space. To save (potentially rate limited) requests, the ripper software could compare the regex against a candidate password and skip it altogether. It's like expressing in machine-readable form how many/which characters they can skip.

hwbehrens 7y ago
I would say in general, no. For a long time, American Express had something along the lines of `^[A-z0-9]{6,8}$`. Given a candidate string, evaluating even this extremely basic regex will take more time than comparing it against a hash table. I suppose you could flip it around and use it as a generator for an arbitrary dictionary, but then you'll run into memory limitations first. Plus, there's always the fact that an adversary can just, you know, go find the password requirements on the website and generate a matching regex themselves. Of course, if the regex is something like `^password$`...
- Beldin 7y ago
  If you have the regex, you'd use it to generate candidate strings. Then, of course you don't have to check any more. For a more complex regex, you could resort to a simplified version (eg, with larger search space). But the space of all random strings is way too huge to just generate random bitstrings and hope they match the regex.
Johnny555 7y ago
Wouldn't this just make password crackers easier? If there's a Regex of what passwords are okay, it lowers the search space. If knowing the rules for acceptable passwords makes it significantly easier to brute force passwords, that sounds like more of an argument to not have those rules in the first place since it wouldn't take an attacker long to figure them out himself even if they aren't published. Hiding the password policy is a very weak form of security through obscurity. I guess it would make it easier to programmatically determine which websites have insecure passoword policies (like an alphanumeric passsword no more than 8 characters long), but the problem here is the password policy, not publishing the rules. Even the NIST recommends that sites stop requiring these arbitrary password rules as they don't actually improve password security: https://www.alvaka.net/new-password-guidelines-us-federal-government-via-nist/ https://www.alvaka.net/new-password-guidelines-us-federal-go...

deleted 7y ago

[deleted]

mtmail 7y ago

There's a similar proposal to allow password manager to change passwords. https://mikewest.github.io/change-password/ https://mikewest.github.io/change-password/ (https://www.kryogenix.org/days/2017/02/24/a-standard-password-change-api/ https://www.kryogenix.org/days/2017/02/24/a-standard-passwor...)

prophesi 7y ago
I was about to post that. I really hope this proposal goes through. It's still difficult to keep up with password rotation.
Avamander 7y ago
Where is the proposal being discussed more actively? Some mailing list?

packet_nerd 7y ago

> I also think there should be a similar file for the regular expression that expresses a site’s allowable passwords. I disagree. Password "complexity" requirements need to die and instead every site's password regex should be `.{12,64}` and then verify it's not in the dictionary or a list of leaked passwords.

all_blue_chucks 7y ago

The current thinking among the security community is that sites should allow all passwords that aren't found on a wordlist, so that would be one hell of a regex.

edent 7y ago

There doesn't need to be a file. The HTML5 specification allows the password input to include a validation regex. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/password#Validation https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...