Now that PasswordMaker has matured into a tool with boatloads of options, I think the next step is to try to keep the typical user from ever having to think about them. Just as a user logs onto Windows XP without a considering the password hash algorithm, salting, etc., the same would be ideal for PasswordMaker. Here is my suggestion to make this a reality:
1. Set the PasswordMaker defaults to a best practice security settings that work for most (90%+) sites. IMHO, this means the following:
1a. SHA-256 hash algorithm.
1b. Password length 16 characters.
1c. Alpha/numeric/symbol character set.
1d. No modifier, suffix, or l33t. These add no value when public. Side comment: I don’t really understand why these are ever useful, since it seems a user can always get the equivalent by using a stronger password.
1e. A character forcing post-filter (new). Many sites require at least one number, one symbol, one capital letter, and one lower case letter. After SHA-256 has been applies, the forcing filter should ensure each password has these features. A suggestion for implementation would be this: for each character type to be forced, if it is absent, find the character with highest ascii value for which there is more than one character of its type and convert it to the forced character type. For the conversion, take the old character’s ascii value modulus the size of the new character type’s set and add that result to the ascii value of the lower character in the new type’s set.
2. Maintain a public list of all sites that don’t work for bullet 1 (“weenie sitesâ€). The public list would contain the domain name of each site, plus its password length and character set. For complicity, I recommend using an enumeration that refers to predefined character sets (the ones already present in PasswordMaker). What to do with this public depends on how big it is expected to get:
2a. If it is small, have PasswordMaker automatically download it periodically, similar to the
AdBlock Filterset.G updater.
2b. If it is large, have PasswordMaker use a web service query to the weenie status of each individual site the first time it encounters a password field on its page. PasswordMaker would maintain a local cache of the responses.
2c. In either case, there needs to be a submission mechanism as new (to the community) weenie sites are encountered. The forums would work initially, but ultimately, this should be integrated into PasswordMaker using web services.
3. The online version would use the weenie site list just like PasswordMaker extension.
I hope my proposal is clear so far. Now, I’m going to throw in usernames. The current problem is that sites vary as to whether they user email usernames or alphanumeric-only usernames. Here is a proposed solution:
1. The user enters an email address into PasswordMaker, which optionally stored (just like the password).
2. By default this email address is populated into the email address field on forms. If the form appears to have a username field instead, the @ is removed, and the remainder becomes a username. If the HTML tag specifies a character limit for the username, PasswordMaker abides.
3. If PasswordMaker’s heuristics don’t correct determine whether to use email or username, or it cannot deduce the character limit, the site goes on the weenie list, in which case the username type and, if applicable, size are included.
4. For the online version would suffer a bit here, since it can’t examine the page source. It would fall back to just showing username information available from the weenie list, if any.
The end goal is to come very close to this point: wherever you are, simply enter your email and master password, and it all “just worksâ€, securely.