In the previous parts I talked about security of the application and infrastructure layer of database security. This will be the last post in the series and I want to dedicated it to a very important topic that is not a database only issue – passwords.
Links to the previous posts:
Part 1 – general introduction to security
Part 2 – introduction to database security
Part 3 – infrastructure aspect of database security
Part 4 – application aspect of database security
This is generally a very interesting and important issue and there are different views on this. In this part, I’d like to share my views on the topic as well as to introduce some pros and cons for managing passwords.
Power User Passwords
I said that before, power users (sys/system/root) should not be used. Users that need access to production should have their own users to login into the system, and then either have the permissions to do everything under this user (like connect as sysdba), or the permission to switch to the relevant user (like becoming root or oracle at the OS level).
If this is the case, it means that nobody should know the passwords for the power users. The best option in my opinion is simply have a very long and complex password and keep it in a safe for special cases. The best practice also says it should be changed every time it is used.
User Passwords
Once we implement personal users to the OS and database, we need to manage these users’ passwords. There are two main schools here:
- Time-limit passwords – this is the common school today. Organizations force the employees to change their passwords every few months. The idea is that if someone tries to brute force the password, they will not manage to get the password in time before it changes.
- Unlimited time passwords – this school claims that time-limited passwords force people to have simpler passwords, as remembering complex passwords takes time. It also claims that people will write the password somewhere (which is insecure) and when changing the password it will be similar enough to the previous one. So the idea here is to have unlimited lifetime passwords, but they must be very complex and long. There are ways to have a really long but remember-able passwords that are very difficult to brute force. For example, a line from a song that you like with special characters instead of spaces and some rule for upper case (like first letter of the first word, second letter of the second word and so on). Smarter people than me proved mathematically that we can generate VERY strong passwords using these methods.
Application Password
The last topic with passwords is the password of the database user that is used by the application itself. A time limit password is not really practical, but having a very long and complex password is relatively easy.
There is however a different matter here and this is brute force. When someone use brute force to login into the database, they simply try many different passwords. In these cases the database can be configured to lock the user for a certain time (or indefinitely) to block the attack. This is the common configuration and it makes sense, but it also allows a malicious person to perform DOS quite easily. All they need to do is to try several wrong passwords on purpose. This will lock the database user and prevent the application from connecting. Preventing brute force and DOS the application is only one reason to disallow access to the production database directly.
Summary
This post concludes this series about introduction to database security. There is plenty to say and explain, but I think this series has enough information to start understanding this world, hope you enjoyed it.