Table of Contents for Part 3: Database & Summary
- RULE: Encrypt or hash password when stored in database
- RULE: Filter and Sanitize Visitor Inputs Before Using in Database Query
- RULE: Log and stop Brute-Force Attacks
- Closing Comments
RULE: Encrypt or hash password when stored in database
It’s very important to obfuscate passwords in the database. Should a vulnerability exist in your code, or a hacker gains access to the server hosting your database, it’ll make it far more difficult for a hacker to take control of their account and/or to use the credentials on other websites. Some people actually use the same username and password across many websites!
Should I chose encryption or hashing of the password? If passwords are encrypted in the database and both source code with decryption key and database are compromised, the hacker would have access to the decryption key from the source code and a list of username and encrypted passwords to decrypt. This is a real threat! The best way to avert such a threat is to hash passwords instead. Hashing is a one-way “lite encryption”, when used with a salt, is a highly effective way in storing passwords in a database.
A quick note, using software such as Zend Guard can reduce the risk of encryption keys being accessible to hackers when they gain access to the source code.
RULE: Filter and Sanitize Visitor Inputs Before Using in Database Query
SQL injection attacks are when a hacker creates a specially crafted input which inadvertantly gains them access to systems or data that they would not normally have access to. To mitigate this risk, visitor inputs must always be filtered and sanitised before being injected into SQL statements. Using PHP’s built-in filter_var(), mysql_real_escape_string() and/or Zend_DB_Select will reduce the risk of SQL injection attacks.
RULE: Log and stop Brute-Force Attacks
A brute-force attack is when a hacker continually attempts to log themselves into your system using a very long list of randomly generated usernames and passwords, until one gains them entry.
To mitigate this risk, it’s important to identify such attacks and to lock them down immediately. Remember, where and how you decide to log these events is important too because this could be an attempted DDOS attack where the main aim is to fill up the log files and bring the web server to a grounding halt.
Storing sensitive data and passing it between client and server must be done consciously and carefully. When building any application that needs to store sensitive data, there should always be a layered approach to security – if one layer is breached, there’s further layers of protection. Simply relying on HTTPS and not taking into account any of the other factors I’ve mentioned in this blog will not protect your visitors. You cannot relying solely on HTTPS to provide all security out-of-the-box because it will not protect your visitors against XSS attacks, sharing the same cookies over HTTP and the safety of passwords in cookies and the database.
About the Author
Brett is the Lead Web Developer at BBC.com working on a number of products, such as the BBC International Homepage, News, Sport, Travel and the back-end work on the iPhone and iPad applications.