<div dir="ltr">Hey Dirk, <div><br></div><div>I was thinking exactly like you do. I am willing to revert my changes. </div><div><br></div><div>I kind of understand John's concern when we are using the hash function for signature. </div>
<div>If the attacker is trying to fabricate a new message that has the same hash value so that the previously calculated signature by the victim still verifies for the new message. However, in our case here, it does not seem to apply. </div>
<div><br></div><div>Let us consider a case that the attacker has a rainbow table such as</div><div><br></div><div>lhash1 preimage1 preimage2</div><div>lhash2 preimage3</div><div>lhash3 preimage4 </div><div> ... </div><div>
lhash2^128 preimageX</div><div><br></div><div>There has to be 2^128 rows in the hash table. I do not think it has been calculated nor is feasible to search through the table within the response time. </div><div><br></div>
<div>Now, suppose such rainbow table was calculated. Then, using salted hash would actually constrain the search space to 2^32 rows, which makes it significantly easier. </div><div><br></div><div>As long as the rainbow table is not there, it does not seem to matter, but once it is there, it is safer to be without the salt, I suppose. </div>
<div><br></div><div>As usual, I may be completely wrong but... </div><div><br></div><div>Nat</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/29 Dirk Balfanz <span dir="ltr"><<a href="mailto:balfanz@google.com" target="_blank">balfanz@google.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Mon, Jul 29, 2013 at 12:35 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Increasing the length of the secret is no help.</div></blockquote><div><br></div></div>
<div>
But that's exactly what the salt does: it increases the length of the thing that is hashed, thus making it "many orders of magnitude" harder to find the preimage. I still don't see why you need a salt here. If you think your secret is too small, then create a salt, prepend that to the secret, and call the new thing the secret. Salts make sense if the original input into your hash function may be in a dictionary of rainbow table. Here the client has control over the original input (it generates the secret) and can make the probability of that occurring as small as it wants.</div>
<div class="im">
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>The thing is that the password is unstructured so any string that computes to the same hash works.</div>

<div><br></div><div>If you send a literal that needs to be combined with the password by the server then the hash table has to not only match the hash, the string to produce the hash needs to start with the salt. </div></div>

</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>This make brute forcing the hash may orders of magnitude harder with the same hash size.</div>

</div></blockquote><div><br></div></div><div>Wait, what? Telling me a prefix of the pre-image will make it _harder_ for me to find the pre-image? I don't think so. If anything it'll make it easier. What makes it harder is not that I will have to match a certain prefix, it's that the search space is bigger with a salt (or with a bigger secret, for that matter).</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Dirk.</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br>
</div><div>Honest.</div><div><div>
<div><br><div><div>On 2013-07-29, at 9:19 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hmmm. I do not actually get it. <div>

<br></div><div>Salting the hash is equivalent to computing hash ( randome_salt + fixed_secret), is it not? </div><div>Then, like Brian says, having original secret longer and have it being calculated at run-time has the same effect. </div>


<div>i.e., hash (long_dynamic_secret) and hash ( randome_salt + fixed_secret) has the same or better effect as long as </div><div>len (long_dynmaic_secret ) >= len(randome_salt + fixed_secret). </div><div><br></div><div>


If it is a fixed secret, yes, you are right, but it is not. </div><div><br></div><div>Nat</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/29 John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span><br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">If it is just a hash then it can be precomputed.   Adding a random salt that is hashed with the value sent to the token endpoint prevents pre-computation of the hash.<div>


<br></div><div>The issues are the same as with PB-KDF given that we are sending the hash in the clear.  </div><div><br></div><div>Yes but if I am a bed person and there is no per password salt I use a precomputed rainbow table and even if I don't cover the entire space eventually I will find a collision if I intercept enough messages.</div>


<div><div><div><br></div><div><br></div><div><br></div><div><br><div><div>On 2013-07-29, at 8:29 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:</div><br>
<blockquote type="cite"><div dir="ltr">I have thought of that, and I do not think so. <div>Adding salt amounts to expanding the entropy of the input string. </div><div>So, having enough bit length in the transient secret to start with has the same effect. </div>



<div>Since the validity period of the transient secret is rather short, you cannot do the offline attack. </div><div>The attacker has to have the rainbow table to start with. </div><div><br></div><div>What we want to make sure is that len(tcs) > max_len(available rainbow table). </div>



<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/29 John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">Thinking about it overnight we need to also have a salt sent with the hash, to prevent rainbow tables attacks.<div><br><div><div><div>On 2013-07-28, at 9:39 PM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:</div>



<br></div><blockquote type="cite"><div><div dir="ltr">As some of you knows, passing the code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high. <div>




<br></div><div>We have discussed about it during the OpenID Conenct Meeting at IETF 87 today, and I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. </div><div><br></div><div>




You can find it at: </div><div><br></div><div><a href="https://bitbucket.org/Nat/drafts/src/" target="_blank">https://bitbucket.org/Nat/drafts/src/</a></div><div><br></div><div>Comments are welcome. </div><div><div><br></div>



-- <br>Nat Sakimura (=nat)<div>
Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div></div></div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>



</blockquote></div><br></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>



@_nat_en</div>
</div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>


@_nat_en</div>
</div>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div>