Client Side Input Validation is Evil
I said it before, and will say it again: All users are evil. Case in point: The recent secure USB key vulnerability.
These USB keys encrypt data stored on the USB key. Great idea! So now, if you loose the key, you no longer have to worry about your top secret image collection getting viewed by minors.
What was the flaw in the implementation? In order to unlock the device, you have to enter your password into software installed on your laptop / desktop. You would expect the software hashes or encrypts the password, sends it to the device, the device uses the hash to decrypt the files stored on the device. WRONG.
In this case, the client software validates the password by encrypting a specific block of data on the drive. Sadly, this block doesn’t change. So these researchers replaced the software with their own tool that just sends this fixed block of data back to the device (they actually just patched the existing software in memory to bypass the password check). To add insult to injury, these scheme was certified as FIPS-140-2 compliant. The FIPS-140 standard is used by the US federal government to certify encryption devices and FIPS-140-2 compliant USB sticks may be used in some government systems that prohibit regular USB devices. Many companies implement similar policies.
As a web developer, this reminded me of input validation using JavaScript on the client. It is nice for user convenience, but should never in lieu of server side input validation. Or using a simple “admin=Y” cookie to identify a user as administrator. Did I mention all users are evil and out to get you?
The original announcement about the USB issue can be found here: http://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/SySS_knackt_Kingston_USB-Stick.pdf
