Unique salt per password and hashed. This is the default scheme we plan
to use when users just send plain text passwords to IDM. The
EncodedPassword type will have pluggable mechanisms that can vary in
security (including encryption).
On 01/07/2013 09:33 AM, 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(a)redhat.com> wrote:
> >+1
> >
> >----- Original Message -----
> >From: "Bruno Oliveira"<bruno(a)abstractj.org>
> >To: "Anil Saldhana"<Anil.Saldhana(a)redhat.com>
> >Cc:security-dev@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/...
Behind 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(a)abstractj.org>
(mailto:bruno@abstractj.org) To: "Pedro Igor Silva"<psilva(a)redhat.com>
(mailto:psilva@redhat.com) Cc:security-dev@lists.jboss.org
(mailto:security-dev@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 behind!
> > 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(a)abstractj.org (mailto:bruno@abstractj.org)>
(mailto:bruno@abstractj.org%28mailto:bruno@abstractj.org%29) >
To:security-dev@lists.jboss.org (mailto:security-dev@lists.jboss.org)
(mailto:security-dev@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/a...).
> > I was just wondering if ShaSaltedPasswordHash
(
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...)
> 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(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
(mailto:security-dev@lists.jboss.org) >https://lists.jboss.org!
/m!
> >ailman/li
> >stinfo/security-dev
>>> >>>
>>> >>>_______________________________________________ security-dev
mailing listsecurity-dev(a)lists.jboss.org
(mailto:security-dev@lists.jboss.org)https://lists.jboss.org/mailman/listinfo/security-dev
>> >>
>> >>
>> >>_______________________________________________
>> >>security-dev mailing list
>> >>security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
>> >>https://lists.jboss.org/mailman/listinfo/security-dev
> >
> >
> >
> >_______________________________________________
> >security-dev mailing list
> >security-dev(a)lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/security-dev
> >
> >_______________________________________________
> >security-dev mailing list
> >security-dev(a)lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev