3:49 a.m.
Good 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
6:20 a.m.
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>
To: security-dev(a)lists.jboss.org
Sent: Monday, January 7, 2013 7:49:58 AM
Subject: [security-dev] SHA salted passwords
Good 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
https://lists.jboss.org/mailman/listinfo/security-dev
7:49 a.m.
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 scenes?
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)>
To: security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
Sent: Monday, January 7, 2013 7:49:58 AM
Subject: [security-dev] SHA salted passwords
Good 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)
https://lists.jboss.org/mailman/listinfo/security-dev
8:14 a.m.
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/a...
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>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: security-dev(a)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 scenes?
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)>
To: security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
Sent: Monday, January 7, 2013 7:49:58 AM
Subject: [security-dev] SHA salted passwords
Good 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)
https://lists.jboss.org/mailman/listinfo/security-dev
8:18 a.m.
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.
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/a...
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>
To: "Pedro Igor Silva"<psilva(a)redhat.com>
Cc: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 scenes?
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)>
> >To: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 passwords
> >
> >Good 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/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)
> >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
8:58 a.m.
--
"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/a...
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(a)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(a)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 passwords > > 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/mailman/li
stinfo/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 (mailto:security-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/security-dev
9:27 a.m.
+1
----- Original Message -----
From: "Bruno Oliveira" <bruno(a)abstractj.org>
To: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
Cc: security-dev(a)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/a...
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(a)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(a)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 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 (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
9:33 a.m.
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(a)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/a...
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(a)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(a)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 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 (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
9:35 a.m.
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
9:57 a.m.
It's actually currently a unique salt per account, but we need to change
it to unique salt per password (see getSalt() method in [1]). I'm also
-1 for EncodedPassword, as it doesn't fit the design of the credential
handler SPI. What we probably really need is an
EncodedPasswordCredentialHandler, similar to [1] which will manage the
persistence of a PlainTextPassword however provide a pluggable mechanism
for controlling the encoding process. This will require some additional
changes though to the SPI to support overriding the default credential
handlers (not a major problem though).
[1]
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...
On 08/01/13 01:35, Anil Saldhana wrote:
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 !
>> PlainTextP
>> assword 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
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
10:28 a.m.
Why not just drop "PlainText" from the class name and keep it Password?
Most of the passwords are character based. If we are going to call it
PlainTextPassword, irrespective of pluggable encoding/masking
functionality under the covers, it will send jitters in developers' spines.
On 01/07/2013 09:57 AM, Shane Bryzak wrote:
It's actually currently a unique salt per account, but we need to
change it to unique salt per password (see getSalt() method in [1]).
I'm also -1 for EncodedPassword, as it doesn't fit the design of the
credential handler SPI. What we probably really need is an
EncodedPasswordCredentialHandler, similar to [1] which will manage the
persistence of a PlainTextPassword however provide a pluggable
mechanism for controlling the encoding process. This will require
some additional changes though to the SPI to support overriding the
default credential handlers (not a major problem though).
[1]
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...
On 08/01/13 01:35, Anil Saldhana wrote:
> 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 !
>>> PlainTextP
>>> assword 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
>
>
>
> _______________________________________________
> 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
10:32 a.m.
I've got no problem with that...are there any other types of passwords
besides text passwords anyway?
On 08/01/13 02:28, Anil Saldhana wrote:
Why not just drop "PlainText" from the class name and keep
it
Password? Most of the passwords are character based. If we are going
to call it PlainTextPassword, irrespective of pluggable
encoding/masking functionality under the covers, it will send jitters
in developers' spines.
On 01/07/2013 09:57 AM, Shane Bryzak wrote:
> It's actually currently a unique salt per account, but we need to
> change it to unique salt per password (see getSalt() method in [1]).
> I'm also -1 for EncodedPassword, as it doesn't fit the design of the
> credential handler SPI. What we probably really need is an
> EncodedPasswordCredentialHandler, similar to [1] which will manage
> the persistence of a PlainTextPassword however provide a pluggable
> mechanism for controlling the encoding process. This will require
> some additional changes though to the SPI to support overriding the
> default credential handlers (not a major problem though).
>
> [1]
>
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...
>
> On 08/01/13 01:35, Anil Saldhana wrote:
>> 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 !
>>>> PlainTextP
>>>> assword 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
>>
>>
>>
>> _______________________________________________
>> 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
10:38 a.m.
I don't think so. If certificates etc are used, they can be separate
fields in the DB table.
As guidance, let us look at ldap servers. LDAP SDK/JNDI API allow bind
and update of userPassword (standard ldap schema attribute). Security of
the passwords is done by the ldap servers. The API is ignorant of the
mechanisms used.
In the case of DB servers, the IDM will have to do all the plumbing to
secure the passwords and cannot rely on DB security. Given this, I think
we should let developers just deal with password and the underlying
plugged mechanisms of IDM can handle salting/hashing, bcrypt, encryption
etc.
Most of the developers will probably use the default
encoding/masking/salting password mechanism IDM will ship with. Advanced
developers should be able to plug in their favorite schemes if they desire.
On 01/07/2013 10:32 AM, Shane Bryzak wrote:
I've got no problem with that...are there any other types of
passwords
besides text passwords anyway?
On 08/01/13 02:28, Anil Saldhana wrote:
> Why not just drop "PlainText" from the class name and keep it
> Password? Most of the passwords are character based. If we are going
> to call it PlainTextPassword, irrespective of pluggable
> encoding/masking functionality under the covers, it will send jitters
> in developers' spines.
>
> On 01/07/2013 09:57 AM, Shane Bryzak wrote:
>> It's actually currently a unique salt per account, but we need to
>> change it to unique salt per password (see getSalt() method in
>> [1]). I'm also -1 for EncodedPassword, as it doesn't fit the design
>> of the credential handler SPI. What we probably really need is an
>> EncodedPasswordCredentialHandler, similar to [1] which will manage
>> the persistence of a PlainTextPassword however provide a pluggable
>> mechanism for controlling the encoding process. This will require
>> some additional changes though to the SPI to support overriding the
>> default credential handlers (not a major problem though).
>>
>> [1]
>>
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...
>>
>> On 08/01/13 01:35, Anil Saldhana wrote:
>>> 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 !
>>>>> PlainTextP
>>>>> assword 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
noon
Since the IdentityManager.updateCredential method expects a credential
of Object type, it is legal to use a String as credential. I think the
implementation should be aware of cases when developers just plug in a
string value. The internal magic needs to happen to convert the String
to any object representation desired.
On 01/07/2013 10:38 AM, Anil Saldhana wrote:
I don't think so. If certificates etc are used, they can be
separate
fields in the DB table.
As guidance, let us look at ldap servers. LDAP SDK/JNDI API allow
bind and update of userPassword (standard ldap schema attribute).
Security of the passwords is done by the ldap servers. The API is
ignorant of the mechanisms used.
In the case of DB servers, the IDM will have to do all the plumbing to
secure the passwords and cannot rely on DB security. Given this, I
think we should let developers just deal with password and the
underlying plugged mechanisms of IDM can handle salting/hashing,
bcrypt, encryption etc.
Most of the developers will probably use the default
encoding/masking/salting password mechanism IDM will ship with.
Advanced developers should be able to plug in their favorite schemes
if they desire.
On 01/07/2013 10:32 AM, Shane Bryzak wrote:
> I've got no problem with that...are there any other types of
> passwords besides text passwords anyway?
>
> On 08/01/13 02:28, Anil Saldhana wrote:
>> Why not just drop "PlainText" from the class name and keep it
>> Password? Most of the passwords are character based. If we are
>> going to call it PlainTextPassword, irrespective of pluggable
>> encoding/masking functionality under the covers, it will send
>> jitters in developers' spines.
>>
>> On 01/07/2013 09:57 AM, Shane Bryzak wrote:
>>> It's actually currently a unique salt per account, but we need to
>>> change it to unique salt per password (see getSalt() method in
>>> [1]). I'm also -1 for EncodedPassword, as it doesn't fit the design
>>> of the credential handler SPI. What we probably really need is an
>>> EncodedPasswordCredentialHandler, similar to [1] which will manage
>>> the persistence of a PlainTextPassword however provide a pluggable
>>> mechanism for controlling the encoding process. This will require
>>> some additional changes though to the SPI to support overriding the
>>> default credential handlers (not a major problem though).
>>>
>>> [1]
>>>
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...
>>>
>>> On 08/01/13 01:35, Anil Saldhana wrote:
>>>> 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 !
>>>>>> PlainTextP
>>>>>> assword 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
>>>>>>>
2:08 p.m.
That shouldn't be too hard, we just need to amend the
PasswordCredentialHandler by adding String to the list of supported
credential types, i.e:
@SupportsCredentials({ UsernamePasswordCredentials.class,
Password.class, String.class })
Then we need to add support for String credentials to the update() method.
On 10/01/13 04:00, Anil Saldhana wrote:
Since the IdentityManager.updateCredential method expects a
credential
of Object type, it is legal to use a String as credential. I think
the implementation should be aware of cases when developers just plug
in a string value. The internal magic needs to happen to convert the
String to any object representation desired.
On 01/07/2013 10:38 AM, Anil Saldhana wrote:
> I don't think so. If certificates etc are used, they can be separate
> fields in the DB table.
>
> As guidance, let us look at ldap servers. LDAP SDK/JNDI API allow
> bind and update of userPassword (standard ldap schema attribute).
> Security of the passwords is done by the ldap servers. The API is
> ignorant of the mechanisms used.
>
> In the case of DB servers, the IDM will have to do all the plumbing
> to secure the passwords and cannot rely on DB security. Given this, I
> think we should let developers just deal with password and the
> underlying plugged mechanisms of IDM can handle salting/hashing,
> bcrypt, encryption etc.
>
> Most of the developers will probably use the default
> encoding/masking/salting password mechanism IDM will ship with.
> Advanced developers should be able to plug in their favorite schemes
> if they desire.
>
> On 01/07/2013 10:32 AM, Shane Bryzak wrote:
>> I've got no problem with that...are there any other types of
>> passwords besides text passwords anyway?
>>
>> On 08/01/13 02:28, Anil Saldhana wrote:
>>> Why not just drop "PlainText" from the class name and keep it
>>> Password? Most of the passwords are character based. If we are
>>> going to call it PlainTextPassword, irrespective of pluggable
>>> encoding/masking functionality under the covers, it will send
>>> jitters in developers' spines.
>>>
>>> On 01/07/2013 09:57 AM, Shane Bryzak wrote:
>>>> It's actually currently a unique salt per account, but we need to
>>>> change it to unique salt per password (see getSalt() method in
>>>> [1]). I'm also -1 for EncodedPassword, as it doesn't fit the
>>>> design of the credential handler SPI. What we probably really
>>>> need is an EncodedPasswordCredentialHandler, similar to [1] which
>>>> will manage the persistence of a PlainTextPassword however provide
>>>> a pluggable mechanism for controlling the encoding process. This
>>>> will require some additional changes though to the SPI to support
>>>> overriding the default credential handlers (not a major problem
>>>> though).
>>>>
>>>> [1]
>>>>
https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/ja...
>>>>
>>>> On 08/01/13 01:35, Anil Saldhana wrote:
>>>>> 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 !
>>>>>>> PlainTextP
>>>>>>> assword 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
https://lists.jboss.org/mailman/listinfo/security-dev
9:48 a.m.
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(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(a)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/a...
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(a)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(a)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 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 (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
9:58 a.m.
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(a)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(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(a)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/a...
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(a)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 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(a)abstractj.org (mailto:
bruno(a)abstractj.org)> (mailto:bruno@abstractj.org%28mailto:
bruno(a)abstractj.org%29) > To: security-dev(a)lists.jboss.org (mailto:
security-dev(a)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.or!
g!
> /m!
>> ailman/li
>> stinfo/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 (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
_______________________________________________
security-dev mailing list
security-dev(a)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
9:45 a.m.
As far as I'm aware we never ever store a plain text password, and I'll
be sure to recommend against it in the documentation when it gets
written. There's two parts to the credential handler SPI, one side of
it is the side that the developer interacts with directly to validate or
update a user's (plain text) password credential. For this part it
makes sense to have the class called PlainTextPassword, because that's
exactly what is being passed. The other side is the actual persisting
of the credential, which is totally up to the IdentityStore and/or
CredentialHandler implementation. In the case of passwords, we
calculate and store a salted SHA-hash for the password (represented by
the SHASaltedPasswordHash class) which is what gets stored by the
IdentityStore in the database/wherever. If there is any confusion about
this then I'll make sure it's explained clearly in the docs.
On 08/01/13 00:18, 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
allow1 configuration of salting/hashing mechanisms.
We should not at any cost save plain text passwords in the tables.
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/a...
>
> 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>
> To: "Pedro Igor Silva"<psilva(a)redhat.com>
> Cc: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 scenes?
>
> 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)>
>> >To: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 passwords
>> >
>> >Good 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/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)
>> >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
4856
days inactive
4859
days old
17 comments
5 participants
participants (5)
-
Anil Saldhana -
Bruno Oliveira -
Jason Porter -
Pedro Igor Silva -
Shane Bryzak