[EGreg]

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.

[pwg]

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

[EGreg]

on websites, usernames are unique, and they are usually unrelated to 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.

[pwg]

>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

And with a wordlist of the 10,000 most common words, if you are not also using a key-stretch function (bcrypt, pbkdf2, etc.) all of those examples become quite trivial to a john-the-ripper ( http://www.openwall.com/john/ ) type attack. I.e., a three word phrase consisting of one each of the 10,000 most common words has at most 10000^3 combinations (1e+12). A 10 digit random password selected from letters, numbers, punctuation (94 digits) has 94^10 combinations (5e+19). 5e+19 is significantly larger than 1e+12)

[EGreg]

In theory, you are correct, of course. In practice, users do not select nearly close to 5e+19 unique passwords when asked to come up with a "random" password on their own. And if one is given to them, then it's inconvenient for them to remember 29c!8z79c. I would rather remember 5 words than 10 random letters, and 5 words would also equalize the space in your example.

Here is what I am pretty sure is true:

1) The salt just has to be unique enough to make rainbow table attacks on any significant portion of the userbase infeasible Any given rainbow table will only work for one salt. From this perspective, usernames are just fine as a salt.

2) The real danger is password re-use (http://xkcd.com/792/) and more generally, just lousy password selection (know anyone whose password is "password"?) Pass phrases are better (http://blogs.technet.com/b/robert_hensing/archive/2004/07/28...) and if we can deliver to the users a space of 10^14 possible phrases that actually sound like they make some sense, as an inspiration for them to choose a phrase of their own, then I think that's a good thing to do.

3) And of course, we use key strengthening, running the hash function a lot of times (a prime number of times, just in case ;)