Salted Hash add vulnerabilities
-
I was going through the process of deciding how to store my passwords in a SQL Server database. I was using the basic hashing approach when I came through the idea of trying with salted hashes. When using normal hashed I didn't need to retrieve the password from the database. What I would do was to use a stored procedure like this. CREATE PROCEDURE [dbo].[proc_authenticate] ( @UserID nvarchar(16), @Password nvarchar(64), @SessionVariable nvarchar(64) ) AS DECLARE @AuthUserId nvarchar (16) SET @AuthUserId = (SELECT UserId FROM Users WHERE (UserID = @UserID AND Password = @Password)) -- IF ABOVE SELECT RETURN ONLY ONE ROW THEN STORE SESSION VARIABLE IN LOCALS TABLE ELSE RETURN IF @AuthUserId = null RETURN UPDATE Locals SET SessionVariable = @SessionVariable, LastLoginDate = GETDATE() WHERE (UserID = @UserID) GO Basically in my application I would ask the user for a username and password. Then I would generate a random session variable. I send everything to the stored procedure on SQL Server. It's the stored procedure that does all the authentication and there is no way to read a password if not by compromising SQL Server and gaining SA privileges. On the other hand the approach with salted hashes is different. 1- Retrieve the stored password and the salt for an user using a stored procedure. 2- Extract salt 3- Calculate salted hash of user provided password 4- Compare stored password with user provided 5- If they are the same call a stored procedure that given UserID writes a ticket in the database. Step one means basically giving away the User table to anybody that can steal our connection string. This in my opinion is a security problem because basically just by cracking the user of our connection string we can retrieve any password from any user. Of course it's hashed and salted and the malicious user has to guess a username but he can use a brute force attack to decode a password. With the previous approach instead to use brute force attack he would have had to call the sored procedure once for every attempt. This would have slowed him down and would leave a trace in our logs of a suspect activity. But since we cannot autheniticate from inside a stored procedure using Salted Hashes we have to retrieve the password. In this case an attacker can perform the brute force attack on his own computer without any delay from accessing our server through the internet and without leavin any trace. Step five is even worst because one can just byp
-
I was going through the process of deciding how to store my passwords in a SQL Server database. I was using the basic hashing approach when I came through the idea of trying with salted hashes. When using normal hashed I didn't need to retrieve the password from the database. What I would do was to use a stored procedure like this. CREATE PROCEDURE [dbo].[proc_authenticate] ( @UserID nvarchar(16), @Password nvarchar(64), @SessionVariable nvarchar(64) ) AS DECLARE @AuthUserId nvarchar (16) SET @AuthUserId = (SELECT UserId FROM Users WHERE (UserID = @UserID AND Password = @Password)) -- IF ABOVE SELECT RETURN ONLY ONE ROW THEN STORE SESSION VARIABLE IN LOCALS TABLE ELSE RETURN IF @AuthUserId = null RETURN UPDATE Locals SET SessionVariable = @SessionVariable, LastLoginDate = GETDATE() WHERE (UserID = @UserID) GO Basically in my application I would ask the user for a username and password. Then I would generate a random session variable. I send everything to the stored procedure on SQL Server. It's the stored procedure that does all the authentication and there is no way to read a password if not by compromising SQL Server and gaining SA privileges. On the other hand the approach with salted hashes is different. 1- Retrieve the stored password and the salt for an user using a stored procedure. 2- Extract salt 3- Calculate salted hash of user provided password 4- Compare stored password with user provided 5- If they are the same call a stored procedure that given UserID writes a ticket in the database. Step one means basically giving away the User table to anybody that can steal our connection string. This in my opinion is a security problem because basically just by cracking the user of our connection string we can retrieve any password from any user. Of course it's hashed and salted and the malicious user has to guess a username but he can use a brute force attack to decode a password. With the previous approach instead to use brute force attack he would have had to call the sored procedure once for every attempt. This would have slowed him down and would leave a trace in our logs of a suspect activity. But since we cannot autheniticate from inside a stored procedure using Salted Hashes we have to retrieve the password. In this case an attacker can perform the brute force attack on his own computer without any delay from accessing our server through the internet and without leavin any trace. Step five is even worst because one can just byp
Even comprimising your SQL Server system would not yield the password if using a digest algorithm like MD5 or SHA1 without using a brute force attack. You make a good point about avoid such an attack, though. Encrypting the ticket is definitely a good idea. Take a look at my article Role-based Security with Forms Authentication[^] for a brief mention of using
FormsAuthentication.Encryptto encrypt a forms authentication-based ticket. Doing this manually would work as well, but I thought I'd just mention it. As far as using a salted hash, storing the salt makes your system little more secure than the first method of using an unsalted hash. If a cracker comprimised your system, nothing is stopping them from discovering the hash. The MD5-digest authentication mechanisms that many HTTP daemons support - as well as many browsers - actually generate a salt of sorts that it communicates with the browser (handshaking) and they use that to digest the credentials. Unfortunately, you can't do that because you need your salt to be persistent. So, instead of storing the salt in the SQL Server, what about storing it in a different medium? You could, for example, keep an XML document (or even a simple text file) up-to-date with users and salts and read that into memory (use ASP.NET'sCache- if applicable - for some good event-based page validation). If a user comprimised the SQL Server, that cracker would have to comprise the entire system as well so that they could - most likely - gain debugging rights in order to insert their code into the ASP.NET worker process space and read the memory directly. This is just an example off the top of my head, but conceptually something you might want to consider.-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----