4 ms·

I use KeePass to store all of my (randomly generated) passwords. One ongoing annoyance is that it's increasingly difficult to generate a random string will be

I use KeePass to store all of my (randomly generated) passwords. One ongoing annoyance is that it's increasingly difficult to generate a random string will be meet a given site's Dumb Password Rules, because so many sites have them, and there's surprisingly little overlap in the rules. I would really like to see a database of sites and their corresponding Dumb Password Rules, so that I can tell KeePass (or any other app using the database) to generate me a new Mindware password, or a new Williams-Sonoma password, and get a random string that conforms to all the relevant DPRs.

jjnoakes 10y ago
KeePass should let users configure a pattern for passwords, like "8-25 letters or numbers or these symbols, must have 1 uppercase letter", and just replicate that socially (the pair of web site and pattern) across all KeePass users.
- scrapcode 10y ago
  Sounds like a good idea at first, but could also be a huge attack point.
  - Bartweiss 10y ago
    The "replicate" bit sounds deeply alarming - a password manager using social or learned rules just screams vulnerability. If you made me guess an attack, I'd picture someone paying for a server cluster or botnet to repeatedly assert super-restrictive rules, and then use their knowledge of those rules to guess the generated passwords. Allowing some basic rule-setting, though, sounds quite nice. Arbitrary restrictions will probably leave people setting bad passwords, but there are some very common flags like "must have a special character" or "can't have a special character" that it'd be convenient to access for these sites.
- tacostakohashi 10y ago
  Sure, but there are other password managers with this same problem. I'm suggesting something more like the tz database - a common, authoritative source of truth for any password generator / database app to use. Just like the tz database, it would require some maintenance, but I think it would be worthwhile (yes, I would volunteer to maintain it, if others were to volunteer to add support for same in the various keepass implementations I use).
- Bartweiss 10y ago
  Even without the social aspect, it would be nice to just have some common flags you can set like "uppercase required, special characters banned" when generating for a specific site.
- WorldMaker 10y ago
  It does let you configure a pattern and even save the pattern for reuse. It's the replicate socially that's not implemented. Might be a fun idea for a KeePass plugin.
tzs 10y ago
What I think we need is a standard for documenting password requirements and restrictions on the password entry page itself, in a format that is easily parsed and understood by software. Password managers that have browser integration could then use this to generate passwords acceptable to the site. For password managers without browser integration, I bookmarklet could be developed that extracts the password format information and makes it available in a form that can be copy/pasted to the password manager, which could then remember it along with the other data for the site. There are at least three ways that seem reasonable that could be used to convey the necessary information. 1. Make use of already defined attributes of the <input type="password"> field. In particular, there are three existing attributes that are very relevant: • minlength: the minimum allowed length of input, • maxlength: the maximum allowed length of input, • pattern: a regular expression that the password must match. By using lookahead matching in the regular expression, you can express rules like "must have at least one upper case English letter, one lower case English letter, one digit, and one special character chosen from @!#$%^&()". For example, pattern="(?=.[A-Z])(?=.[a-z])(?=.[0-9])(?=.[@!#$%^&()])". A downside to this is that expressing the rules as a regular expression does not make it easy for a program like a password manager to understand it. It makes it easy for a password manager to apply it to a give password, but that isn't super helpful when it comes to generating a new password. So that argues for some other way to convent this information, bringing us to... 2. Add a new attribute to some tag to convey this information. In HTML5, it is legal (as in doing so does not make the HTML invalid) to add custom tags if their name starts with "data-". A "data-format" tag could be added to the password input field, with its value being in some industry agreed upon format. In prior versions of HTML, doing that would break HTML in the sense that it would not conform to the DTD. Not many programs actually care if what they are given as HTML conforms to the DTD, but those can be kept happy be a slight change to the DOCTYPE declaration. Usually the DOCTYPE declaration just contains references to external documents that contain the definitions that actually make up the DTD for the document. You can also put DTD definitions right inside the DOCTYPE declaration. To make our new data-format attribute legal, all we need to do is append the appropriate definition in the DOCTYPE after the list of external references.
- tacostakohashi 10y ago
  You think that sites that are unable to come up with sensible password rules will be able to get this right, on a large enough scale to make it useful? In terms of the metadata, you've more or less covered it, but the only way it has a hope of being useful is if it's provided by some community-minded third party.

