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.
Related
I hear about all these websites getting hacked with sql injections and stuff. What's preventing them from encrypting the hashes with a 32 character string? If I were a hacker and I managed to get the database and I came across encrypted hashes I would not be able to do anything with the database as I do not know the encryption algorithm and the key.
As long as the key being stored securly everyones account would be safe.
Your idea of encrypting the hashes will indeed improve the security of the users password, but you should understand what exactly you are solving with this measure and what not.
First and most important, encryption on passwords is usually frowned upon, because it is a weak protection. If an attacker has the key, he can instantly discover all passwords. So the encryption does not relieve you from properly hash passwords with a slow algorithm like BCrypt, SCrypt, PBKDF2 or Argon2.
But your question was about encrypting the hashes. There is a case where even properly hashed and salted passwords can be recovered easily. If the user has choosen a very weak password, a dictionary attack will reveal them very fast anyway. If the hashes are encrypted though, the attacker needs the key, before he can start with the dictionary. This leads us to the following situation:
Encrypting the hashes will protect weak passwords, as long as the key stays secret. This is always the case when the attacker has no privileges on the server, examples are SQL-injection, disregarded servers, backups, ... I tried to describe this at the end of my tutorial about safely storing passwords.
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.
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'm wondering how to encrypt my password column in SQL Server 2008. I've read this article, but I still have no idea how... is there an easier to understand tutorial? Thanks!
The usual practice is to store a hash of the password. Like:
HASHBYTES('SHA1', convert(varbinary(32), #password))
With a hash, you can verify if the password matches, but you don't know the password itself. So even if a hacker gains complete access to your database, he still does not know the passwords.
There are many tutorials on the web.
You should instead consider storing hashes of passwords instead of using encryption. In case you are unaware of the differences, a hash (also called a one way hash) takes an input and produces gobbledygook (called a hash) such that for the same input the same gobbledygook is produced. Authentication works by hashing what the user entered on the client and comparing it to the gobbledygook in the db. If they match, the passwords are the same. Without getting into specifics, hashes can never be reverted back to plain text which is their protection. Encryption however involves creating a cypher such that if you have the decryption key you can revert the cypher back to plain text.
If you are using SQL Server and ASP.NET, you should look into Forms Authentication with the SqlMembershipProvider.
Explained: Forms Authentication in ASP.NET 2.0
SqlMembershipProvider Class
An Overview of Forms Authentication
Microsoft have made this super-easy with the snappily named
FormsAuthentication.HashPasswordForStoringInConfigFile.
http://www.adventuresindevelopment.com/2009/05/23/a-simple-way-to-hash-passwords-in-aspnet/
I need to view users password history in an ASP.net application.
Is there any way to achieve it?
You have to maintain that as an encrypted string in your backend. Meaning in the database or some file system (not recommended).
It depends.
In fact, storing plain passwords is the worst approach in terms of security.
Administrator must not have access to plain passwords, this the reason of most of applications prompts you to create a new one, because passwords are hashed and hashing prevents from reverting to plain text.
If you need to track passwords, you'll need to write a custom membership provider tracking them.
There is nothing built into .Net that will provide this information. You would have to write your own solution to create an audit trail of passwords but this would involve storing passwords in a visible format. Remember the massive caveat about plain passwords though!
So long as you're only doing this for old passwords i.e. storing them AFTER the user has set a new password it should be ok.