<div>I doubt people use Last.fm, but they had a leak too. </div><div><br clear="all">--Cameron<a href="http://ghostfreeman.net" target="_blank"></a><br>
<br><br><div class="gmail_quote">On Fri, Jun 8, 2012 at 10:13 AM, Tim Watts <span dir="ltr"><<a href="mailto:tim@cliftonfarm.org" target="_blank">tim@cliftonfarm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Makes sense now. Thanks!<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, 2012-06-08 at 09:58 -0400, Michael H. Warfield wrote:<br>
> On Fri, 2012-06-08 at 08:54 -0400, Tim Watts wrote:<br>
> > Thanks for this Mike. Great lesson as usual!<br>
><br>
> > On Thu, 2012-06-07 at 22:56 -0400, Michael H. Warfield wrote:<br>
><br>
> > RE Salts:<br>
> > > So it prevents some optimization in brute forcing<br>
> > > large tables of passwords (like the Linkedin dump).<br>
><br>
> > I guess I don't quite see this. If the salt is invariably stored with<br>
> > the hash this sounds a bit like claiming base64 is a form of encryption.<br>
> > The only way I can make sense of this is if the encoding of or<br>
> > association between the salt and hash is somehow a system secret. Or if<br>
> > you don't know the hashes are salted. Am I missing something?<br>
><br>
> Without salt, the attacker would take a brute force password guess and<br>
> hash it once and compare that hash to all the hashes in the database.<br>
> One hash operation per guess to do all the hashes in the table and it's<br>
> a straight compare.<br>
><br>
> With salt, you have to hash your password with the hash salt that's<br>
> there for each entry in the table. So, if you have 6.5 million entries<br>
> in the compromised hash table you would likely have to hash the guess<br>
> with each individual salt (6.5 million is still a very tiny percentage<br>
> of even 2^48 so collisions are almost non-existent) resulting in 6.5<br>
> million hash operations where you would only have needed 1 hash<br>
> operation without the salts. 6,500,000:1 is quite an optimization and<br>
> that's why I said "large tables". The larger the table, the bigger the<br>
> effect.<br>
><br>
> The hash is a one-way function. Even with the salt present with the<br>
> hash (necessary for verification) you can't reverse the hash back to the<br>
> password so the presence of the salt doesn't weaken the hash. It's not<br>
> any more secret than the hash itself and is necessary to compute the<br>
> hash given a password to test and verify.<br>
><br>
> Here... I'll give you an example from the shadow file (no, it's not an<br>
> active account but it's a real hash, you can try and brute force it if<br>
> you like...)<br>
><br>
> *****:$1$mVyvPlQz$M02ivX0uzi6al7vWWu5X6.:15499:1:::::<br>
> ^^^^^^^^^^^^^^^^^^^^^^ Hash<br>
> ^^^^^^^^ 48 bit salt - almost 3 * 10^14 possibilities.<br>
> ^^ Algorithm 1 - md5<br>
><br>
> This is a SHA512 hash pulled from a web page I had handy...<br>
><br>
> *****:$6$QR3drPrQ$JLolPKyiVuXvea1F2IpbPx9F9PEV0s/IGcNCpm6ZrBA6AFDvwHPQG7EsTQHuUqxfCvlsuKRb.O7w5RLPyj8nS/:15119:0:99999:7:::<br>
><br>
> Same format, just algorithm 6, sha512.<br>
><br>
> With the salt, you can hash a password the user enters and, if it then<br>
> matches the hash you expect, you have a verification match. That salt<br>
> has to be present with the hash at the point and time of verification.<br>
> In theory, they could be stored in different locations but, in practice,<br>
> that really doesn't buy you much since they have to be retrieved<br>
> together and are tightly associated, so they're generally stored<br>
> together. If that table is compromised, the brute force attacker would<br>
> then merely take the salt, combine it with the password he's using to<br>
> guess, and then compare. But, without a salt, he only has to hash the<br>
> password once and do a simple compare to all the entries. Grep would do<br>
> the job.<br>
><br>
> Regards,<br>
> Mike<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Ale mailing list<br>
> <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
> <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
> See JOBS, ANNOUNCE and SCHOOLS lists at<br>
> <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br>
</div></div><br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br></div>