Security quotes of the week

One of the nastier effects of this (and it didn't start with EFI and 'secure' boot but with Android) is that people are now hoarding kernel security holes rather than reporting them. Previously bad guys hoard them, good ones fixed them. Now everyone is hoarding them so end user security will suffer drastically.

Why not just avoid the entire Secure Boot problem by using Coreboot? Because the reason we have the Secure Boot problem is because Microsoft's Windows 8 certification requirements mean vendors have to ship a UEFI implementation with Secure Boot. You could satisfy that by using Coreboot with a Tiano payload, but it'll still have Secure Boot enabled so you still have the same set of problems. But maybe you could just reflash your system with Coreboot? No, because another part of the requirements states that all firmware updates have to be cryptographically signed now. The only way to reflash will be to attach a flash programmer directly to your motherboard.

So why not just use Coreboot? Because it doesn't help solve this problem in any way.

Deleting intermediate certificates is pointless. You can only rely on revocation (which is known to be very unreliable), _or_ (preferably) you should import the same certificate in the _revocation_ branch of the SYSTEM certificate store. Only in that case you can be certain that the particular certificate will be untrusted (regardless of whether it is present in one of the _trusted_ stores or not).

As the article makes clear, the 6.5 million hashes are likely just those the hackers couldn't crack. The take-away from this is: It means nothing that you don't find your password in the list. Out of an abundance of caution, readers should presume the entire list has been obtained and change their password no matter what.