Using encrypted/hashed passwords in ADO Conn string?

[Ovatvvon]

Hi,

Does anyone know if it is possible to supply a hashed password in the ADO connection, instead of the password value itself?

I am using a domain account for the ADO connections, but do not want the password available for anyone to see as it has admin rights. I would like the ADO connection string to contain the hashed value of the password for the connection login, so the account can still do its work, but so anyone looking at the code will not know what the password is.

I thought there might be a way to do it in ASP.NET, but before I try incorporating that, I'd just like to know if anyone knows if this is possible in ASP.



-Ovatvvon :-Q

 

[ermora]

I don't believe there is such a thing.

What you should do, would make your life easier too, is change the SQL configuration from Windows Authentication to SQL & Windows Authentication.

With this change, you can create an account that is restricted to SQL itself, and even then, limited to the types of transactions (edit, delete, select, etc) and object access (tables, views, triggers, etc).

Hope this helps.

 

[Ovatvvon]

Ermora,

Thank you for your input.

Unfortunately, that would not be a wise decision in my specific situation as this will be using the domain account to manage aspects across hundreds of servers throughout our data-centers. If I used a SQL ID, I would have to implement that ID on every one of the [current] 230 servers (note, that number is continually growing), which would be scary enough if it weren't for the fact that passwords must be updated every 90 days according to our security policy, which turns that situation into a nightmare. The Domain account makes it so we only have to manage one account. One of the many things this will do is manage security passwords so our internal clients can manage their own passwords on their SQL accounts, so there is not thousands of people contacting our DBA's every 90 days to change their passwords - they can manage their passwords on their own.

We just need to secure the password for this domain account within the code of the internal website (intranet).

Hope this makes sense.

If anyone else knows of a way, please let me know, otherwise I will resort to using .NET, which will not be bad except for the fact that it will slow me down a bit during the development processes because I am not very familiar with ASP.NET.


-Ovatvvon :-Q

 

[Chopstik]

Couldn't you just use a Universal Data Link (UDL) file and then save it there, then reference that in your ASP file?

------------------------------------------------------------------------------------------------------------------------
"Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing ever happened."
- Winston Churchill

 

[Ovatvvon]

Hello Chopstik,

This will be connecting to SQL Server 2005 servers, and I'm not sure udl works with that. Do you know if it does?

More importantly, as far as I know, don't UDL files store information in clear text? My only concern about the password being in the code is for anyone that has access to the physical machine that will store the webpage code. If they can access the ASP pages, then they would be able to access the UDL file as well, and thus know the password for the domain account.

Please correct me if I am wrong about this.

-Ovatvvon :-Q

 

[ermora]

You might try this then.....

Create a vb project that Encrypts and Decrypts a string. Compile it to a DLL. Reference it in your ASP page and use the functions within the DLL to decrypt or encrypt both the username and password.

	'SQL Connection
	oConn.Provider = "SQLOLEDB.1"  
	oConn.Properties("Data Source").Value = dycrypt("dkshajsks")
	oConn.Properties("Initial Catalog").Value = dycrypt("372j2nshjs")
	oConn.Properties("User ID").Value = dycrypt("37272b2g3")
	oConn.Properties("Password").Value = dycrypt("8382jsjs")
	oConn.Open

I can't think of any other way to *secure* the username and password.

 

[Chopstik]

The UDL file will store the ID and password in clear text, but since it would be stored on the webserver, then only people who have access to the webserver would be suspect (in the case of a problem). But if you're worried about the people who have access to the webserver, then IMO your problem is really the people you're working with and not how to secure the connection string. Unless I'm missing something in your explanation...

Otherwise, I'd recommend ermora's idea about a DLL file. Just bear in mind that doing so will require you to hard-code the ID and password and you may have issues should either of them change in the future (a bigger issue if the system requires constant changes due to security).

------------------------------------------------------------------------------------------------------------------------
"Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing ever happened."
- Winston Churchill

 

[ermora]

You shouldn't have to hard code the username or passsword (or any other property you want to encrypt). Just create a text file something like;

