> I have a feeling I could be using the Cryptography features much more > effectively. For instance, when a new user signs up, I do the following: > member.setPassword(new Sha256Hash(dto.getPassword()).toHex());
Use a salt to protect against rainbow tables. It's just good practice. > I require that all passwords are at least 8 characters long and include > characters from at least three of the following four categories: lowercase > letters, uppercase letters, numbers, and symbols. After reading the following > article, I'm worried about just how easy it would be to crack these password > hashes: > http://codahale.com/how-to-safely-store-a-password/ Well, yes and no. My quick calculation suggested that with your scheme, an exhaustive search of the keyspace would take about 400 days on the computer cluster the article is on about (assuming SHA-256 is about 30% slower than SHA-1 as suggested here http://www.cryptopp.com/benchmarks.html). At a minimum of ten characters you would need 4000 years. (This is BTW one of the reasons why pass phrases are better than passwords.) However, this is only true if the attacker has access to the hashes, i.e. your database security is compromised. And in such a case you have far worse problems than someone cracking your database - they could be injecting their own passwords, or installing keyloggers or whatever. The article you refer to just suggests that you use a very slow hash function. > I seem to recall some talk of performing multiple hashes on things to secure > them better? Any links to this resource? One trick would be to run the hashing several hundred times. You can do that in Shiro automatically. This slows down the required time to perform an attack. http://shiro.apache.org/static/current/apidocs/org/apache/shiro/authc/credential/HashedCredentialsMatcher.html and the setHashIterations() method. /Janne
