Are there any security concerns in choosing to hash a user password at the application level in ASP.NET vs at the database level in SQL CLR? I'm seen it done both ways.
My thinking is that in the application level, the password is only sent once from the browser to the webserver. In a database implementation, the password is sent a second time to the database for hashing.
In the latter case, someone running SQL Server Profiler would be able to see the password sent to the procedure or function in plaintext. I'm not too familiar with SQL Server Auditing, but if it had the ability to capture similar information it would pose a risk as well.
You should hash the password in your application, not in you database. This means that:
Browser to application -> password is send in plain text protected by ssl
application to database -> password is allways hashed
Now you have no problem with someone running a profiler, because the passwords are hashed. Besides that if someone can run a profiler, he can probably do much more damage then reading the passwords...
Hash in the application layer using scrypt or bcrypt, don't depend on general purpose hashing algorithms (MD5, SHA1, SHA512, etc) because of these reasons.
Here are .Net implementations for scrypt and bcrypt.
Related
I have an issue when it comes to encrypting user passwords. I have a authorization services with which one can create a user account. Given is an email and a password. As for now I encrypt the user password in the server before persisting it in the database.
However I feel that is somewhat wrong because the password is in plaintext when coming in through a https request. So I actually could log the real passwords of users.
Isn't that a dangerous way to handle user passwords? I think it would be better to encrypt user passwords in the client side code (javascript) before submitting a form (either registration or login). So the password will arrive encrypted already.
Am I right with my concerns?
I encrypt the user password in the server before persisting it in the database.
Please don't. Use slow salted hash if possible (BCrypt, SCrypt, Argon2,..)
If you really cannot use the mentioned functions, than a database native hashing functionality is better than encryption.
https://practice-code.github.io/architecture/how-to-store-passwords-in-a-secure-way/
the password is in plaintext when coming in through a https request
Nope, the https encrypts traffic between the client (browser) and the server.
Yes you can see the password in the browser side before encryption (but the user entered the password, so it looks ok to access its own data) and the server needs to validate the password anyway.
Isn't that a dangerous way to handle user passwords?
Indeed. So maybe it's a good idea to offload the user authentication to already proven services (AWS Cognito, IBM AppID, Azure AD,..) or to social accounts (Google, FB,..)
I think it would be better to encrypt user passwords in the client side code
As already commented, that is not helping at all. Then the encrypted value becomes the password
Nothing is in clear text when using HTTPS, data is encrypted that is the main point of using server certificate !
As an alternative approach usually one stores the password hash in db instead of the password text, so eventually your code uses hash algorithm to generate the password hash and compare it versus one stored in DB, by that even if someone was able to access the database records ,that one is unable to figure out what is the password because all he gets is the hash value
Using Hash in C#
We have a legacy application that is storing the user's passwords down in the database unencrypted. We've had a fair few customers come onboard now which encrypting this password is a big deal to them (fair enough). Currently it's just a Nvarchar(100) field inside an SQL Server database table.
The situation is that we have multiple client applications accessing this database and validating against this password.
Just wanting to get advice on how we can achieve encryption on this field in the database without having to rewrite all the client applications that read off of it? It's not out of the question to change the client applications but we're trying to get away with this with as little fuss as possible.
Any ideas?
Do not do that, store salted, iterated HMACs of the passwords. Use something like Bcrypt, password_hash, PBKDF2 or similar.
If the HMAC is not salted and iterated it is not sufficient. Simply hashing without salting leaves the hashed passwords open to rainbow table attacks.
Convert the existing passwords now.
Is it safe to send a bcrypt encrypted username and password through a http post? I basically just want to set a server up for my friends with a username and password that is encrypted so they can access stuff on my server.
It's just about as dangerous as doing all communication in plaintext without the safety net of SSL/TLS. There's not much benefit.
If you care about security, make sure all usernames and passwords are encrypted over the wire by using a common standard like SSL/TLS. There have been a number of vulnerabilities in this approach lately (e.g. OpenSSL), so it's worth investigating ways to establish secure communication channels. OWASP is a great resource for web application security strategies.
Bcrypt isn't for encrypting communications, but it is a cryptographic hash function that's particularly good for password hashing.
What does the server need to know when deciding whether to accept or reject a login attempt? It has to decide whether the username and password provided by the client are correct. Interestingly, you can do that by storing a derivative of the password that difficult to reverse rather than the password itself. The benefit? If somebody gains access to your password database, your user's passwords should still be secure. That's not to say you should publish your password database, but it's better to engineer everything as though that could happen.
I have a .net application that stores hashed passwords in a sql server database.
The passwords are hashed using a salt that gets stored in the database with the hashed passwords.
As an extra layer of security, I hash the hashed password with another sitewide secret key that is not stored on the database server for security reasons. As the system is load balanced, where should I store the sitewide secret key? Store a copy of it in the config of each of my .net applications (same value on all servers).
Second question is, what is the recommended hashing mechanism for storing passwords?
I tend to use bcrypt storing passwords. The .NET implementation of it is BCrypt.NET as it doesn't come in the .NET framework at this point. You do not want to use a general purpose hash function like MD5. Another common algorithm is PBKDF2, but I have not personally used it in .NET.
I am about to deploy an ASP .NET application (developed with LINQ-to-SQL).
I have taken following precautions:
Database access via user with limited access, however, since application is to access the sensitive data, I can't deprive this limited access user from it
Database server is not exposed to external network - is hiding behind DMZ and all external ports are blocked
I have done thorough security testing of the web-application; SQL Injections, rights management, illegal data access (via post/get data tempering)
Application is operating on SSL
Questions:
1 - I am using ASP .NET authorization API; any recommendation for avoiding session hijacking (in case someone some-how gets to know the session key). Is there are way to change the authentication cookie less prone to threats? Say like, changing it after every request? (I know I am get very conscious about this particular item)
2 - Data in the database is not encrypted. To make things ultra-secure, I am thinking about implementing transparent data encryption. Can someone share his/her experience or a link about implementing data level encryption with SQL Server 2008 along with pros-and-cons?
3 - Recommendation for storing connection string in web.config. Is using integrated security better then using encrypted database connection string?
It's seems to me that it's enough of standard asp.net api for this task. There is a very good article from MS P&P team about securing your forms authentication, it should help you.
I don't have such experience but here is a link with article.
I don't know :(
Also I recommend to check AntiXSS tool, it can show you some potential xss holes. And one last note, never trust to user input.
Integrated security is your strongest option.
I'm not an ASP.Net expert, but in my PHP projects I encrypt the cookie and affinitize it to a specific client IP. This way sessions cannot migrate to a different client. Ultimately, if you want to be absolutely sure, cannot rely on cookies for authentication, but instead use HTTP Digest, since browsers will transparently re-authenticate every request within the realm. Unfortunately this option does not work with the built-in ASP.Net membership providers as the HTTP Digest option they offer is half-brained to say the least (only authenticate against AD).
What specific threat are you trying to mitigate by encrypting data? TDE is designed to mitigate the threat of accidental media loss (ie. someone find an old disk of your with all the data on it, or you loose a laptop with the database on it). This is also the threat mitigate by most other database encryption schemes, like column encryption or file level encryption (bit locker). Other threats, like accidental compromise of access to the database (ie. someone finds a SQL injection vector to your db) cannot be mitigated by TDE, since the database will offer the decrypted data to any authenticated user. To mitigate such threats it means the data is encrypted with keys presented by the user (ie. only the user session can decryt the data becaus eonyl that session know the key password), but that knocks out the 'Transparent' aspect of all these encryption schemes. Having the user encrypt data with it's own key password protects data from other users (other sessions), so it is stronger, but its very difficult to 'get right', and the user is always at risk at locking himself out of its own data by forgetting/loosing the key password.
Use integrated security and store connection string encrypted. Since encrypting the strings in Web.Config is trivial and well supported in ASP deployment and operation, just do it. Encrypting the string protects agains accidental compromise of the IIS/ASP host from a non-admin account. An admin account, or the account under which the ASP runs will always be able to read the encrypted connection string. Since the most likely attack vector will always be ASP compromise (ie. SQL injection and friends) the attacker will most likely be able to read the connection string even when encrypted, so there isn't that much benefit from it, but every little bit counts.