[security-dev] SHA salted passwords

Mon Jan 7 10:58:50 EST 2013

bcrypt is better than salting, if for no other reason because it's slower,
and you can increase the work factor. scrypt seems to be better than bcrypt
because you can increase the memory and the CPU cycles needed to generate
the password for storage, however, it's less tested than bcrypt. You can
find more info at http://en.wikipedia.org/wiki/Scrypt and
http://en.wikipedia.org/wiki/Bcrypt. It may be worth noting that bcrypt is
available out of the box with Spring Security (and probably Shiro).

On Mon, Jan 7, 2013 at 8:48 AM, Shane Bryzak <sbryzak at redhat.com> wrote:

> The credential handler SPI is totally pluggable, so while we provide a
> PlainTextPassword on the validate() or update() side, it's up to the
> credential handler how the password is represented in the backend
> identity store.  I'm absolutely open to providing additional
> implementations if they're more secure than a hash.  (To answer your
> question though, no we're not using the same salt).
>
> On 08/01/13 01:33, Jason Porter wrote:
> > I haven't looked at the code yet, so forgive me if this is ignorance on
> my part. Are we using the same salt for every password? I think it might
> actually be a good idea to remove hashed passwords as an option and instead
> offer things more secure such as bcrypt or scrypt. One of those at least,
> imo, should be default. Hashed passwords, even with a salt are really not
> that secure and I'm not talking about rainbow table attacks, just plain
> brute force attacks with small box lots of GPU power and some coda code are
> quickly become the norm for brute forcing passwords.
> >
> > This also brings up a good point with what are our recommendations and
> defaults? Encryption, hashing, account locks?
> >
> > Sent from my iPhone
> >
> > On Jan 7, 2013, at 8:27, Pedro Igor Silva <psilva at redhat.com> wrote:
> >
> >> +1
> >>
> >> ----- Original Message -----
> >> From: "Bruno Oliveira" <bruno at abstractj.org>
> >> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >> Cc: security-dev at lists.jboss.org
> >> Sent: Monday, January 7, 2013 12:58:01 PM
> >> Subject: Re: [security-dev] SHA salted passwords
> >>
> >>
> >>
> >>
> >> --
> >> "The measure of a man is what he does with power" - Plato
> >> -
> >> @abstractj
> >> -
> >> Volenti Nihil Difficile
> >>
> >>
> >>
> >> On Monday, January 7, 2013 at 12:18 PM, Anil Saldhana wrote:
> >>
> >>> Having a PlainTextPassword and EncodedPassword separation at the class
> level is good. It clearly tells the user/developer what type of password is
> being stored. But if he chooses PTP, should we do the default
> salting/hashing in the background? The EncodedPassword can allow
> configuration of salting/hashing mechanisms.
> >>>
> >>> We should not at any cost save plain text passwords in the tables.
> >> +1 and maybe for a while we could refactor PlainTextPassword to
> EncodedPassword and avoid some misunderstanding.
> >>
> >> Makes sense?
> >>> Wdyt?
> >>>
> >>>
> >>> On 01/07/2013 08:14 AM, Pedro Igor Silva wrote:
> >>>> Yeah, the class name is not good and leads to confusion. Today you do
> not need any extra code to get encoded passwords. The code you pointed out
> is already doing that:
> https://github.com/picketlink/TODO/blob/master/server/src/main/java/org/aerogear/todo/server/security/register/RegistrationEndpoint.java#L85Behind the scenes it is using SHA-512 and a SecureRandom-1024 salt.
> Unfortunately, you can not change such configuration for now. Regards.
> Pedro Igor ----- Original Message ----- From: "Bruno Oliveira" <
> bruno at abstractj.org> (mailto:bruno at abstractj.org) To: "Pedro Igor Silva" <
> psilva at redhat.com> (mailto:psilva at redhat.com) Cc:
> security-dev at lists.jboss.org (mailto:security-dev at lists.jboss.org) Sent:
> Monday, January 7, 2013 11:49:08 AM Subject: Re: [security-dev] SHA salted
> passwords Hi Pedro, maybe the class name led me to some confusion and I
> missed the real concept here. So, the PlainTextPassword can be used to
> store encoded password which algorithm will be used behin!
>  d!
> >>   the scen
> >> es? Which extra code is necessary to have encoded passwords on
> PicketLink? Could you please provide some example? +1 on EncodedPassword
> class.
> >>>> -- "The measure of a man is what he does with power" - Plato -
> @abstractj - Volenti Nihil Difficile On Monday, January 7, 2013 at 10:20
> AM, Pedro Igor Silva wrote:
> >>>>
> >>>>>> Actually, passwords are not stored in plain text by default. The
> PlainTextPassword is used to store both encoded and plain text passwords. >
> > Maybe we can change the API to better indicate whether you want to use
> encoded passwords or not. Something like this: > > Encoded :
> this.identityManager.updateCredential(user, new
> EncodedPassword(request.getPassword())); > > Plain Text:
> this.identityManager.updateCredential(user, new
> PlainTextPassword(request.getPassword())); > > Where for the
> EncodedPassword type you can specify the different configurations for the
> encoding such as supported algorithms, salt, etc. > > ----- Original
> Message ----- > From: "Bruno Oliveira" <bruno at abstractj.org (mailto:
> bruno at abstractj.org)> (mailto:bruno at abstractj.org%28mailto:
> bruno at abstractj.org%29) > To: security-dev at lists.jboss.org (mailto:
> security-dev at lists.jboss.org) (mailto:security-dev at lists.jboss.org) >
> Sent: Monday, January 7, 2013 7:49:58 AM > Subject: [security-dev] SHA
> salted passwor!
> >> ds > > Go
> >> od morning everyone. > > I'm planning to upgrade AeroGear to
> PicketLink, looking at the examples looks like the passwords will be stored
> in plain text > (
> https://github.com/picketlink/TODO/blob/master/server/src/main/java/org/aerogear/todo/server/security/register/RegistrationEndpoint.java#L85).
> > > I was just wondering if ShaSaltedPasswordHash (
> https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordHash.java#L13)
> > could replace PlainTextPassword in this example, because I don't want to
> provide examples to our users with passwords stored in plain text. > > Is
> it possible? > > > -- > "The measure of a man is what he does with power" -
> Plato > - > @abstractj > - > Volenti Nihil Difficile > > > >
> _______________________________________________ > security-dev mailing list
> > security-dev at lists.jboss.org (mailto:security-dev at lists.jboss.org)
> (mailto:security-dev at lists.jboss.org) > https://lists.jboss.or!
>  g!
> >   /m!
> >> ailman/li
> >> stinfo/security-dev
> >>>> _______________________________________________ security-dev mailing
> list security-dev at lists.jboss.org (mailto:security-dev at lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/security-dev
> >>>
> >>> _______________________________________________
> >>> security-dev mailing list
> >>> security-dev at lists.jboss.org (mailto:security-dev at lists.jboss.org)
> >>> https://lists.jboss.org/mailman/listinfo/security-dev
> >>
> >>
> >> _______________________________________________
> >> security-dev mailing list
> >> security-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/security-dev
> >>
> >> _______________________________________________
> >> security-dev mailing list
> >> security-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/security-dev
> > _______________________________________________
> > security-dev mailing list
> > security-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/security-dev
>
>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130107/8c3b791f/attachment.html 