shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tauren Mills <tau...@groovee.com>
Subject Re: Securing passwords, emails, credit cards, etc.
Date Fri, 01 Apr 2011 07:33:42 GMT
Janne,

Thanks for your response and good advice. My codebase dates back to
pre-Shiro days, and I don't think multiple iterations were supported then. I
agree that I absolutely should be using salts and should have from the
start.

Anyway, my question was really meant to be focused on using Shiro for
encrypting and decrypting sensitive data such as credit cards and SSNs and
less on hashing passwords. There is very little documentation on the crypto
features and sample code is basically non-existent as far as I've seen. If
there are any resources I'm not aware of, please let me know.

By the way, I found the conversation that I was looking for about salts and
iterations. I see that most of the suggestions in this thread are now part
of Shiro core, so I'll update my code to use them.
http://shiro-user.582556.n2.nabble.com/Password-Salting-one-salt-per-password-td5490030.html

Of course, when I switch to using salts and iterations, I'll have to figure
out a way to migrate all the passwords stored in my database to continue
working. I can't just change the code and force every user to use the
"forgot password" feature.

Thanks,
Tauren


On Fri, Apr 1, 2011 at 12:06 AM, Janne Jalkanen <janne.jalkanen@ecyrd.com>wrote:

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

Mime
View raw message