After research I have found out that using hascode to verify password on login page is more secure but can anyone give me some insights code wise how to achieve it ?
-
I suggest you read [CrackStation: Secure Salted Password Hashing - Doing it Right](https://crackstation.net/hashing-security.htm) – dav_i Jun 05 '14 at 12:59
-
Check this answer: http://stackoverflow.com/questions/23448510/linq-to-sql-authenticate-login-credentials/23448529#23448529 it gives an explanation about how to implement such hashing and checking. – Max Jun 05 '14 at 13:49
2 Answers
I won't write code for you, but I will explain briefly how it works.
First, understand the difference between hashing and encryption. If you don't realize there is a difference, read this: Fundamental difference between Hashing and Encryption algorithms
By default, your password is in plaintext, which is bad. Ideally, you want to be able to store that password in a non-plaintext way so that you can compare it to data that a user sends you. To do this, you can either store an Encrypted password or a Hashed password.
If you choose to store an encrypted password, that implies that you intend to someday retrieve the original plaintext password (which, really, you should never need to do). Additionally, you need to store the key somewhere, and it gets messy (because you don't really want to store THAT plaintext either, so you encrypt it, but then you need ANOTHER key, etc.), so let's just assume you don't want to go this way.
If you choose to store a HASHED password, then what you are storing is a fixed-length representation of that password. A human cannot determine the original password simply by looking at the hash (which is good).
On the client end, then, you still have that plaintext password that they need to submit. This is where encryption comes in. You will want to encrypt the connection between the client and server. The user submits their plaintext password, it gets encrypted so that nobody can understand it, your server decrypts it, and then immediately hashes it. At this point, you may now compare that hash to the one stored in your database.
Please note that hashing the password client side and assuming that encryption is no longer necessary is NOT secure.

- 1
- 1

- 4,181
- 2
- 18
- 28
Convert given password into its hash:
using System.Security;
using System.Security.Cryptography;
...
public static String GetHashValue(String password) {
// You may find useful to add "salt" here:
// Byte[] buffer = Encoding.ASCII.GetBytes(password + "some const irregular string");
Byte[] buffer = Encoding.ASCII.GetBytes(password);
// I've chosen the strongest (but the longest) hash provider
using (SHA256 provider = SHA256Managed.Create()) {
return String.Join("", provider.ComputeHash(buffer).Select(x => x.ToString("X2")));
}
}
then try to find user by his/her login and password hash:
select permissions,
...
from Users
where login = @prm_login and
password_hash = @prm_password_hash
Note, that you don't store password (e.g. "123") in the database, but the hash (e.g. "A665A45920422F9D417E4867EFDC4FB8A04A1F3FFF1FA07E998E86F7F7A27AE3"
)

- 180,369
- 20
- 160
- 215
-
Hashes of the SHA* family are not appropriate to hash passwords, because they are ways too fast. You can calculate about [1 Giga SHA256](http://hashcat.net/oclhashcat/#performance) hashes per second with common hardware. So you should switch to a hash algorithm with a cost factor like [BCrypt](http://bcrypt.codeplex.com/) or PBKDF2. – martinstoeckli Jun 05 '14 at 19:35