0

We would like to implement the feature of remembering user's passwords in our application similar to how Microsoft SQL Server login credentials are stored. enter image description here

(nothing to do with SQL server connection)

We researched and found some information on this.

However, it is not clear how the process/flow of encryption/decryption takes place, i.e, how the process of securely saving and matching of password takes place during validation process.Some of the websites also mention that the SQL login passwords can be cracked.

As per this document from Microsoft, Windows DPAPI is also being used in the form of Service Master Key (SMK) to secure data stored in database, but the actual SQL credentials validation flow is not mentioned. (We found this question as well which mentions DPAPI.)

So is there any method where we can store user's application passwords similar to SQLServer's methodology or any other secure method to ensure they are not cracked or decrypted? We have also read that DPAPI-encrypted passwords can be cracked.

EDIT 11/05/2022: Added screenshot of SQL Server login page, and made minor edits to content.

IT researcher
  • 3,274
  • 17
  • 79
  • 143
  • Encryption is reversible. You don't encrypt things with hashing algorithms, which is why hashes can't be decrypted. i.e.: Hashing and encrypting are two completely different things and are not interchangeable. – AlwaysLearning May 10 '22 at 13:12
  • Why is SQL Server at all relevant here? Storing credentials securely can be done in many ways, but whether or not you do it the same way as SQL Server should be of no relevance, since you have no choice as to the mechanism of how those credentials are passed (this always starts with a plaintext that is then encrypted by the driver on the client end). This is true even if you should happen to want to use those credentials for logging in to SQL Server; where possible, you should try to use integrated authentication so no passwords have to be supplied in the first place. – Jeroen Mostert May 10 '22 at 13:12
  • Note that the link you supplied discusses cracking credentials stored in SQL Server that are used to access external resources, which is completely different from the credentials used by users to log into SQL Server -- those are not stored (encrypted or otherwise) but only hashed. (Per that link, what's discussed there also requires admin privileges, basically making it not very interesting -- securing things from admins is fundamentally impossible, since in the extreme case they have the opportunity to patch the engine binary to directly disclose the plaintext, if all else fails.) – Jeroen Mostert May 10 '22 at 13:23
  • @JeroenMostert So it does indicate that if Windows administrator privileges are gained, then SQL Server credentials (as per the link) can be gained, and there is no way for Windows to check the request has come from which application ? " since you have no choice as to the mechanism of how those credentials are passed " -- we are looking for the exact SQL credentials validation flow that takes place when a user logs in to SQL using the stored password using 'remember password' feature. – IT researcher May 11 '22 at 05:18
  • The client-side Management Studio features have essentially nothing to do with SQL Server itself. SSMS stores the credentials encrypted (likely through DPAPI, yes) and then decrypts them and passes them when the connection needs to be made. There are probably articles out there that document how SSMS stores credentials, though there's no need to reverse engineer that unless you somehow need to extract credentials that were forgotten from the SSMS storage. And yes, as always, if someone has admin rights they can always subvert anything, even if per-user encryption makes this harder. – Jeroen Mostert May 11 '22 at 07:19
  • Note that SSMS is just a front-end for accessing SQL Server, it just happens to be supplied by MS itself and the most popular one. There are other choices for DB front-ends that will have their own way of storing credentials. SQL Server is not a party in this until a connection is made and the credentials are passed (which it then validates against the hash stored server-side). – Jeroen Mostert May 11 '22 at 07:21
  • Note that the literal answer to your question ("is there any method where we can store user's application passwords similar to SQLServer's methodology or any other secure method to ensure they are not cracked or decrypted") is a solid "no". It *must* be possible to decrypt the credential, because otherwise it couldn't be passed to SQL Server. If you don't want to store credentials, don't use SQL Server authentication but Windows authentication. – Jeroen Mostert May 11 '22 at 10:00
  • @JeroenMostert Thank you for your responses. We are researching but not able to find the exact methodology used by SQL server , other than the information that DPAPI is being used to validate the credentials. Our requirement is not to reverse engineer, but to implement the same for our application so that user's stored passwords are secured. – IT researcher May 11 '22 at 10:03
  • 1
    Then simply use DPAPI (`ProtectedData.Protect` with `DataProtectionScope.User` and `optionalEntropy` set to a fixed array you embed in your application), store the result in a file or the registry, and be done with it. Responsibility for the security of DPAPI-protected data can be delegated to the OS. Protecting against admins isn't possible: yes, they can extract DPAPI-encrypted secrets, but then they can also simply install a keylogger and get the user's passwords that way, or snoop your application's memory directly for the decrypted data. You're better off securing the machine itself. – Jeroen Mostert May 11 '22 at 10:39
  • If client machines can't be trusted not to have malware or untrustworthy admins, another option is to set up a jump server that users RDP to for this specific purpose, that is entirely controlled and managed by you, and store credentials only there. This also gives you an opportunity for securing database servers by limiting what machines can connect to them in the first place. – Jeroen Mostert May 11 '22 at 10:42

0 Answers0