Live data from Hacker News

Midnight project: Password manager without a password manager

gist.github.com

21–30 of 43 posts

Re: Midnight project: Password manager without a password manager

#21
I think this is catastrophically broken because of a known issue of how SHA-2 breaks its input into blocks: when A is aligned to a block boundary, sha(A || B) = f(sha(A), g(B)).

http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_con...

In your system, the derived password is a sha digest of a concatentation of other sha digests. It almost has the form sha(sha(SALT) || sha(RESOURCE) || sha(MASTER)), with sha() returning the ascii encoding of the base-16 representation. (The difference is three extra newline characters "\n", which makes things slightly messier). This string representation for sha-512 digests is 128 characters or 1028 bits, and sha-512 uses 1028-bit input chunks, so the final sha() call reads the other three digests aligned on chunk boundaries. (Again, few bits off because of newlines, but this is not fatal).

So DERIVED(RESOURCE) has a form

    DERIVED = sha(sha(SALT) || sha(RESOURCE) || sha(MASTER))
            = f(sha(sha(SALT) || sha(RESOURCE)), g(sha(MASTER)))
where f,g, are known functions. Moreover, f is reversible -- in SHA-512 it is just addition.

So for an attack: given the salt, along with one resource/derived password pair, every other password can be computed. If you know SALT, RESOURCE_1, and DERIVED_1, you know these:

    sha(sha(SALT) || sha(RESOURCE_1))

    DERIVED_1 = f(sha(sha(SALT) || sha(RESOURCE_1)), g(sha(MASTER)))
Because f is reversible, and you know its first argument, you also learn its other argument,

    g(sha(MASTER))
and can calculate any other password, given the resource name. Note you don't learn the master password, nor its sha digest -- you can't reverse the block function g(), not without breaking SHA-2 itself. But that's not necessary.

Re: Midnight project: Password manager without a password manager

#22
post #15

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 pa…

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

Since when is your salt suppose to be secret?

Re: Midnight project: Password manager without a password manager

#23
We conceived of something like this for the web a couple years ago, as part of a much much larger picture:

http://www.faqs.org/patents/app/20120110469#b

In our formulation, the salt was simply (a function of) your username.

But yeah, we couldn't find a way to crack it, either.

Re: Midnight project: Password manager without a password manager

#24
post #22
post #15

Earlier quoted context omitted.

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

Since when is your salt suppose to be secret?

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

Re: Midnight project: Password manager without a password manager

#25
post #24
post #22

Earlier quoted context omitted.

Since when is your salt suppose to be secret?

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

Well, if that's true one should change the algorithm :)

Re: Midnight project: Password manager without a password manager

#26
post #17

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 pa…

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…

> 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 ) prior to use as the encryption key for the master encryption.

Re: Midnight project: Password manager without a password manager

#27

I think this is catastrophically broken because of a known issue of how SHA-2 breaks its input into blocks: when A is aligned to a block boundary, sha(A || B) = f(sha(A), g(B)). http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_con... In your system, the derived password is a sha digest of a concatentation of other sha digests. It almost has the form sha(sha(SALT) || sha(RESOURCE) || sha(MASTER)), with sha() r…

> I think this is catastrophically broken because of a known issue of how SHA-2 breaks its input into blocks: when A is aligned to a block boundary, sha(A || B) = f(sha(A), g(B)).

If that's the case, wouldn't it suffice to mix A and B, for example with byte-wise XOR?

  password ::= sha(A XOR B)

Re: Midnight project: Password manager without a password manager

#28
post #23

We conceived of something like this for the web a couple years ago, as part of a much much larger picture: http://www.faqs.org/patents/app/20120110469#b In our formulation, the salt was simply (a function of) your username. But yeah, we couldn't find a way to crack it, either.

> In our formulation, the salt was simply (a function of) your username.

For password hashing, the input salt needs to be a cryptographically secure random number. This is because it needs to be unique, and unrelated, to each password.

In your "formulation", what you have is simply a unique identifier for a user derived from the three, but it is in no way a "salt" as that term is used in regards to "salted passwords".

> But yeah, we couldn't find a way to crack it, either.

Just because you couldn't find a way to crack it, does not mean it is secure:

http://security.stackexchange.com/questions/18197/why-should...

Re: Midnight project: Password manager without a password manager

#29
post #24
post #22

Earlier quoted context omitted.

Since when is your salt suppose to be secret?

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

Not true, you have to input a master password (it's what the ';sha512sum -' part does), which is also unknown to the attacker.
Post reply on HN