That would mean RIPE NCC did not do anything while people has been aware of this fact since 2 years ?<br><br><div class="gmail_quote">On Tue, Nov 8, 2011 at 1:42 PM, Micha Borrmann <span dir="ltr"><<a href="mailto:ripe@syss.de">ripe@syss.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Am 08.11.2011 13:14, schrieb virtu virtualabs:<br>
<div class="im"><br>
> I agree the fact that grabbing all the existing maintainers hashes is<br>
> completely feasible since I did it during previous days �(in order to<br>
> assess their strength, not to disclose them). I made some tests with the<br>
> help of a friend of mine, and we recovered at least 4% of these<br>
> passwords only by testing a very popular wordlist (rockyou), and the<br>
> recovery process is still running.<br>
><br>
> We were amazed to see how many maintainers use weak passwords to protect<br>
> their datas, sometimes using their alias as a password. Therefore, I<br>
> totally agree with David and would ask that some constraints should be<br>
> added while creating MD5(UNIX) hashes through RIPE's website dedicated<br>
> page (<a href="https://apps.db.ripe.net/crypt/" target="_blank">https://apps.db.ripe.net/crypt/</a>). This webpage is also recommended<br>
> by ARIN and modifying the way passwords are hashed (and checked ?)<br>
> should be better for both RIPE NCC and ARIN.<br>
><br>
> Telling people not to use twice a generated hash could also help a bit<br>
> more ;)<br>
><br>
> My goal is not to recover every possible password from public hashes but<br>
> just demonstrate that it does not follow currently best-practices in<br>
> term of security.<br>
<br>
</div>This is an old story for myself. It was reported by the german magazin<br>
"DER SPIEGEL" two years ago<br>
(<a href="http://www.spiegel.de/spiegel/print/d-65243798.html" target="_blank">http://www.spiegel.de/spiegel/print/d-65243798.html</a>).<br>
<div class="im HOEnZb"><br>
> On Tue, Nov 8, 2011 at 12:58 PM, David Freedman<br>
</div><div class="im HOEnZb">> <<a href="mailto:david.freedman@uk.clara.net">david.freedman@uk.clara.net</a> <mailto:<a href="mailto:david.freedman@uk.clara.net">david.freedman@uk.clara.net</a>>> wrote:<br>

><br>
> � � I don't mind it continuing to be used over encrypted channels,<br>
> � � as long as the hashes are not available to the general public (as<br>
> � � per your<br>
> � � previous mail)<br>
><br>
> � � I would support a warning phase<br>
><br>
> � � Dave.<br>
><br>
><br>
><br>
> � � On 08/11/2011 11:56, "Shane Kerr" <<a href="mailto:shane@time-travellers.org">shane@time-travellers.org</a><br>
</div><div class="HOEnZb"><div class="h5">> � � <mailto:<a href="mailto:shane@time-travellers.org">shane@time-travellers.org</a>>> wrote:<br>
><br>
> � � >David,<br>
> � � ><br>
> � � >On Tue, 2011-11-08 at 09:38 +0000, David Freedman wrote:<br>
> � � >> I'd like to see auth: MD5-PW deprecated , even though it seems to be<br>
> � � >> widely used (for various reasons)<br>
> � � >> according to the report by DB presented to us.<br>
> � � ><br>
> � � >I propose that we deprecate �passwords over unencrypted channels. AFAIK<br>
> � � >this just means e-mail today, although the web API stuff may also<br>
> � � >provide an non-TLS option (I don't know).<br>
> � � ><br>
> � � >Unlike hiding MD5, this is a major change for users, and would need to<br>
> � � >be done with the same caution and preparation as similar large changes<br>
> � � >in the past. We could have a warning phase, where anyone using a<br>
> � � >password in email would get a scary warning in the reply telling<br>
> � � them to<br>
> � � >use a more secure scheme (PGP, X.509, webupdates, or database web API).<br>
> � � >The RIPE NCC could identify heavy users and help them convert their<br>
> � � >tools. And eventually we could flip the switch and turn off plain text<br>
> � � >passwords.<br>
<br>
<br>
</div></div></blockquote></div><br>