3 ms·

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 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.

waterhouse 13y ago
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).
- zokier 13y ago
  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.
  - waterhouse 13y ago
    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.

waterhouse 13y ago

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).

zokier 13y ago
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.
- waterhouse 13y ago
  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.