Security Means More than a Certificate
In our discussion on architecting for scaling of a three-tier application, Bluedog discusses the various components that make up a secure web solution.
Bluedog takes security seriously, and the coding of Workbench supports our assertion that the best protection for data is to encrypt it when it is at rest. We know that access to encrypted data ultimately comes down to access to the key, and we use a combination of public, private, and symmetric keys to encrypt and decrypt data using RSA, DSA, or DH encryption algorithms in the database that is behind Workbench.
Transport Layer Security (TLS -- and its now-deprecated predecessor SSL, Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser, and, when properly implemented, it assures the end user that data passed between the web server and the user's browsers remains private and intact. It is useful in preventing so-called "man-in-the-middle" snooping on data in transit. But having a certificate doesn't mean data is secure. TLS/SSL certificates have a usability problem because web browsers mark all HTTPS websites as secure—and users have been trained to look for the padlock or the word “Secure” to determine the site’s legitimacy. Yet all that padlock or the word “Secure” means is that communications are encrypted. It doesn’t say the owner has been validated; a site can be encrypted and still be unsafe because the owner has been spoofed by a phisher or other malevolent force.
At the core of our security is database access -- in Workbench this is isolated at a low-level change in our data model. Nothing outside of our data layer/models/business objects are even aware that the stored data is encrypted. Even if data isn't terribly sensitive, we ensure that the loss of records will never be embarrassing to anyone because that data is unusable without the keys to decrypt it.
Read more here about Bluedog's model for end-to-end security of data.