Hacker News new | ask | show | jobs
by al2o3cr 4527 days ago
Sure, that sounds brilliant: allow anybody who can compute a hash collision to poison other sites' JS libraries. facepalm
3 comments

That's not hash collision, that's hash preimage attack.

If you can perform hash preimage attack, then faking a JS library is aiming really low.

• You could forge any SSL certificate.

• You could forge any PGP/GPG message (public key crypto is not applied to whole messages, only hashes of them, same with certs).

• You could maliciously modify Git repositories, even those with GPG signed releases like the Linux kernel.

• You could inject malware into any package repository, MITM software updates for all OSes, etc.

Basically security of the entire Internet and all secure software distribution depends on the fact that preimage attack against crypto hashes is impossible (i.e. time and/or energy required to perform a brute-force attack is literally astronomical).

A slightly more sensible approach may be to allow script tags (or any external linking mechanism) to list multiple (trusted) sources, and fallback appropriately.

That certainly feels more inline with how the internet in general was designed.

    <script src="googleapi/jquery,code.jquery.com/jquery,/my/own/version/jquery">
The point they were making is that googleapi and code.jquery.com don't count as trusted (at least not until you verify the hash)
The domains are obviously trusted to a degree. The objective of the hash is just to allow a content addressed[0] clientside web cache, and avoid talking to them most of the time. Good for privacy, security and load times.

[0] http://en.wikipedia.org/wiki/Content-addressable_storage

If you can create arbitrary collisions with something cryptographically secure like SHA-256, malicious jquery is probably the least of our worries.