[security-dev] SHA salted passwords
sbryzak at redhat.com
Mon Jan 7 10:45:41 EST 2013
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.
> 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:
>> Behind the scenes it is using SHA-512 and a SecureRandom-1024 salt. Unfortunately, you can not change such configuration for now.
>> Pedro Igor
>> ----- Original Message -----
>> From: "Bruno Oliveira"<bruno at abstractj.org>
>> To: "Pedro Igor Silva"<psilva at redhat.com>
>> Cc:security-dev at lists.jboss.org
>> Sent: Monday, January 7, 2013 11:49:08 AM
>> Subject: Re: [security-dev] SHA salted passwords
>> Hi Pedro, maybe the class name led me to some confusion and I missed the real concept here. So, the PlainTextPassword can be used to store encoded password which algorithm will be used 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 at abstractj.org (mailto:bruno at abstractj.org)>
>>> >To:security-dev at lists.jboss.org (mailto:security-dev at lists.jboss.org)
>>> >Sent: Monday, January 7, 2013 7:49:58 AM
>>> >Subject: [security-dev] SHA salted 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
>>> >I was just wondering if ShaSaltedPasswordHash (https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordHash.java#L13)
>>> >could replace PlainTextPassword in this example, because I don't want to provide examples to our users with passwords stored in plain text.
>>> >Is it possible?
>>> >"The measure of a man is what he does with power" - Plato
>>> >Volenti Nihil Difficile
>>> >security-dev mailing list
>>> >security-dev at lists.jboss.org (mailto:security-dev at lists.jboss.org)
>> security-dev mailing list
>> security-dev at lists.jboss.org
> security-dev mailing list
> security-dev at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the security-dev