In a perfect world this should be done at all layers of your application, both at the front end and at the back end.  At the front end, this is usually easy, as you control the application, and the code that goes into it.  Adding a module like this is pretty easy.  On the back end you’ve got less options available to you.  You are pretty much at the mercy of your database vendor on this one.

However the database vendors have heard our requests for more security in the platforms and they have begun to respond.  As an example Microsoft SQL Server has since the release of SQL Server 2005 included the ability to have the SQL Logons follow the same security requirements as Windows Logons on the Windows Active Directory domain.  (Other database vendors may offer similar features, but as I mostly use Microsoft SQL Server I’m not aware of them.  If you are please feel free to comment below.)

Now with this comes some risk.  Because if you were to enable these settings and someone did try to break into the database server using this account, the account would lock out.  This is both good and bad.  Its good because they aren’t able to continue the attack, however its also bad because your business application isn’t able to log into the database either.

Open source apps such as WordPress are starting to get these features added into them.  There’s a plugin for WordPress called “Login LockDown” which allows the WordPress admin site to lock it self down if the same person gets the password wrong more than n number of times.  The options are totally configurable by the blog owner, so you can set your settings as high or as low as you want.

So, what’s the point of all this you ask?  It’s pretty simple, and it is easier when you look at the math.  Assume you wanted to attack a system which takes 1/10th of a second to check a password.  Using the characters on the standard keyboard (letters, numbers, symbols) you’ve got ~94 characters to work with.  Assuming an 4 character password of say “test” there are 78074896 character combination to try.  Assuming you try all the combination (just to make sure you get the correct password) it will take about 90 days to test all the options.  Now if every 5 failed attempts we lock the account for one hour that test times goes from 90 days to 3012 years (if I’m done my math correctly).

The next question then becomes, why would anyone take 90 days to break my password.  The answer is that they wouldn’t.  They would use more than one machine to reduce that 90 days down to a more manageable number.  If using 10 computers and you break with workload up evenly across the 10 computers that 90 days, is now 9 days.  20 computers will get it done in 4.5 days.  50 computers will get it done in 1.8 days.  All of a sudden by simply throwing a few computers at the problem the password gets broken very quickly.  Now longer passwords will make this take longer, but if you have a system which people really want to break into they could get access to one of the large botnets and have 100,000 computers work on breaking into your site.  Even with a very strong password, it wouldn’t take all that long to brute force your way into your passwords.

The only sure fire way to stop someone from brute forcing there way into your accounts is to lock those accounts after the password has been tried incorrectly several times.  Don’t make the limits to low that your customers can get into there own services, but don’t make them so loose that people can break into those services.

Denny

Your database holds all of your data.  If someone was to great into your database server they would have access to view, and possibly delete all your data forcing you to restore your data from your backup.  In a perfect world there would be no database servers directly accessible from the Internet.  There is pretty much no reason for database servers to be directly accessible from the Internet.

If your servers are CoLo’d then setup a VPN between your office and the CoLo, or VPN directly into the CoLo.  There are some hosting providers which prefer to setup the servers on public IPs, however most of them will if requested use private IPs and configure a Site to Site VPN connection for you.

Pretty much the only times that a database needs to be on the Internet would be if you are replicating data between servers as this will typically require that at least one of the servers be on the public Internet.  SQL Service Broker can need to be on the public Internet as well.  However in both of these cases, you don’t need to give the server a public IP.  You can give the server a private IP, and NAT the server from the Internet to the private IP.  However make sure that only the correct port or ports are open through the firewall.

In Oracle this should be done by setting up a new listener.  In SQL Server this is done by setting up a new endpoint either for general connection, or in the case of Service Broker an Endpoint is used to connect to, which listens on a seperate TCP port.  When setting up these listeners or endpoints make sure that only the accounts which need to have access to them have access.  This way the minimal attack surface is avaialble from the Internet.  In addition you will want to setup your firewall or router ACLs to allow only the required public IP addresses to have access to the listener or endpoint.

With your database being publicly available attack scripts could attack for it, or people could manually try and break in.  With SQL Server running in mixed mode, and with Oracle there are accounts which can be brute forced which have well known usernames such as system and sa.  When SQL Server is running in Windows only mode breaking in is harder, but not impossible.

Denny