Given a site that uses the default ASP.NET Membership Provider and the membership password format is configured to use hashing and the hash algorithm is SHA1 (the default; same one used by LinkedIn) and assuming the membership database is breached, are there any additional steps that can be taken to further mitigate exploitation of said data?
From quickly looking at the membership schema, passwords seem to utilize a salt key. Is this measure sufficient?
To make things short: for storing passwords, you should never go with MD5, SHA1, SHA256, SHA512, SHA-3, etc... bcrypt is the only safe way to store a password.
Here is the why of the affirmation above:
Since my question a while back
Is this the way to salt and store a Password in Db?
I started to use BCrypt as my password hashing code, and from what I keep reading, even if you get hold of the users table, it is pretty difficult from that get the plain text of the storage password.
I use this in my Custom Membership Provider so I get to host my own passwords.
From the blog post:
Why BCrypt? Most popular password storage schemes are based on fast hashing algorithms such as MD5 and SHA-1. BCrypt is a computationally expensive adaptive hashing scheme which utilizes the Blowfish block cipher. It is ideally suited for password storage, as its slow initialization time severely limits the effectiveness of brute force password cracking attempts. How much overhead it adds is configurable (that's the adaptive part), so the computational resources required to test a password candidate can grow along with advancements in hardware capabilities.
From codahale.com you can also read How to safely store a password as well...
By the way, BCrypt project is on Codeplex
Related
I'm making an application that needs logging in.
I used node.js as API.
I understand I have to encrypt the password on backend in case the database is stolen.
But if for some reason HTTPS failed or some developer on our side had malicious intention he/she could easily steal the raw password if it wasn't encrypted on the frontend as well.
So my question is is there a problem if I use Argon2 on backend and BCrypt on frontend together?
(Also I assumed that Argon2 is faster so if the attacker wants to brute force he has to use the slow one as well on his side instead of my api heavylifting his/hers shannigans)
I know there are some simillar questions, but they ask if i should use one OR the other and the answer is backend and HTTPS.
I WILL use HTTPS and backend encryption. But I ask if it's possible (or a good idea) to use encryption on the frontend as well.
Argon2 and BCrypt are not encryption algorithms. They're password stretchers (formally "PBKDFs" or "Password-based Key Derivation Functions"). It doesn't make sense to use both, however.
The design you're looking for is this:
Apply a password stretcher on the front-end so that the raw password is never sent to the server.
On the backend, apply a fast hash (SHA-256) so that the hashed password is not stored in the database.
The first part protects the user. Their password never leaves their machine. The second part protects your database. Even if it's stolen, there's no way for an attacker to use the hashes stored there to log into your system.
We are currently implementing our authorization to a restricted resource by encrypting specific information and the password given to create a token using AES/CBC/PKCS5Padding encryption with a 128bit private key known only to the server.
Inside this token we place
hash of password(sha-512 and a random salt of 64 bytes)
expiry date
valid flag (boolean)
creation date timestamp
The server then encrypts this information using its private key and passes it to the client.
The client requests the restricted resource and presents this token to the server which decrypts it and validates the contents to provide access to a restricted resource.
We wish to do it this way to avoid keeping information regarding issued tokens on our server to avoid potential resource limitations.
Since I am not a security expert any help showing possible vulnerabilities or why this is a bad idea would be much appreciated.
Just send the hashed version for comparison.
Just using a hash function is not sufficient and just adding a salt does little to improve the security. Instead iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash. Use functions such as PBKDF2 (aka Rfc2898DeriveBytes), password_hash/password_verify, Bcrypt and similar functions. The point is to make the attacker spend a lot of time finding passwords by brute force. Protecting your users is important, please use secure password methods.
See Toward Better Password Requirements by Jim Fenton.
[DRAFT NIST Special Publication 800-63B Digital Authentication Guideline](
https://pages.nist.gov/800-63-3/sp800-63b.html)
NIST’s new password rules – what you need to know:
https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/ by Sophos
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.
I am developing ASP.NET web application for a financial institution that is accessible by authenticated users. As a requirement, password for each user need to be encrypted so that Database Administrators can't have access to any user's password. I have gone through various types of encryption and hashing algorithms, but not sure which can be best suited for my requirement.
Whenever possible, prevent storing passwords all together, for instance by using Windows Authentication. If that is not possible, use the industries best practices in storing passwords. This means that you should:
Use password hashing (not encryption)
Add a salt to the hash
Use a computational intensive hashing algorithm.
The big danger of storing passwords is that the passwords of thousands of users get compromised when someone breaks into your system (or your DBA steals them). Although you can every user's password in your system, users usually use the same password over and over again and this means that the user is at risk when their password is compromised. Of course it is of course bad practice to reuse passwords, this is what users do and it is our job to at least minimize the risk for our users by doing anything that is within our power to do so. Don't forget that failing to do so, might even cause your company to get sued. This happened with LinkedIn.
So for password hashing this practically means that password hashing using MD5 and SHA (even with salting) is pretty useless, since those algorithms are optimized for speed, which allows hackers compute 2300 million salted hashes per second (brute force).
Some well-known computational intensive hashing algorithm are PBKDF2, Bcrypt, PBMAC, and scrypt. In .NET there's an PBKDF2 implementation named Rfc2898DeriveBytes. Here's a good example of the use of Rfc2898DeriveBytes (complete with configurable computational intensiveness, which allows this method to allow to withstand ever increasing computing power of computers).
Using some well-known frameworks that implement best-practices might be a good idea as well. #trailmax already suggested the AspNet Identity framework, which uses PBKDF2. However, prevent from using ASP.NET's SqlMembershipProvider, since it uses SHA by default, and it's actually quite hard to reconfigure it to use a safe method.
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.