So, your app is secure because you encrypt passwords?

I continue to be amazed by the haphazard approach many IT product vendors take to security. For work purposes I was recently asked to evaluate an HR package of a vendor which has been around for a fair few years and you would really expect to be big enough to put some attention to detail in the area of security. Although I would love to name and shame them, I had to sign an NDA before they would allow the evaluation and therefore cannot reveal their name here.

When receiving the package and a few hefty manuals, I could spot the problem a mile away. The usernames and passwords for all users were contained inside the SQL database (which raised the thorny issue of why it didn’t integrate with our AD to begin with) and then the program used a fixed username and password with Database Authentication to the SQL Server to query it for the username and password that existed in the user table.

Architecturally this solution is awful. In order to connect to a table which contains encrypted data, the program has to make a database connection with an unencrypted username and password. Hardly secure is it? Also, although it was possible to change the default username and password, the tool to do this with was undocumented, which means hardly anybody will bother.
A quick test with Cain and Abel confirmed my suspicions. After configuring the ARP cache poisoning feature in Cain it was possible to capture this database password from a third machine in around 20 seconds. Of course I could still not connect with the client (as this used credentials contains in encrypted form inside the database), but I now had direct access to the database and could look at the raw data which included salary details, medical history, disciplinary records etc. Good thing this was a test environment with a demo database!

I did of course raise my concerns with the vendor, but they did not appear very concerned at my quite detailed description of the problem. Either they do not care they have hundreds of insure installs around the world, or they are well and truly aware of the problem and are choosing to ignore it and hope to improve the architecture in future releases of the product.

It is not only smaller vendors that ignore this problem. One well known industry name allows you to store their configuration details in a database so your entire farm of servers can access the same info. Again, the documentation only talks about using Database Authentication, but at least does give a warning that this is not suitable for high security environments. Why not include another two pages to explain to users how to switch it to Windows Authentication or maybe a whole chapter on how to make it completely secure?

If you really have to live with database authentication, it is possible to make it secure. IPSec under Windows is relatively straightforward to enable, and you can disallow connections from any client that is not capable of communicating securely. Microsoft do a nice little KB article that describes this process in detail. Once we put this in place, Cain was rendered ineffective and our data was once again secure.

Essential lesson? Don't assume commercial software vendors value your security as much as you do and do your own research!