Lets say that you have a list of passwords and usernames stored in a db generated from your web/intranet app. If your like me, you only want the best in security for your users. So you go shopping for encryption technology.
In this example, I will demonstrate the use of Rijndael (AES) form of encryption to securely store sensitive data such as usernames and passwords.
AES or Advanced Encryption Standard uses 128-256 bit keys to encrypt and decrypt data into plain text. Other forms of encryption technologies such as hashing algorithms do not offer this feature of being symmetric. With hashing it is said to be "one-way" encryption. When the hash is computed, it is stored and compared to another hash when needed.
AES offers a added salt value to the data as an additional layer of security. Salt value places random bits to the initialization vector making it more secure than if you opted out of having one.
Using a tough salt value composed of random alphanumeric characters is the way to go. This further fortifies the data from breaches that might occur in any typical situation.
However, this can be taken one step further. If you'll recall my scenario, we had a db comprised of sensitive information that the user wants protected. In a typical system, the db probably has this data contained in a table i.e. called 'tbl_users'.
- Alter the tables definition: username and password columns to a binary type of column that varies in length for the reason being that AES returns binary data.
- Create a supplemental table for lookups. This table is going to be used for random number that you are going to generate and encrypt with your initial salt value.
- Data columns found here: a foriegn key to the ID of the 'tbl_user' and a random number encrypted with your salt.
- Create procedure 1 that will formulate a random number for you and insert it into the 'tbl_lookup' table.
- Next, Create function that will decrypt the value from the 'tbl_lookup' table and return the value in plain text.
- With the random number returned by the function, you can swiftly take the value and add that to you initial salt value, should equate our new salt in the body of a new procedure.
- Once that is acquired, you can insert user sensitive data enciphered with the new salt. Securely inserting them into the 'tbl_user' table.
- Create another procedure to undo the process; successfully deciphering the data.
Note: On a larger scale, there might be a performance issue with using this approach, but when you're taking security that's always a trade off. Use a bench marking tool and do an assessment to find out if this is the right approach for particular case.