June 18, 2014 at 4:40 pm
This is to follow up this thread on writing a user authentication script for a client application. I thought to put under a different topic because the i think the users replied to it kind of misunderstood whats i was on about.
I was told that the authentication is a process that concerns about security. So the authentication process should be hidden from the client as possible and the client should receive a flag value (1= password is correct and authenticated, -1= incorrect password) and/or user name of the authenticated user. So it should be a SQL operation that should occur in the back end. So the process in detail should be, client form sends user name and hashed /encrypted password to SQL, SQL authenticates and it sends 1/-1 with the user name to the client as the return value and the output.
But when i do research that was not the case, all the threads i have seen on web, either the app is windows or web, developers do two operations:
1. the salt value of the user is searched by user name then return the salt value along with the PasswordHash to the client form / or to the business layer
2. Then use the entered password and the returned salt value to generate a PasswordHash and then compare this passwordHash with the returned passwordHash. if match password is correct if not password is incorrect.
Is this actually how developers write code to authenticate a user in a login event? If so basically the password comparison happens at the client side(either in the form or in the business layer) then wouldn't this be huge security risk by exposing the actual salt and passwordHash to the client?
thanks
June 27, 2014 at 12:23 pm
My read of the situation:
If the client is 100 percent under the control of the user then yes, its a security problem, but not because of the hash and salt being calculated in the client, its more that we would be trusting the client to itself determine whether it has access to the database or not, and in that case, the hash and salt is a moot point, the end user can simply and alternatively access the database directly.
If the client is NOT under the control of the user, then this can work, because this situation is used typically by client software that the end user does NOT have access to, such as a web app (yes, this means you cannot allow full access to the application code running in the web server to the connecting client and thankfully thats how we typically want web apps to work).
The only other situation that hashes and salts work is when your client software is a presentation layer and the authentication is happening in an application server that the client software is prevented from manipulating. Otherwise you are correct, the hash comparison should happen in the database, and all access should go through some sort of T-SQL that allows or prevents access to the actual data depending on the results of the hash and comparison (authentication results), or else use regular active directory or sql based security and permissions.
In the second paragraph above, the web app performs as the "application server" as mentioned in the third paragraph, and the client is actually a web browser.
editted for clarity.
June 27, 2014 at 12:34 pm
No the actual values are not sent to the client. The client passes UserName and password to the server. In a webapp this is all done on the webserver well away from anything the client can access. The server then calculates the hash value based on whatever logic you have (including salt). Then you compare that result to the store value in sql. If they are the same, authentication is valid. In a windows application this is performed inside the compiled code and the result is compared to sql.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
June 27, 2014 at 2:18 pm
Sean Lange (6/27/2014)
In a windows application this is performed inside the compiled code and the result is compared to sql.
This is actually the insecure part I was talking about. In this case you're trusting that the windows application code won't be replaced with a version that simply connects to the database and ignores the hash match.
June 27, 2014 at 2:52 pm
patrickmcginnis59 10839 (6/27/2014)
Sean Lange (6/27/2014)
In a windows application this is performed inside the compiled code and the result is compared to sql.This is actually the insecure part I was talking about. In this case you're trusting that the windows application code won't be replaced with a version that simply connects to the database and ignores the hash match.
Who is writing the code? Are you saying you are worried that somebody might write a rogue app and write their own authentication code? The typical thing for this is write an authentication service so the code is not on the desktop.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
June 30, 2014 at 6:29 am
Sean Lange (6/27/2014)
patrickmcginnis59 10839 (6/27/2014)
Sean Lange (6/27/2014)
In a windows application this is performed inside the compiled code and the result is compared to sql.This is actually the insecure part I was talking about. In this case you're trusting that the windows application code won't be replaced with a version that simply connects to the database and ignores the hash match.
Who is writing the code? Are you saying you are worried that somebody might write a rogue app and write their own authentication code?
Yes you got it! The original poster actually posted as such in the original post:
Is this actually how developers write code to authenticate a user in a login event? If so basically the password comparison happens at the client side(either in the form or in the business layer) then wouldn't this be huge security risk by exposing the actual salt and passwordHash to the client?
Even more so, if the only authentication going on is a client side hash, the client can simply skip that mess and connect directly. Even more damaging, the client can, if permissions allow, dump the servers hashes for everybody, since to perform authentication we know the client can read the table containing the hashes.
The typical thing for this is write an authentication service so the code is not on the desktop.
Yep!
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply