[snowwrestler]

Why not just require your users to set a 4-word passphrase as their password? You'll capture more variations than you would working from a fixed 5,000 word dictionary, and your users can still choose to write the words down if they want--or they can use the password management features of their browsers if they want. Plus it would be more simple to build and maintain, which is a plus when it comes to security.

[MarkMc]

The problem is that the average user is really bad at choosing a password. If the system requires a four-word passphrase then the user will choose easy-to-crack passphrases such as "use the force luke" or "john paul george ringo".

If the system randomly chooses the four words then you force the user to exchange convenience for security.

[snowwrestler]

Then why let users choose a password at all? Why not just assign them one that they have to write down? And if they're going to write it down anyway, why make it words? Why not generate a 20 character random string?

I obviously don't have the whole picture of your effort, but from your description so far, I think you are over-emphasizing the importance of clever password schemes. As Colin points out in the top comment, hashing with scrypt will make even mediocre passwords uncrackable. So it would be a better use of your time to implement scrypt or bcrypt with just one password.

And high-speed cracking is only a problem if the bad guys get your password table. To do that they will have to get into your application...and if that happens there are all sorts of other problems. So I'd argue that spending more time testing and proving the overall security of your app is also a better use of your time.

[MarkMc]

> Then why let users choose a password at all? Why not just assign them one that they have to write down?

Because then anyone who reads what is written down gains full access to the user's data. A password (kept in human memory) plus passphrase (written down) is more secure. I would agree this comes at the cost of convenience, but I think the trade-off is worth it.

> Why not generate a 20 character random string?

Because it would be a real pain to type each time the user logs in. In this case I don't think the security/convenience trade-off is worth it.

> As Colin points out in the top comment, hashing with scrypt will make even mediocre passwords uncrackable.

True, but what percentage of users choose poor passwords - not mediocre ones? Scrypt will not be much good if the user chooses a password from the dictionary, or a word that appears in a list of the top 10,000 most common passwords. (Edit: According to Mark Burnett [2] such passwords are chosen by 99.8% of users)

> And high-speed cracking is only a problem if the bad guys get your password table.

The password + passphrase model also protects users who choose the same password for different online systems. A weakness in some other website (or something more evil [1]) will not compromise the security of my online system.

Edit: Low-speed cracking might also be a problem. Mark Burnett says 14% of users have a password from the top 10 password list [2].

[1] http://xkcd.com/792/

[2] http://xato.net/passwords/more-top-worst-passwords

[snowwrestler]

You are presuming that your users would not write down the password they choose for themselves as well, perhaps on the same sheet of paper.

I'll leave this final thought--how many other websites have implemented a double password system like the one you're proposing? I don't know of any.

Is that because you have come up with a more secure solution that no one else has thought of? Or that your approach does not confer the security advantages that you think it does? Which is the more likely explanation?