Cache password for SQL Server connection as a hash

问题:

I'm writing a .NET 4.0 application that requires access to a SQL Server (v10.50.1600) database on the intranet. The database does not support integrated security/SSPI logins, only user/password logins. The best I've managed so far is:

SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder()
{
   DataSource = Settings.SQLHostName,
   Encrypt = true,
   TrustServerCertificate = true,
   UserID = Settings.SQLUser,
   Password = "xxx",
   InitialCatalog = "xxx"
};

However, this requires that I store and manipulate a plain-text password locally, something that I want to avoid.

Is there a way to give ADO, LINQ, or the Entity Framework, etc. a password hash instead of a password to connect to a SQL Server?

---

Whereas encrypted storage for connection strings is better than nothing, it eventually needs to be decrypted before use. Since the rationale behind not having a bindable content property on WPF password boxes is apparently that keeping plaintext passwords in memory is a bad idea, any sort of connection string decryption before use sounds ill-advised.

The ideal alternative would be understanding how SQL server stores and transmits its password digests; applying the same digest algorithm locally; and then sending the digest instead of the plaintext password. Unfortunately, it seems that the TDS7 password encoding described in part here:

http://dbaspot.com/ms-sqlserver/210567-tds7-8-login-packets.html

seems to not use any digest algorithm at all. So I'm probably stuck with podiluska's answer below.

回答1:

You can encrypt a connection string in the app.config.

http://msdn.microsoft.com/en-us/library/89211k9b(v=vs.80).aspx

http://msdn.microsoft.com/en-us/library/53tyfkaw(v=vs.100).aspx

However, given this is an intranet application, I would recommend finding out why Integrated Security is not enabled.

回答2:

No there isn't. A password hash is useful when you need to validate an incoming password. It's no use when you need to store a password to authenticate to an external resource.

If your app is running on a secure server (e.g. an ASP.NET app), you could encrypt the database credentials, e.g. using Protected Configuration.

But in a client app, this won't be much help, except to dissuade casual browsers, because if your app can decrypt the configuration file, a determined user will be able to too.