5 ms·

This approach is cryptographically WEAKER than a password manager! Because password[0], password[1], ... password[n] are all related through common salt and m

This approach is cryptographically WEAKER than a password manager! Because password[0], password[1], ... password[n] are all related through common salt and master password string (and known domain name). Where as passwords stored in a password managers are independent. Therefore, in theory, if I know a few of your passwords (lets say I own 10 top domains and you've got accounts with me), I can crack your salt and password file, or at least, I can generate probable passwords for other domains.

cwp 14y ago
Also, the advantage of not having to keep your password database secret is negated by problem of keeping your salt file secret.
- gizzlon 14y ago
  Since when is your salt suppose to be secret?
  - pwg 14y ago
    >Since when is your salt suppose to be secret? In the instance of this particular algorithm, the salt must be kept secret, because it is the only unknown in the process from an attackers point of view.
    - gizzlon 14y ago
      Well, if that's true one should change the algorithm :)
    - icebraining 14y ago
      Not true, you have to input a master password (it's what the ';sha512sum -' part does), which is also unknown to the attacker.
      - pwg 14y ago
        Fair enough, but then the "salt" is not really a "salt" anymore as that term is known from "password salt", because it is no longer a random input value unique to each different password. It is simply a piece of known-plaintext input for every "hashing" session. That means that an attacker who can somehow obtain the salt value can now mount a known-plaintext attack against the outputs of the algorithm. http://en.wikipedia.org/wiki/Known-plaintext_attack http://en.wikipedia.org/wiki/Known-plaintext_attack I am ignoring the fact that in a general sense an attacker with resources to obtain the salt can also likely log the master password, in which case no attack against the algorithm is necessary.
- lloeki 14y ago
  There is one advantage to the design: only the salt has to be synced, and only once. This means that you can transfer it securely, and you don't need to sync your password database, ever (which means there's not even a third party involved). Something like this could actually help backport a limited form of two factor auth (something I know: password + something I have: salt) to single-password systems. That's of course barring the crypto issues this algorithm has (see comment by anon081312) but maybe things could be improved on that front (not that I want to 'roll my own', but maybe this function could be designed better, and reviewed)
jroes 14y ago
Is this cost offset in comparison to passwords actually being stored in a password manager? Do we know if all password managers are written in such a way that they generate independent salts per password? What is the likelihood that you own or would have compromised 10 top domains? Not sure if that matters, just curious. At the very least I'd personally prefer to use an open, understandable methodology to generate my passwords than some of the more popular options that are secured through obscurity.
- pwg 14y ago
  > Do we know if all password managers are written in such a way that they generate independent salts per password? Because password managers must store __the password__ itself (in order to be able to submit it into login forms and the like) the use of a salt for each stored password would work against the aim of storing __the passwords__ themselves. Instead, password managers store everything in encrypted form using a master key (password) for decrypting the encrypted data file. That master password should be passed through a key stretching function ( http://en.wikipedia.org/wiki/Key_stretching http://en.wikipedia.org/wiki/Key_stretching ) prior to use as the encryption key for the master encryption.
  - lloeki 14y ago
    How hard is it to get the master password when one knows 1. the encryption method 2. the encrypted password 3. the decrypted password ? (I don't have the foggiest idea about it, really)
    - pwg 14y ago
      > How hard is it to get the master password when one knows 1. the encryption method 2. the encrypted password 3. the decrypted password ? (I don't have the foggiest idea about it, really) If your password manager encrypts each password separately, and stores that output separately, then that simplifies the task, because you can mount a known-plaintext attack and potentially reduce the complexity. However, if your password manager stores things correctly, all the passwords are stored as a single "blob", with no known-plaintext anywhere in the blob, and the entire blob is fed through the encryption algorithm as a single block encryption using a single key. For example, the password safe format ( http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/trunk/pwsafe/pwsafe/docs/vormatV3.txt http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/... ) the master password is both salted and passed through a work-configurable key stretch function. The result of that operation is used to encrypt a 256bit random key using the Twofish algorithm. That 256bit random key is the actual encrypt key for all the password records, again using Twofish as the encryption algorithm. So deriving the master password is made difficult by use of the key-stretch function, and deriving the actual 256bit random key is as difficult as otherwise breaking the Twofish algorithm.
bascule 14y ago
The difference between the output of SHA512 and random data is negligible, provided that the master password is of non-negligible entropy. This is a necessary property of a secure hash function. HMAC or HKDF would probably be more appropriate here, but this usage is not inherently insecure. I'd certainly love to see you try to recover the master password from only 10 hashes.

cwp 14y ago

Also, the advantage of not having to keep your password database secret is negated by problem of keeping your salt file secret.

gizzlon 14y ago
Since when is your salt suppose to be secret?
- pwg 14y ago
  >Since when is your salt suppose to be secret? In the instance of this particular algorithm, the salt must be kept secret, because it is the only unknown in the process from an attackers point of view.
  - gizzlon 14y ago
    Well, if that's true one should change the algorithm :)
  - icebraining 14y ago
    Not true, you have to input a master password (it's what the ';sha512sum -' part does), which is also unknown to the attacker.
    - pwg 14y ago
      Fair enough, but then the "salt" is not really a "salt" anymore as that term is known from "password salt", because it is no longer a random input value unique to each different password. It is simply a piece of known-plaintext input for every "hashing" session. That means that an attacker who can somehow obtain the salt value can now mount a known-plaintext attack against the outputs of the algorithm. http://en.wikipedia.org/wiki/Known-plaintext_attack http://en.wikipedia.org/wiki/Known-plaintext_attack I am ignoring the fact that in a general sense an attacker with resources to obtain the salt can also likely log the master password, in which case no attack against the algorithm is necessary.
lloeki 14y ago
There is one advantage to the design: only the salt has to be synced, and only once. This means that you can transfer it securely, and you don't need to sync your password database, ever (which means there's not even a third party involved). Something like this could actually help backport a limited form of two factor auth (something I know: password + something I have: salt) to single-password systems. That's of course barring the crypto issues this algorithm has (see comment by anon081312) but maybe things could be improved on that front (not that I want to 'roll my own', but maybe this function could be designed better, and reviewed)

jroes 14y ago

Is this cost offset in comparison to passwords actually being stored in a password manager? Do we know if all password managers are written in such a way that they generate independent salts per password? What is the likelihood that you own or would have compromised 10 top domains? Not sure if that matters, just curious. At the very least I'd personally prefer to use an open, understandable methodology to generate my passwords than some of the more popular options that are secured through obscurity.

pwg 14y ago
> Do we know if all password managers are written in such a way that they generate independent salts per password? Because password managers must store __the password__ itself (in order to be able to submit it into login forms and the like) the use of a salt for each stored password would work against the aim of storing __the passwords__ themselves. Instead, password managers store everything in encrypted form using a master key (password) for decrypting the encrypted data file. That master password should be passed through a key stretching function ( http://en.wikipedia.org/wiki/Key_stretching http://en.wikipedia.org/wiki/Key_stretching ) prior to use as the encryption key for the master encryption.
- lloeki 14y ago
  How hard is it to get the master password when one knows 1. the encryption method 2. the encrypted password 3. the decrypted password ? (I don't have the foggiest idea about it, really)
  - pwg 14y ago
    > How hard is it to get the master password when one knows 1. the encryption method 2. the encrypted password 3. the decrypted password ? (I don't have the foggiest idea about it, really) If your password manager encrypts each password separately, and stores that output separately, then that simplifies the task, because you can mount a known-plaintext attack and potentially reduce the complexity. However, if your password manager stores things correctly, all the passwords are stored as a single "blob", with no known-plaintext anywhere in the blob, and the entire blob is fed through the encryption algorithm as a single block encryption using a single key. For example, the password safe format ( http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/trunk/pwsafe/pwsafe/docs/vormatV3.txt http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/... ) the master password is both salted and passed through a work-configurable key stretch function. The result of that operation is used to encrypt a 256bit random key using the Twofish algorithm. That 256bit random key is the actual encrypt key for all the password records, again using Twofish as the encryption algorithm. So deriving the master password is made difficult by use of the key-stretch function, and deriving the actual 256bit random key is as difficult as otherwise breaking the Twofish algorithm.

bascule 14y ago

The difference between the output of SHA512 and random data is negligible, provided that the master password is of non-negligible entropy. This is a necessary property of a secure hash function. HMAC or HKDF would probably be more appropriate here, but this usage is not inherently insecure. I'd certainly love to see you try to recover the master password from only 10 hashes.