A really awesome and simple solution would be to ask users to use non obvious sentences as their password. Even better would be to ask them to use a non grammatical sentence with deliberate phonetic spelling variations.
Although that would be ineffective against a sophisticated brute force attack to crack the encryption itself over a period of days, but it would be an awesome stopgap.
You know you could match it against a corpus and reject the password as being too weak. Right now it's just a graphic, but if you become proactive about it by education through a meme or something and reject passwords. Then maybe people will learn.
An astonishing number of those users love chain emails. It's certainly not an exclusive set, so why don't we use that? Make it "cool", or something.
Pass-phrases + minor misspellings are typically non-crackable with billions^x years, barring dictionary attacks (stupidity will always exist). There's no "sophisticated brute force" that would speed it up measurably.
Granted, password-hashing reduces the keyspace, often to something possibly-computable to find a collision. But you're still talking up to 36^40 (for SHA1) attempts (that's 1e62, btw).
I am not saying that you go through every permutation. What I meant was something like Turing's tricks. The naval Engima was consistently cracked in a short time by the bombe because they learnt that at a particular time of day all ships sent weather reports. Further they were always signed 'Hail Fuhrer/Hitler!". I am pretty sure that modern equivalents must exist in the implementation of cryptography today.
The irony is that I am not qualified to comment and the people who are qualified to do so are bound by secrecy not to do so.
There you're talking a statistical analysis of a code, specifically one based on a "code book", which are vulnerable to attacks like this. Hashes are designed to prevent this by being (ideally) evenly distributed based on input, and salts destroy analysis across multiple clients. To perform that sort of attack, your hash function would have to be "cracked" in some way, like MD5 is (you can create collisions easily - values which resolve to the same hash), and thus almost totally worthless.
I wish I could, actually. I've just been picking it up by reading random articles for a couple years now, writing some Rails code, and looking things up (details / best-practices) as I go. Not a route I'd suggest in general, but it works if you're focusing on other things.
What got me started & revealed a lot of other cryptography techniques was to look into how Diffie-Hellman[1] and RSA[2] work (they're not too complicated, really), understand what hashing functions do, if not necessarily how, and then look around at news of exploits / attacks. A lot to understanding secure code / techniques is understanding how the attacks work, and a lot of the news around them contain surprisingly-good explanations.
Anyone else have suggestions? I could probably use them too.
I found Katz & Lindell's Modern Cryptography, a textbook written by active research cryptographers, quite good. The classical "applied" work is Schneier's Applied Cryptography", but note there are a lot of issues with that work. His newer book, "Cryptography Engineering", is supposedly better.
Goldreich's Foundations of Cryptography is quite solid, but requires quite a bit of background and is very theoretical.
Standard password security, basically. At that point, there's a lot more danger from social engineering or people writing down the (long, non-obvious) passwords.
Although that would be ineffective against a sophisticated brute force attack to crack the encryption itself over a period of days, but it would be an awesome stopgap.