What''s the best practice for application passwords?

Question

What''s the best practice for application passwords?

SRuecker

SSC Enthusiast

Points: 170
More actions
November 10, 2005 at 10:10 am

#90807

Hi all -
Our current practice with application profiles is to embed the profile/password in compiled application code. The advantage to this is no one can see the application profiles or passwords. The disadvantage is that a password change necessitates re-compiling and deploying applications. I've worked at other companies that stored profiles and passwords in a SQL table; in practice, this gave too many support people visibility to sensitive information.
What's the best practice for dealing with sensitive application profiles and passwords ?
Thanks in advance,
susan

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply

Roberto Rivera-152314 SSC Rookie Points: 27 More actions · Answer 1

Well, this is my first post. So hello!

Anyway, dont take my answer as correct since I'm in no way a SQL administration expert. But I would approach the problem by encrypting data on the server with, perhaps, AES. Use a master key that only the application would know. Granted, the application could be cracked and the master key obtained, yadda yadda yadda. But usually the average user in an office wont even know that's possible. Even better, they may not even know you are actually using any kind of encryption.

This is how we are approaching it in a small investigation I'm working on at college.

Regards

Norene Malaney SSCommitted Points: 1896 More actions · Answer 2

Here's an idea:

Store the login/password in encrypted form (for more security, use 1 encryption key for the login info; 1 encryption key for the password) in a secure file on the network.

Create an ini file that stores the location (also in encrypted form) of "the login/password file".

Have the application (1) Read the ini and decrypt the location of the "login/password file". (2) Open the "login/password" file and decrypt the data in this file to gain access to the server. Thus, the application only needs to know the encryption keys used to encrypt the data in these 2 files (ini file and login/password file). You will have to re-compile the application when you want to change encryption keys (but not to change password/login information).

Have a good day,

Norene Malaney

SRuecker SSC Enthusiast Points: 170 More actions · Answer 3

These are both great suggestions. I'm wondering whether there's anything built-in in SQL Server that I could use, instead of a 3rd party encryption system.

Maybe instead of asking about 'best practices', I should have asked how others are handling this. I'd like to improve on what we're doing... and there may be considerable room for improvement before reaching the 'best practice'. i.e. its not a 'best practice', but its working quite well for us.

Any more suggestions?

Thanks!

susan

Roberto Rivera-152324 Grasshopper Points: 23 More actions · Answer 4

I know MySQL server has md5 encryption builtin.. but I tried finding it on SQL Server and wasn't successful (I'm not much of an expert, anyway).

If you want to use AES. Take a look here: http://msdn.microsoft.com/msdnmag/issues/03/11/AES/ it's a ready-to-go implementation.

My other suggestion would be integrating extended stored procedures in your Database. That way, it would have a built-in feel. http://www.sqlservercentral.com/columnists/mcoles/freeencryption.asp

Good luck,

Roberto Rivera

SRuecker SSC Enthusiast Points: 170 More actions · Answer 5

Hi Roberto,

Thanks a lot for the advice and the links.

Keep well,

susan

david russell-253790 SSCarpal Tunnel Points: 4042 More actions · Answer 6

Use Windows Authentication.This way there is no password passed over the network as the user's authenticated token is used. Until SS 2005 Windows Authentication was stronger than SQL Server's. With 2005 on Server 2003 (ONLY) a DBA has all of the same capabilities for setting/controlling passwords as a system administrator. This is done through an API to the OS - and it is basically the same capabilities that Active Directory already implements. In my eyes this is making work for a DBA and there are better things to spend time doing. Your hosts will have to be part of the domain (or a trusted domain) in order for this to work. That is not a bad thing in itself, especially if you have a department already in place for securing the domain, testing patches and distributing (SUS), and updating anti-virus protection, etc.

Cheers,

david russell

Clive Strong SSChampion Points: 11222 More actions · Answer 7

I would never hard code a password in a compiled app! As you say, a password name change would require a recompilation.

You have two options really. If you must use SQL authentication, then I'd employ encryption for the passwords and if you wanted to store profile information within a table, then again, encryption would be the way to go.

The other option would be to run with NT authentication.

A bit off track, but if you're embedding login information within the binaries, are you also emedding SQL code within the binaries? I know this is a bit off track, but it's just a red flag with any kind of SQL embedding to me.

adam spencer Hall of Fame Points: 3926 More actions · Answer 8

Yes, It is not a good idea to ever hard code the login/password becuase it limits the ability for it to be changed on the server (since the front end app would have to be re-hardcoded and compiled). If you have to use standard/sql authentication use ssl to protected the password being deciphered over the network. Best way is to use windows auth since no password needs to be sent.

hope this helps