<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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:<br>
<br>
@SupportsCredentials({ UsernamePasswordCredentials.class,
Password.class, String.class })<br>
<br>
Then we need to add support for String credentials to the update()
method.<br>
<br>
On 10/01/13 04:00, Anil Saldhana wrote:<br>
</div>
<blockquote cite="mid:50EDB03D.5080007@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">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.<br>
<br>
On 01/07/2013 10:38 AM, Anil Saldhana wrote:<br>
</div>
<blockquote cite="mid:50EAF9FE.7040106@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">I don't think so. If certificates
etc are used, they can be separate fields in the DB table. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
On 01/07/2013 10:32 AM, Shane Bryzak wrote:<br>
</div>
<blockquote cite="mid:50EAF8AD.8070508@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">I've got no problem with
that...are there any other types of passwords besides text
passwords anyway?<br>
<br>
On 08/01/13 02:28, Anil Saldhana wrote:<br>
</div>
<blockquote cite="mid:50EAF7AA.3080502@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">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.<br>
<br>
On 01/07/2013 09:57 AM, Shane Bryzak wrote:<br>
</div>
<blockquote cite="mid:50EAF071.4000708@redhat.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">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).<br>
<br>
[1]
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a moz-do-not-send="true"
href="https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/credential/internal/PlainTextPasswordCredentialHandler.java">https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/credential/internal/PlainTextPasswordCredentialHandler.java</a><br>
<br>
On 08/01/13 01:35, Anil Saldhana wrote:<br>
</div>
<blockquote cite="mid:50EAEB3F.40907@redhat.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">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). <br>
<br>
On 01/07/2013 09:33 AM, Jason Porter wrote:<br>
</div>
<blockquote
cite="mid:D0FEF39D-7FBB-4923-803F-DB0C0810C5E6@gmail.com"
type="cite">
<div class="moz-text-plain" wrap="true"
graphical-quote="true" style="font-family:
-moz-fixed; font-size: 12px;" lang="x-western">
<pre wrap="">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 <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:psilva@redhat.com"><psilva@redhat.com></a> wrote:
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">> </span>+1
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>----- Original Message -----
<span class="moz-txt-citetags">> </span>From: "Bruno Oliveira" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:bruno@abstractj.org"><bruno@abstractj.org></a>
<span class="moz-txt-citetags">> </span>To: "Anil Saldhana" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a>
<span class="moz-txt-citetags">> </span>Cc: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<span class="moz-txt-citetags">> </span>Sent: Monday, January 7, 2013 12:58:01 PM
<span class="moz-txt-citetags">> </span>Subject: Re: [security-dev] SHA salted passwords
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>--
<span class="moz-txt-citetags">> </span>"The measure of a man is what he does with power" - Plato
<span class="moz-txt-citetags">> </span>-
<span class="moz-txt-citetags">> </span>@abstractj
<span class="moz-txt-citetags">> </span>-
<span class="moz-txt-citetags">> </span>Volenti Nihil Difficile
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>On Monday, January 7, 2013 at 12:18 PM, Anil Saldhana wrote:
<span class="moz-txt-citetags">> </span>
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>> </span>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.
<span class="moz-txt-citetags">>> </span>
<span class="moz-txt-citetags">>> </span>We should not at any cost save plain text passwords in the tables.
</pre>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> </span>+1 and maybe for a while we could refactor PlainTextPassword to EncodedPassword and avoid some misunderstanding.
<span class="moz-txt-citetags">> </span>
<span class="moz-txt-citetags">> </span>Makes sense?
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>> </span>
<span class="moz-txt-citetags">>> </span>Wdyt?
<span class="moz-txt-citetags">>> </span>
<span class="moz-txt-citetags">>> </span>
<span class="moz-txt-citetags">>> </span>On 01/07/2013 08:14 AM, Pedro Igor Silva wrote:
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>>> </span>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: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/picketlink/TODO/blob/master/server/src/main/java/org/aerogear/todo/server/security/register/RegistrationEndpoint.java#L85">https://github.com/picketlink/TODO/blob/master/server/src/main/java/org/aerogear/todo/server/security/register/RegistrationEndpoint.java#L85</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" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:bruno@abstractj.org"><bruno@abstractj.org></a> (<a moz-do-not-send="true" class="moz-txt-link-freetext" h!
re!="" f="
%21" "m="" %21%0a%2="" 0ai%21%0a%2%0a0lt%21%0a%2%0a0o:%21%0a%2%0a0bruno@abst%0aractj.org"="">mailto:bruno@abstractj.org</a>) To: "Pedro Igor Silva" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:psilva@redhat.com"><psilva@redhat.com></a> (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:psilva@redhat.com">mailto:psilva@redhat.com</a>) Cc: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a> (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:security-dev@lists.jboss.org">mailto:security-dev@lists.jboss.org</a>) 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!
</pre>
</blockquote>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> </span> the scen
<span class="moz-txt-citetags">> </span>es? Which extra code is necessary to have encoded passwords on PicketLink? Could you please provide some example? +1 on EncodedPassword class.
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>>> </span>-- "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:
<span class="moz-txt-citetags">>>> </span>
</pre>
<blockquote type="cite" style="color:
#C0C0C0;">
<blockquote type="cite" style="color:
#C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>>>>> </span>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" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:bruno@abstractj.org%28mailto:bruno@abstractj.org%29"><bruno@abstractj.org (mailto:bruno@abstractj.org)></a> !
(<!--
a moz-do-n
ot-send="true" !="" moz-do-not="" -send="true" mo!="" z-do-not-s="" end="true" moz-!="" do-not-sen="" d="true" moz-do!="" -not-send="true" moz-do-n!="" ot-send="t
rue" class="moz-txt-link-freetext" href="mailto:bruno@abstractj.org%28mailto:bruno@abstractj.org%29"--><a class="moz-txt-link-freetext" href="mailto:bruno@abstractj.org%28mailto:bruno@abstractj.org%29">mailto:bruno@abstractj.org%28mailto:bruno@abstractj.org%29</a>) > To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a> (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:security-dev@lists.jboss.org">mailto:security-dev@lists.jboss.org</a>) (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:security-dev@lists.jboss.org">mailto:security-dev@lists.jboss.org</a>) > Sent: Monday, January 7, 2013 7:49:58 AM > Subject: [security-dev] SHA salted passwor!
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><span class="moz-txt-citetags">> </span>ds > > Go
<span class="moz-txt-citetags">> </span>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 > (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/picketlink/TODO/blob/master/server/src/main/java/org/aerogear/todo/server/security/register/RegistrationEndpoint.java#L85">https://github.com/picketlink/TODO/blob/master/server/src/main/java/org/aerogear/todo/server/security/register/RegistrationEndpoint.java#L85</a>). > > I was just wondering if ShaSaltedPasswordHash (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordHash.java#L13">https://github.com/picketlink/picketlink/blob/master/idm/impl/src/main/java/org/picketlink/idm/password/internal/SHASaltedPasswordHash.java#L13</a>) > 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 > <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a> (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:security-dev@lists.jboss.org">mailto:security-dev@lists.jboss.org</a>) (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:security-dev@lists.jboss.org">mailto:security-dev@lists.jboss.org</a>) > <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org">https://lists.jboss.org</a>!
</pre>
</blockquote>
<pre wrap=""> /m!
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">> </span>ailman/li
<span class="moz-txt-citetags">> </span>stinfo/security-dev
</pre>
<blockquote type="cite" style="color: #C0C0C0;">
<blockquote type="cite" style="color: #C0C0C0;">
<pre wrap=""><span class="moz-txt-citetags">>>> </span>
<span class="moz-txt-citetags">>>> </span>_______________________________________________ security-dev mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a> (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:security-dev@lists.jboss.org">mailto:security-dev@lists.jboss.org</a>) <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a>
</pre>
</blockquote>
<br>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
security-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>