jjnoakes 10y ago

KeePass should let users configure a pattern for passwords, like "8-25 letters or numbers or these symbols, must have 1 uppercase letter", and just replicate that socially (the pair of web site and pattern) across all KeePass users.

scrapcode 10y ago
Sounds like a good idea at first, but could also be a huge attack point.
- Bartweiss 10y ago
  The "replicate" bit sounds deeply alarming - a password manager using social or learned rules just screams vulnerability. If you made me guess an attack, I'd picture someone paying for a server cluster or botnet to repeatedly assert super-restrictive rules, and then use their knowledge of those rules to guess the generated passwords. Allowing some basic rule-setting, though, sounds quite nice. Arbitrary restrictions will probably leave people setting bad passwords, but there are some very common flags like "must have a special character" or "can't have a special character" that it'd be convenient to access for these sites.
tacostakohashi 10y ago
Sure, but there are other password managers with this same problem. I'm suggesting something more like the tz database - a common, authoritative source of truth for any password generator / database app to use. Just like the tz database, it would require some maintenance, but I think it would be worthwhile (yes, I would volunteer to maintain it, if others were to volunteer to add support for same in the various keepass implementations I use).
Bartweiss 10y ago
Even without the social aspect, it would be nice to just have some common flags you can set like "uppercase required, special characters banned" when generating for a specific site.
WorldMaker 10y ago
It does let you configure a pattern and even save the pattern for reuse. It's the replicate socially that's not implemented. Might be a fun idea for a KeePass plugin.

tzs 10y ago

What I think we need is a standard for documenting password requirements and restrictions on the password entry page itself, in a format that is easily parsed and understood by software. Password managers that have browser integration could then use this to generate passwords acceptable to the site. For password managers without browser integration, I bookmarklet could be developed that extracts the password format information and makes it available in a form that can be copy/pasted to the password manager, which could then remember it along with the other data for the site. There are at least three ways that seem reasonable that could be used to convey the necessary information. 1. Make use of already defined attributes of the <input type="password"> field. In particular, there are three existing attributes that are very relevant: • minlength: the minimum allowed length of input, • maxlength: the maximum allowed length of input, • pattern: a regular expression that the password must match. By using lookahead matching in the regular expression, you can express rules like "must have at least one upper case English letter, one lower case English letter, one digit, and one special character chosen from @!#$%^&()". For example, pattern="(?=.[A-Z])(?=.[a-z])(?=.[0-9])(?=.[@!#$%^&()])". A downside to this is that expressing the rules as a regular expression does not make it easy for a program like a password manager to understand it. It makes it easy for a password manager to apply it to a give password, but that isn't super helpful when it comes to generating a new password. So that argues for some other way to convent this information, bringing us to... 2. Add a new attribute to some tag to convey this information. In HTML5, it is legal (as in doing so does not make the HTML invalid) to add custom tags if their name starts with "data-". A "data-format" tag could be added to the password input field, with its value being in some industry agreed upon format. In prior versions of HTML, doing that would break HTML in the sense that it would not conform to the DTD. Not many programs actually care if what they are given as HTML conforms to the DTD, but those can be kept happy be a slight change to the DOCTYPE declaration. Usually the DOCTYPE declaration just contains references to external documents that contain the definitions that actually make up the DTD for the document. You can also put DTD definitions right inside the DOCTYPE declaration. To make our new data-format attribute legal, all we need to do is append the appropriate definition in the DOCTYPE after the list of external references.

tacostakohashi 10y ago
You think that sites that are unable to come up with sensible password rules will be able to get this right, on a large enough scale to make it useful? In terms of the metadata, you've more or less covered it, but the only way it has a hope of being useful is if it's provided by some community-minded third party.