shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tauren Mills <>
Subject Re: Securing passwords, emails, credit cards, etc.
Date Fri, 01 Apr 2011 23:35:13 GMT
> Yep, this looks great.  Exactly what I do in my own apps :)
> Because of this, for a long time I wanted to create a PasswordService
> concept in Shiro (maybe something in line with
> - I'm not sure) that
> encapsulates the logic that you've just laid out and what I'm sure
> people replicate from app to app.
> I just created a new issue for it here:
> Feel free to vote for it if you'd like to see it implemented earlier
> rather than later.

Looks useful, I just voted for it.

> > Any suggestions on migrating existing simple Sha256Hash() passwords
> without
> > interrupting user logins? Perhaps have Member.password and
> > Member.oldPassword properties. If Member.password is NULL, then test
> using
> > the old method and update Member.password with data if old method is
> > successful. If Member.password exists, then test using new method as user
> > password has been upgraded already. Or do you have a better idea?
> Nope, this sounds pretty good to me as a non-invasive approach.
> A more direct approach might be to send 'reset password' emails and
> force them to reset their passwords either via a link in the email or
> upon the next login (you would null/remove the existing password hash
> to ensure it couldn't be used to compromise their account).  This is
> definitely invasive in that it requires user interaction, but if you
> have any concern at all, it is the safe approach.

I might do something like that after maybe 30 days. Those accounts that
haven't already upgraded will receive a 'reset password' email with a link
at that time. I'm not concerned that I've been compromised, I just want
better safeguards in place without imposing on too many users. Of course,
sending emails with reset links has its own set of vulnerabilities to

> > Assuming I'm not going for rolling keys, would you suggest having one
> > application-wide key that is used to encrypt and decrypt any sensitive
> > values? Or would it be better to have different keys for different
> purposes
> > (one for credit cards, another for SSNs, etc.)?
> The more keys the better, since a compromise on one doesn't
> necessarily mean a compromise of another.  However, if you store all
> of your keys in the same place, you can assume that if one is
> compromised, they all will be.  In this case, a single key is just as
> effective as multiple keys.

Do you have suggestions on where key storage would ideally be? Currently I
include this sort of application-level information in a properties file that
gets loaded by Spring and the values injected into appropriate beans. But
obviously that would mean all keys would be in the same place. And anyone
who has access to the WAR file could easily discover those keys. The
application is hosted on a different server than the database, but if the
app server is hacked, the intruder would have the WAR file and access to a
system that is able to connect to the DB server.

Plus, this means that every developer, system administrator, or personnel
involved in deployments would be able to see these keys. A little social
engineering hacks and someone might share the keys with the bad guys. But
where could they be stored that these same people would not be able to
easily access them? Hard coded into the application? In a database?

> > Shiro's certainly made it dead simple to work with crypto. Is there
> anything
> > wrong with the following implementation, or anything you would do to
> improve
> > the way I'm using Shiro's crypto (note I haven't tested the following
> code
> > yet)?
> Looks pretty good to me!

I'm debating between just encrypting the entire credit card number and
encrypting either the middle (like my example) or everything except the last
4 digits. Here's my take on the trade-offs:

* Encrypting the entire card seems more secure, as none of the card's digits
is available in clear text. However, my UI will display masked card number
(i.e. ****1111) more frequently than it needs the full card number. Every
time I need to display a masked card number, I'd have to decrypt the full
card number. This will add some additional resource usage, but more
importantly it means the full card number will be resident in the server's
memory more often.

* Keeping the last 4 digits unencrypted means that I can do all normal UI
display actions without needing to decrypt the credit card. The only time
the card would need to be decrypted is when a charge to that account is
going to be made. This might actually be more secure because the full card
number isn't floating around in memory (and possibly swapped to disk or
logged somewhere) nearly as often.

Any insights?

Thanks again,

View raw message