<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><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 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("<u></u>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 href="https://github.com/keycloak/keycloak/pull/171" target="_blank">https://github.com/keycloak/<u></u>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>