Friday, October 26, 2012

Anyone who pays any attention to DRM will extrapolate the general principle:

You can never prevent an end-user who has physical control of a device from breaking any DRM scheme you can invent.

Sony just learned their DRM lesson (again). I'm sure that people at Sony already know this principle, but some "suit" tells the engineers to "do something about the problem" so they implement a technical speed bump. That's all it is and will ever be.

Thursday, October 18, 2012

Wouldn't it be really scary if physical locks in large planned cities like NYC were designed to use skeleton keys-- master keys that are shared with do-gooder firefighters and locksmiths alike-- without ever thinking what could happen if such keys got into realm of the average Joe, whose do-gooder status was unknown? Yep it would.

Look but don't pay attention to key teeth details!

Wouldn't it be even scarier if those who cried "the sky is falling, the sky is falling" also were dumb enough to post high res photos of the skeleton keys on their websites (pictured left) so that anyone with access to key blanks and tools could easily measure and create their own skeleton key copies? Again, yes.

Saturday, October 6, 2012

It's very common for Hello World example apps in textbooks or other educational literature to promote insecure software building practices right out of the gate. What a breath of fresh air to see the Microsoft MVC folks safely HTML encoding (to avoid XSS) in their MVC4 Hello World application!

Friday, October 5, 2012

With the news containing stories of malware distributing via compromised Certificate Authorities, it makes sense that some IT Security blogs would address "what to do" if this happens to your CA. This blog post gets it wrong, though:

What would you do if you found out that the Certificate Authority
that provides Digital Certificates to your company was compromised, and
Microsoft was adding the Certificate Authority’s public key to Windows
un-trusted Root Store? Well if you have not got a contingency plan to
implement then I can presume you will be in a panic to purchase new
certificates from another Certificate Authority... It can take Certificate
Authority’s (CA’s) a few days to validate domain ownership and company
registration details... While all this is
happening your customers are getting a message from Internet Explorer
that your SSL certificate is not to be trusted.

What can you do?

Do not rely on one Certificate Authority for all of your certificates. You should have a relationship with at least two well known Certificate Authority’s and the CA’s should have validated all of your domains. This will let you quickly order Digital Certificates from the second CA without having to go through the company validation process...

If you cannot tolerate any downtime for a service you can take the extra step in which you create backup certificates for each service using your backup Certificate Authority. This will enable you to implement the backup certificates without having to contact the second CA and joining the queue of company’s looking for new certificates.

Keep in mind that the worst-case scenario described above would require the Root CA Certificate to be compromised. Most Root CAs are offline certs, meaning the computers that house them are not powered on except during special circumstances when new intermediate CA certificates are generated, OR, they are online in an "air gap" (disconnected from the internet) network accessible only via sneakernet. Exploiting an offline CA is a big deal, and if it occurs it won't be just your organization that is affected, but likely a large part of the entire internet.

So a much more plausible option:

The CA will just create a new intermediate CA cert
and re-issue client certs to all of its paying customers.