property = (encrypted text value)
property = (....

then within the asp page, you can use FSO (FileSystem Oject) to read that text file, parse it, then pass the content to the decrypter.

Anyhow, just a thought.

 

[ermora]

**forgot probably obvious, but just in case**

if you use the mix DLL + FSO, you could create the text file (which is becomes your connection configuration) and share it amongst all the servers needing it. This way, you only need to change this one (1) text file.

Anyhow, good luck

 

[Tarwn]

Why not use a DSN? Then you only have to worry about people that have admin access AND know their way around the registry well enough to find the password.

Although I must admit something feels a bit wrong that your having to protect a Domain password from other admins...we have a couple accounts like this, but it's only the core SA and Administrator accounts that can't be disabled should someone leave. The rest of us are part of Domain Admins and have Admin rights across the company. Part of the requirements and paperwork for It at our company is to not go snooping into informaiton we shouldn't know about unless it's at the request of the user who owns that information (ie, payroll, executive DFS folders, mail, etc). I guess thats probably the difference between a large company and a medium-sized one though.

-T

 

[Ovatvvon]

Thanks for all your advice everyone!!

Ermora, I am actually using an encrypted password on the development server, so it is not readable to anyone scanning the code, but the problem is that if anyone inserted the function call to the decryptor anywhere else in the code, that can use a response.write to see what the password is, and therefore defeats the purpose of the encryption. That's why I was hoping I could just use the hash value of the password, so the domain controller can just verify that hash against the hash of the password in its files.


Chopstick and Tarwin, I fully agree with you...if we had to worry about our admins having the passwords, there would be serious issues; however, that's not the case of worry here. This is more of a precautionary step to add one more layer of security. For instance, there are hackers that try to get their way into our infrastructure every so often. If by chance one happened to get in, and just happened to get onto this server, in hopes that they do not already have admin rights, I would like to prevent this code from giving those admin rights readily away. Hope this makes sense. (Besides, as far as admins go, there is Way too many people here for me to know who is trustworthy or not. There are more people that have access to these boxes in one way, shape or form, than I even know exist. I'm just one small part.)

Tarwin, the DSN would work for the database on the local server, as that maintains the logs for every change made via the web interface, who did it, and when. The changes to passwords, etc, on remote servers would need a DSN setup on everyone of them if I went that route, which is just too much administration. DSN-Less connection via code seems like the only viable solution to me - unless there is something I'm not remembering or thinking of.

It sounds like I need to just go with the password hash and make a call to a decryptor, or else implement ASP.NET.

Once again, thank you all for your thoughts and advice! I truly appreciate it!!


-Ovatvvon :-Q

 

[tsdragon]

I don't think encrypting the password is going to do you very much good as long as it is still stored in the asp file where the people you don't want to have it can read it. What is to prevent them from simply writing an asp program to do what they want to the database, and passing the same encrypted password you used?

The only thing you're preventing is them using the password directly on the sql server.

Unless you prompt for the id and password, encrypt them to prevent sending them in clear text, decrypt them on the other end, and then send them to the server, you're not going to be able to prevent potential problems.

Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Ovatvvon]

Hello Tracy,

In this particular situation, I see your point if I were to use a one-way hash for the code. They could just reuse the conn string with the hashed password to interact with the sql server remotely.

As I'm doing it right now, the hashed password isn't actually used in the conn string. As it would seem, a hashed password cannot be used in classic ADO, so I have implemented a 2-way hash, where it must be decrypted to be used in the conn string. I'm also currently encoding the header page which contains that conn string, along with the actual connection object, and they just call the object itself (i.e. cnnDB). This way, they don't physically see the password or connection string, and do not know the variable for the connection string.

The only way I can see them defeating this is if they decode the header page so they can read it in plain-text again, which wouldn't be as hard as breaking encryption, but is still a deterant for even the average programmer.

I put the hashed password into a separate ASP file, so that it can be changed every 90 days to meet our security policy requirements, but the encryption key is also encocded in the header page, thus hiding it from the average person.

Granted, if someone was really good (i.e. good enough to hack onto the box) they would likely be able to decode the header page as well, but, if nothing else, it is just one more deterant / blockage slowing them down in that event.

Do you see any problems with my logic here?

-Ovatvvon :-Q

 

[tsdragon]

I don't see any problem with it. The idea of encoding the header page hadn't occurred to me.

Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.