SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Algorithm Secrecy is not Security

By Steve Jones,

I find the field of cryptography and encryption to be fascinating. I present a talk on encryption and  constantly find people that don't realize the security of an encryption algorithm doesn't depend on what the algorithm is or knowing how it works. I can tell you that I'm using an AES or RSA algorithm and that doesn't make it any easier to decipher the plaintext.

This week Troy Hunt wrote a piece where he called for disclosure by websites (and really all applications) of the password storage mechanism. The badge above is an example of what he'd like to see posted on all websites. His explanation of what this might change in terms of Internet security is great, and while this might not actually make applications more secure, I'm not sure that many companies would want to be forced to disclose they are storing passwords in plain text. Consumers are becoming more savvy and realize this is a poor way of managing systems. I suspect that people will quickly learn what are strong and no-so-strong algorithms.

Real security still requires developers to not only implement strong algorithms in their applications but also make these algorithms upgradeable. We used to use MD5 everywhere (now a bad idea), and in SQL Server 2008 R2, we are limited to SHA1. This algorithm is known to have problems and SHA2 is recommended. Unfortunately you would have to upgrade to SQL Server 2012 in order to use this algorithm. You can write your own implementation, and if you have high security requirements, I'd encourage you to do so.

Key security is important, and this is to systems what password security is to individuals. Protecting your keys (and passwords) is ultimately the way in which we can dramatically increase the level of security in applications. This is the hardest part of managing encryption in your application, and I'd encourage you to seek out someone with experience to help you understand how to best handle  this.

Ultimately a lot of security depends on layers, with some secrecy in place, but the secrets you keep should be the exact design and implementation of your entire infrastructure, not the algorithms used. If you build encryption into your systems, please do not design your own algorithm. On a regular basis the vendors and developers who think they've implemented strong encryption by hiding the details of their algorithm are usually unaware of how flawed this approach is. Please use well known, public algorithms for encryption, which have been tested and probed by mathematicians in a public forum.

Total article views: 149 | Views in the last 30 days: 1
Related Articles

Implementing Encrypting File System (EFS) with SQL Server

EFS provides a mechanism for encrypting files completely transparent to higher level applications su...


Free Encryption

Free SQL Server 2000 Encryption for your data!!! Author Michael Coles has put together a tolljit and...


What Encryption Algorithms Are You Using?

Security is an important consideration when designing a database application. Who can get access to ...


SQL Server Encryption

Implementing encrypted database columns


The Dangers of Algorithms

How we implement algorithms can change the way the world works with our software. Steve Jones wonder...