Should I implement my own local password hash?

Question

Having a more-than-elementary knowledge of internet security, I've realized that some web applications and websites I use implement a less-than-ideal password policy. Some examples include:

• Implementing a password-length upper-bound (upper-bounds I have seen are 16, 20, and 32)
• Requiring the presence of arbitrary characters
• Forbidding the presence of arbitrary characters (such as spaces, %, ^, and others)

These kind of practices make me worry that the server-side encryption is equally questionable.

Thus I'm wondering if it would be a good idea to implement my own script (drawing on tried-and-true methods) to create a hash of my password on my local machine and then rehash it until it meets the sites arbitrary requirements and use that as my 'password'.

Answer 1

What you describe is one of the two main methods used by "password vaults" products. Such products try to make it easier for you (the human user) to "remember" site-specific passwords, while still maintaining the important property, that is the specificity of passwords: one password for each site, so that a breach on one site does not endanger your accounts on other sites.

The two main methods are:

1. Try to "derive" (through hash functions or similar construct) a site-specific password from a master password; the site name is then used as extra parameter, to make sure that each site get its own password.

2. Generate random passwords for each site, and store them locally (on the client), encrypted with a "master password".

In both cases, you need client-side software, because there is no known method to achieve the one-wayness required for proper specificity with only human brain capabilities (see this previous question). Such software can be a local application, some script, a browser extension...

Your proposal relates to the "type 1" method (derivation from the master password). The usual hope is that the "type 1" method may allow for dispensing with local storage. Unfortunately, this fails on two accounts:

• As you have noticed, password rules mandated by various sites are incompatible with each other, so you can not produce passwords which can fit all possible sites. Therefore, something in your system must remember the rules for each specific site, so that the site password can be recomputed properly.

• Some sites mandate password changes at more or less regular intervals. A no-storage password derivation cannot cope with a password change.

"Type 1" password vaults still have value, in that the required local storage needs not be confidential, since it includes nothing which depends on the master password (it does include information about all the sites on which you have accounts, though, and that may be a privacy issue). On the other hand, each site-specific password may be used for an offline dictionary attack on your master password, which can be a problem.

"Type 2" password vaults are more flexible and are thus more common (e.g. KeePass). Some of them couple with a centralized storage (see 1Password) so that you may have access to your passwords from all your devices. A really good point of "type 2" vaults is that the site-specific passwords, being randomly generated, cannot (in a strong mathematical sense) leak information about your master password or passwords for other sites.

Answer 2

A couple of problems I see with that approach:

• You probably want to go ahead and salt the hash (even if it's just with the name of the site).
• If you ever try to log in from another computer, you will need to have your hashing program available. Alternatively, you can use a hash that you can get from a web site, but then you are sending your password to an untrusted domain.
• You'll need to map the output of the hash into those arbitrary restrictions, so you'll need to know the schema per-site every time you log in. For example, one site might require special characters while another may forbid them.

I have recommended this strategy in the past, and I think it appears to be solid apart from the items I mentioned above; I look forward to seeing others' advice on the subject.

Answer 3

If you just used a hash of your password, your hashed password would become your de-facto new password. If used on more than one site, it is similar to reusing your normal password, although it's hopefully harder to guess it or brute force it.

In practice, you want to mix a salt (to protect from rainbow tables) and website name (to protect from reuse) into the hashing process, but then you encounter another problem (in addition to those mentioned by others) - some sites share user database, because they are actually run by same company or are even just different name or frontent for the same service.

It's better to just use a password manager, imo.