4 ms·

Honest question: why doesn’t everyone just use hash functions for passwords. Generating a Base64 string from a secret salt + the website name sounds ideal. This

• sametmax 7y ago
  Passwords are not just for websites, same services has different domains, sync is free, autocomplete on mobile, passwords are not the only thing I want to save, etc.
• vectorEQ 7y ago
  base can be decoded. hash cannot be reversed (should not be able to). That means if someone gets the hash, he can only guess the password based on hasing all his guesses and checking the outputs. that takes a long time compared to being able to decode and read the password directly.
• zallarak 7y ago
  How do you handle password rotations? I am intrigued regardless.
  • 0xCMP 7y ago
    A new salt probably
• Blackstone4 7y ago
  I’ve thought about a similar method but I’m not sure it would be portable for me. First I do not always have access to a bashing function. Secondly what happens if a website url/name changes? For me, I can’t remember all the exact details so I use a manager
• jperry 7y ago
  Huh? How is this a solution? If your password gets leaked I can just: recognise that it's base64, decode it, see your salt and then all of your other passwords are essentially open to me? Edit: Oh, is the salt different for each site? I don't get why you'd ever do this instead of generating an entirely new password though, you aren't solving the storage problem.
  • infogulch 7y ago
    I think you missed the "use hash functions" part. it would be something like base64(H(salt||example.com:1)). The ":1" suffix is there for when you have to change your password, you can increment to ":2" because : is not valid in a domain name. This doesn't solve all the other problems with this system, like what if there are multiple logins on the same domain? what if the site has esoteric password requirements? what if the requirements change? if your salt leaks you don't have a list of sites to know to go change your password. etc etc. Not my favorite solution for practical reasons, but it's cryptographically reasonable at least.
• rwz 7y ago
  I actually tried doing this at some point before 1Password. One obvious problem with this approach is when you’re forced to change your password. You can’t change salt, or hash function for obvious reasons, so you have to change site name. At some point guessing the original input becomes tedious, when you’re trying to remember if your github password has name “github.com2” or “github.com-3” Edit: Completely forgot about another huge usability issue. Some sites enforce weird rules for what symbols are allowed, or what length your password should be. Every time your function generates something that doesn’t pass validation, you’re forced to pretty much revert to your pre-password-management behavior. Obviously you won’t remember that a year later when you suddenly realize that generated password doesn’t work.
• dchest 7y ago
  https://crypto.stackexchange.com/questions/5689/a-single-password-manager-vs-password-generator-hash/5691#5691 https://crypto.stackexchange.com/questions/5689/a-single-pas...
• 33degrees 7y ago
  For one, you only get a single password per site, so you can't rotate them, or have multiple accounts unless you add the account name to the inputs. Secondly, different sites have different requirements, so your generated passwords might not work everywhere. Finally, a password manager lets you store more than just a password for each site, and it can let you store passwords and secrets for things other than websites.
  • _o-O-o_ 7y ago
    > For one, you only get a single password per site, so you can't rotate them Well I know Lesspass[0] has a 'counter' so that if you need to change a pass you simply increment it by one and you get a new hash https://lesspass.com/#/ https://lesspass.com/#/
• ben509 7y ago
  Standard issues with these derived password schemes: * Are you sure your algorithm can't be reversed? * What do you do if your normal username is taken? * What do you do when the site's name changes? * How do you handle forbidden and mandatory characters? * How do you handle forced rotation? * What about extraneous crap like security questions, phone PINs, emails, related sites, &c.? * How do you access it on other devices? * How can you track down old accounts to close them down? If you go on listing the issues, you wind up writing the requirements document for a password manager.
  • tzs 7y ago
    > If you go on listing the issues, you wind up writing the requirements document for a password manager. One difference, though, is that most of the issues can be addressed by some sort of persistent data store that does not need high security. Once you've taken the passwords themselves out of what your password manager stores, I think this is the only thing on your list that requires storing highly sensitive data: > What about extraneous crap like security questions, phone PINs, emails, related sites, &c.? For the rest, such as some sort of per site version serial number to handle password rotation, or a map from current site name to original site name for sites whose names have changed, it is also sensitive data, but it is on a level of sensitivity like a contact list or browser bookmarks for which your ordinary OS security mechanisms for file protection should be sufficient.
  • _o-O-o_ 7y ago
    https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-managers https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...