[OpenWrt-Devel] r46816, remove unused crypt() algorithms -> switch to sha512?

[Etienne Champetier]

Hi,

Le 15 sept. 2015 01:40, "Felix Fietkau" <nbd at openwrt.org> a écrit :
>
> On 2015-09-15 00:22, Etienne Champetier wrote:
> > Hi Felix,
> >
> > Maybe we should keep sha512 and switch to it? md5 is not best security
> > practice these days.
> I don't see the point. It's true that for file integrity purposes, md5
> is weaker than sha512, but for salted passwords it should not make much
> of a practical difference. Cryptographic attacks against MD5 don't work
> here, brute force is still the fastest way to crack those.

Yep, and there is a 100x between md5 and sha512, so it does matter a bit
http://blog.codinghorror.com/speed-hashing/

>
> > I've checked, ubuntu 14.04 and fedora 22 both use sha512 in /etc/shadow
> Not a very convincing reason for me. The impractical aspect of switching
> password hashing algorithms is that we then need to support both the new
> one and the old one for a long time.

If 5k is the cost of some more security, i'm personnaly OK to pay the price

>
> > I wonder if AF_ALG can be of any interest here (integrate needed algo by
> > default into the kernel, then patch core software to use kernel
> > implementation)
> That would just make it more bloated without making any real practical
> difference. This approach would be especially bad for CPU intensive
> crypto if the kernel can only do software crypto. In that case bouncing
> between kernel and user space would waste many CPU cycles.
>
> > To conclude maybe you should emit a clear error when we try a now
> > unsupported hash,
> > because crypt can be used by other app, so maybe you just broke another
> > app and someone will waste a good amount of time debugging it
> I don't think anything's using crypt() with a custom generated non-md5
> salt. Most programs that store password hashes simply do their own crypto.

I will send a patch for this part

>
> - Felix

Regards,
Etienne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150915/1b64fe3e/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel