Are clear-text passwords better and more secure than passwords encrypted using ciphers like AES, 3DES or other 2-way encryption technologies? I started thinking more about this after Dmitri Maximovich and I discussed Matt Luce’s implementation of SecureDriverManagerDataSource as a replacement of Spring’s implementation of javax.sql.Datasource (DriverManagerDataSource). Matt’s implementation overrides the getPassword() and getConnectionFromDriverManager() methods and adds support for encrypting database passwords.
Dmitri asks the questions if there is any value to encrypt password with reversible algorithm and keep the key easily available. Can’t someone just grab the key and decrypt the information you are encrypting? While I agree with Dmitri in principle, I still think encrypting the password is better than storing it in the clear. I think the principle of ‘Defense-in-depth’, suggests that multiple layers of security are better than a single protection mechanism. To me, encrypting password using AES for example, makes it a little harder for someone to derive the original password. First they would need to get the key and then pass the key and encrypted string into an AES decrypter to get the original password, assuming the person knew the algorithm used to encrypt the password. Now I know it is really easy to figure what algorithm was used to encrypt text as most of the algorithms have a certain tell-tale signs like M as the first character or = as the last, etc. So in my scenario, the hacker must determine the encryption algorithm, locate and retrieve the key and then decrypt the password. It’s all still doable but I’ve put up more barriers that simply providing the password in the clear. Is it foolproof? By no means but I still assert that it’s better than having the password in the clear.
Another point Dmitri makes is that calling the class anything Securexx will provide users with a false sense of security. I completely agree with that and JavaDoc and usage notes of any class that provides 2-way encryption should make that clear. Dmitri also suggests the use of the Java keystore as a place to hold the encryption key instead of just keeping it in the same property file. A great idea as you would need the keystore password to get to the encryption key out of the store. This idea adds a slight wrinkle as your process must now account for any VM upgrades and make sure that the new keystore has your encryption key. Still a great idea!
To me, 2-way or reversible encryption is the process of obscuring information to make it unreadable without special knowledge. If you need to get to the original text password or any item you are trying to encrypt, you need to know how to get back to the original string. In most cases, you will also need to automate that task programmatically and so technically anyone can decompile your class and figure out how to derive the original text. The word security people use to describe a situation like this is ‘mitigating controls’ and how many controls or barriers do you have to prevent people from getting to this information. It does give people a false sense of security as it is possible for anyone to decrypt your information. By using a 2-way encryption process, you are making someone do a little work to get to the information you’ve encrypted.
I’m curious to see what people think about this. Please drop me an email or comment if you have any thoughts on this. If you’ve implemented something similar to protect passwords, drop me a comment and tell me about it.
AES, Rijndael, 2-way encryption, Spring