31–40 of 43 posts
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)). 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…
Earlier quoted context omitted.
They would only discover the domains, not the passwords you entered. You type the domain at the command line, but you type the password into stdin.
The program outputs your site-specific password to stdout. Is it possible for an attacker to get your stdout history?
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)
Earlier quoted context omitted.
The program outputs your site-specific password to stdout. Is it possible for an attacker to get your stdout history?
Might be. Some terminal emulators save logs. "Unlimited scrolling" often goes to disk, possibly in a file, possibly in swap (Terminal.app makes it stay in memory, which once consumed 3GB of RAM for my long-lived "rails server" tab). iTerm2 allows you to navigate back in time, while Terminal.app saves some data on quit to display on restore (if OSX autosave is enabled).
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.
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)
Earlier quoted context omitted.
>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.
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
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.
Earlier quoted context omitted.
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…
This is fine for hackers but for mere mortals it looks cumbersome.
Mortals simply use domainName+superSecretWord.
By using this scheme, you're trusting $domainName to securely scramble the password.
Once a single password is known in plain, an attacker has a nice password template that he can try on any site. The last few bits of security would be your user name (which is often similar to the one you use elsewhere) or nothing at all if you can log in by email address (which is usually possible these days; and that email address is often among the leaked information as well). Instant login anywhere!
At least hash that '$domain+$masterpass' string...
-----
More problems: I heard some people still truncate passwords down to unreasonable lengths on the server side, which might make hash compression (e.g. base 16 -> base 64) necessary and which will totally break the simple concatenation scheme, leaving a prefix of $domainName as the actual password. Ouch.
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"…
on a related note, we encourage each of our users to select a passphrase, and even scour yahoo news from the past year, and other sources for three consecutive words, that the user can easily remember, such as "that truck driver" or "what he did". This in practice causes users to have a much better space of possible passwords to begin with ... without which any system would be susceptible to brute force rainbow table type attacks.