Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.

Stop Storing Unencrypted Passwords!

Doctor Fox

I was called over today by a person doing application support to help troubleshoot a database connectivity issue. This isn't a big deal and something that's a regular job task for a database administrator. But then he did something that totally floored me.

He went into the registry and copied the password (in plain text) and used it to test the database connection. See, the application stores the username and password in the registry and encrypts neither. Yes, this is in the year 2012. What makes things worse is that this is a relatively new version of the software, released in the last couple of years. This software's target audience are enterprise-class organizations. And they've been operating on the Windows OS for years. So all of the standard excuses for why they might make this mistake don't hold in this case.

Look, vendors, if you store the username and password without encryption, whether in a text file or in the registry, then you've given every administrator those credentials and they don't even have to work for it. Based on how you've secured those permissions, the situation might even be worse. In any case, there is no excuse now for doing such things. Encyption algorithms are readily available. Computing power is not significantly impacted if you have to decrypt a single username/password. We've been doing it for years. 

So if you're vendor and you're doing it the wrong way, please, please, PLEASE, put it in your next enhancement build to fix this. It's not hard. It helps out overall security. It brings about non-repudiation. And it's a well-known, well-documented security best practice that should always be followed. PLEASE? Or do we have to start embarrassing you by posting names and software applications on-line like what was done with applications that couldn't play nicely under the UAC? This is beyond ridiculous.

 

Comments

Posted by derek.colley on 27 July 2012

This is not unusual.  One software manufacturer who supplied one of my clients had bastardized the Microsoft Dynamics CRM offering into a custom application, and stored the application login password in plaintext in a key marked 'password' in a new registry hive.

Might as well write it in size 48 Arial and use it as a desktop background, eh?

Posted by barry.parkinson on 30 July 2012

So where should you store the decryption key for the password?

Hard-code it?

Posted by umailedit on 30 July 2012

"Computing power is not significantly impacted if you have to decrypt a single username/password. We've been doing it for years. "

This is totally dumb.  You never 'decrypt' a password. Otherwise anyone with the decryption key can get the password.  It is no better than storing the password in clear text.  What you do is get the password from the user, encrypt it with itself a hundred times and store the hash.  When the user wants to sign in do the same and compare the resulting hash to the stored hash and grant access.

Leave a Comment

Please register or log in to leave a comment.