This WordPress release download compromise is exactly the sort of thing I had in mind when I thought up Link Fingerprints for Firefox and other WWW clients. If the download URLs on the WordPress website and in the release announcement emails had had a fingerprint attached, then any supporting clients would have complained, and the admins would probably have found out far sooner than 3-4 days after the compromise.
Note that not everyone’s client would have needed to support it for it to be useful. Of course, the more clients that support it, the better it is for those individual people, but some level of support in a few clients protects everyone by flagging the problem.
I *really* like this idea. There’s no cost for the user at all — no ugly UI, no unnecessary security alerts, no privacy concerns, no hoops to jump through — and only an insignificant cost for the web developer. If only all security problems were susceptible to this kind of (albeit partial) solution.
…except if someone can change a file on the server, they can most likely change the file containing the link too. :-)
I guess if the fingerprint does get changed along with the file then users will be lulled into a false sense of security when the browser validates the file successfully. Better would be to have the fingerprint stored on a third-party server but that introduces problems of its own.
The system would have worked nicely with the fingerprints in the announcement emails though.
Great idea, but I wonder if it would be better to use !scheme=xxxxx rather than !scheme!xxxxx – seems a bit clearer to me
Jeff: In some cases, perhaps yes – but if you have your server set up well, breaking into one service doesn’t necessarily compromise the others. For example, this guy may have sniffed an FTP password. That doesn’t mean he has access to change the CMS’s content database.
Like I said, it’s not foolproof, but it vastly increases the chances of someone noticing quickly – and like voracity says, there’s almost no downside.
David: The double-pling is a means of separating the name of the extension used from the data to support it. This means you can have other extensions like:
foo.html#!xpath!/html/body/p[3]
foo.html#!s!Some%20text%20to%20search%20for (see blogpost)
“In some cases, perhaps yes – but if you have your server set up well, breaking into one service doesn’t necessarily compromise the others.”
And that’s only thinking about one server. If you have, as Mozilla does, one web server, and an ftp hostname that points to a whole spread of mirrors, then it’s not only 1 service versus another on a server, but also 1 service on 1 server versus services across a whole load of different servers, any of which could be compromised individually.