<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 24.1.2014 12:55, Bruno Oliveira
wrote:<br>
</div>
<blockquote
cite="mid:CAM5SUC40Q4AgXSxqyFke=QfJAcgyz3WRNUKEVx_2Tgcbj2-Mzg@mail.gmail.com"
type="cite">
<div dir="ltr">Let me check if I'm misreading you, are you
considering to make the salt static? If the answer is yes, the
salt would be predictable, no? Not sure if I'm following you on
this.</div>
</blockquote>
No, not salt of course. I meant to have just SecureRandom instance
declared to be static (or maybe not necessarilly static but shared
somehow via something like Picketlink is doing with
SecureRandomProvider or we are doing in GateIn). The expensive part
is initial generation of seed for SecureRandom and if this would
need to be done during each encoding/validation, you will likely see
performance issues. Especially in production environments with many
logins/password validations.<br>
<br>
You can easily try to run the code snippet below couple of times on
your machine and maybe you will see what I meant.<br>
<br>
Marek<br>
<blockquote
cite="mid:CAM5SUC40Q4AgXSxqyFke=QfJAcgyz3WRNUKEVx_2Tgcbj2-Mzg@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<br>
<br>
<div class="gmail_quote">On Fri, Jan 24, 2014 at 7:49 AM, Marek
Posolda <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Bruno,<br>
<br>
that's great improvement. I just want to point the creation
of SecureRandom during each password encoding/validation as
it's platform dependent and quite expensive. We already have
issues with this in GateIn. For example running this on my
laptop:<br>
<br>
public static void main(String[] args) throws
NoSuchAlgorithmException {<br>
SecureRandom.getInstance("SHA1PRNG").nextBytes(new
byte[16]);<br>
}<br>
<br>
is sometimes quick, but sometimes it took about 30 seconds
to finish (depends on available random entropy from
/dev/urandom on linux laptops). So IMO will be better to
have it declared as static variable?<br>
<br>
We already discussed and solved similar issue with
picketlink team some time ago. In the end Picketlink is
using SecureRandomProvider abstraction for retrieve
SecureRandom instance. And default implementation of this
interface is good compromise between security and
performance.<span class="HOEnZb"><font color="#888888"><br>
<br>
Marek</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
On 22.1.2014 13:55, Bruno Oliveira wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Good morning guys, as a suggestion to improve the way
how the passwords have been stored in nowadays I did
some changes to support PBKDF2[1] (we have been doing
the same thing on AeroGear for mobile devices), into
this way is possible to prevent rainbow tables and
brute force attacks like HashCat does for example.<br>
<br>
I'm completely fine on adding bcrypt as long as we
include some KDF, I just didn't that because I would
like to hear some feedback before move forward, not
sure if makes sense but my suggestion is to remove
SHA-* encoders because they can be easily broken and
replace by the support for PBKDF2 and bcrypt only.<br>
<br>
What do you think? Let me know if I should move
forward or that doesn't fit.<br>
<br>
[1] - <a moz-do-not-send="true"
href="https://github.com/keycloak/keycloak/pull/171"
target="_blank">https://github.com/keycloak/keycloak/pull/171</a><br>
<br>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div><br>
</div>
-- <br>
"The measure of a man is what he does with power" - Plato<br>
-<br>
@abstractj<br>
-<br>
Volenti Nihil Difficile
</div>
</blockquote>
<br>
</body>
</html>