<div dir="ltr">Sorry dummy question but at application creation time (and when resetting the secret), in the response of the POST , the master secret should be returned to the user, right ? Otherwise he will never get it.<div>
<br></div><div>And second question, I know Security is not often a good mate with UX but , the console will never show the master/variant secret anymore ? </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Apr 16, 2014 at 6:57 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Karel, this not bullet proof but let me try to explain. Currently you<br>
can only send push messages if you have the master secret, currently I<br>
can see two points of vulnerability: 1) client side in possession of<br>
master secret, 2) database storing master secret. We can't do so much<br>
about the former, but we can try to fix the latter.<br>
<br>
What we are trying to avoid here is: if someone have access to the<br>
database, this person should not be able to send push messages — because<br>
master secret is not there. How? Look at this snippet please:<br>
<a href="https://github.com/abstractj/aerogear-unifiedpush-server/commit/a2cb2c6f135aab6d85e1e60e6271ceae445ece1e#diff-9ce4033a33f0606bf0c35537a1fd95bdL84" target="_blank">https://github.com/abstractj/aerogear-unifiedpush-server/commit/a2cb2c6f135aab6d85e1e60e6271ceae445ece1e#diff-9ce4033a33f0606bf0c35537a1fd95bdL84</a><br>
<br>
Previously we had a comparison against the database:<br>
<br>
if (pushApplication != null &&<br>
pushApplication.getMasterSecret().equals(secret))<br>
<br>
The proposal doesn't store the master secret and makes use of a<br>
derivation function which means: given a salt and a password (master<br>
secret), I was supposed to be able to compute the key for further<br>
comparisons — to check if they match.<br>
<br>
Let's see how it works:<br>
<br>
1. The server generates a salt and a master secret (111111)<br>
2. The salt is stored into the database. Master secret, not.<br>
3. Given the master secret we compute the key<br>
(<a href="https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293#diff-dc07653bd3c83d4e82c45b70d8ad34dfR177" target="_blank">https://github.com/abstractj/aerogear-unifiedpush-server/commit/a9993c35edc39501eef7d7a26f3d8ea29b38e293#diff-dc07653bd3c83d4e82c45b70d8ad34dfR177</a>)<br>
4. Store it for further comparisons<br>
5. The following key is generated:<br>
FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk=<br>
<br>
What would happen if someone get access to DB?<br>
<br>
1. Evil gets access to the database<br>
2. Manage to retrieve the key: FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk=<br>
3. Now Evil try to send push messages<br>
4. The following code will attempt to validate:<br>
FPj+xcfeoR5vJdi6SsqxiT0WK8cv4PesQ0jpDMYdTYk= but the password was 111111<br>
<br>
You can see the simulation with the following code:<br>
<br>
@Test<br>
public void testEvilScenario() throws Exception {<br>
Pbkdf2 pbkdf2 = AeroGearCrypto.pbkdf2();<br>
String masterSecret = "111111";<br>
byte[] salt = RandomUtils.randomBytes();<br>
//Master secret is never stored into the database<br>
byte[] applicationSecret = pbkdf2.encrypt(masterSecret);<br>
// Now Evil stole the applicationSecret.<br>
// Providing String pushApplicationID = credentials[0]; String secret =<br>
credentials[1];<br>
// First the is stored in an array of bytes and validate method do not<br>
support byte array as parameter<br>
// No problem, we can attempt to convert to BASE64<br>
String evilMasterSecret = Base64.BASE64.encode(applicationSecret);<br>
//Now lets try to compute the key<br>
assertTrue("Key is not valid", pbkdf2.validate(evilMasterSecret,<br>
applicationSecret, salt));<br>
}<br>
<br>
Let me know if you have more questions.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Karel Piwko wrote:<br>
> Still not there.<br>
><br>
> If we store *secret key* and *salt* in DB, whoever gets access to DB can<br>
> compute derived key via PDKDF2, right?<br>
><br>
> Is the security increased because hackers need to acquire two values instead of<br>
> one?<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
abstractj<br>
<br>
<br>
</font></span><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>