Hacker News Reader

Comment by danielhughes | Hacker News Reader

What do you do when the site requires that you change your password? Do you use a different secret phrase? And if so how do you keep track of those?

View on HN

My scheme involves the passphrase, the site name, and a password version all getting hashed together. If a password needs to be changed, I just bump the version. This requires me to keep a list of names and versions around, but that's not sensitive information absent the passphrase. I've also written my own version of a pwdhash-like tool which saves the list of site names along with the versions, so I don't have to do a lot of data entry in order to retrieve a password.

Heh heh--uh, fortunately I have not encountered a site that ordered me to change my password and forbade me to use an old one. If I had to deal with that scenario... I guess I would create a file that had, on separate lines, "[site name] [number of resets]", and would change the main script to take a hash of [site name] + [secret phrase] + [output of "grep '^'$SITE_NAME' ' [that file]"].

Also, if I wanted this to work with multiple accounts on a single website, I would have to include [account name] in the input to the hash function.

The forced password change seems to be popular with enterprise software managed by a corporate IT department. A favorite policy they enforce is something like the following..."You must change your password every 30 days. Your new password must be different than your last 8. It must contain at least one number and a mix of upper and lower case letters. It cannot be more than N characters in length." It's kind of ridiculous and counter productive in that it destroys an otherwise sensible strategy like the one you proposed (referring to your first comment) and in its place you get employees doing silly things like making their passwords Password1, Password2, Password3, etc with each successive forced reset.

Gah, that's unfortunate, and perverse. My scheme has indeed been defeated by the DMV's website capping the length of the password at 20, and there are a couple I know it wouldn't work for because they require at least one non-alphanumeric character.

On the plus side, all this brain-damage does seem fairly easy to incorporate into an automatic scheme. Have another file that has a list of cutoff lengths for each site that has them, and another file with special characters to insert. Then the scheme becomes: hash [domain] + [secret] + [resets (if any)], add special characters to the start (if any), and cut off the end of the string (if necessary).

The primary (or even only) advantage of hash-based password management is it's stateless nature. Once you begin to introduce files (ie extra state) to support the system you might as well use fully randomized passwords stored in file.

You have a point. Another advantage is, all that state other than the secret phrase is insufficient to derive the password, and could be passed around insecurely, while the secret phrase could be memorized. But I suppose one might achieve the same thing with a GPG-encrypted file of randomly generated passwords. Still, if you lose all relevant files, you should be able to reconstruct the hashing scheme and recreate all passwords that didn't require state. Whether this matters is up to the reader.

Reply on news.ycombinator.com