It's better practice to hash a password rather than encrypt it. Very basically, hashing is a one-way mechanism whereas encryption is reversible.

Why's this important? Well, if a malicious entity (which could be an employee) finds how you've encrypted the data (either by brute force or just stealing the key etc.) they can decrypt it - and then (mis)use your customers passwords, most of which will have been re-used elsewhere (other sites, email, banking etc.). A breach like that would harm the reputation of your site / company.

With a hash, you can know how a hashed value has been generated, but you won't know the value (their password) that has generated it. Unless, of course, you're not securing the communication between the server at log on (HTTP instead of HTTPS web pages, for example). *

As part of this process, the password should also be salted:

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase.[1] The primary function of salts is to defend against dictionary attacks versus a list of password hashes

Source: http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Again, very basically, this would be where an attacker takes a list of known / common (pass)words, say "letmein" and hashes it. Know they'll know the Hash that corresponds to the password "letmein" and can quickly lookup to see if any of your users have the same password hash. Obviously, this is very easy to automate with a "dictionary" of possible / common (pass)words. Salting helps to prevent this scenario.

As for how to implement it in .NET, see this question (and answers) from Stack Overflow:

http://stackoverflow.com/questions/19957176/asp-net-identity-password-hashing

I'm not terribly familiar with .NET development, but according to the answer from @jd4u the default implementation uses a salt in addition to the user's password when producing a Hash.

* If your site pages (at least the log on) aren't already served over a secure connection, get this done too.

It's better practice to hash a password rather than encrypt it. Very basically, hashing is a one-way mechanism whereas encryption is reversible.

Why's this important? Well, if a malicious entity (which could be an employee) finds how you've encrypted the data (either by brute force or just stealing the key etc.) they can decrypt it - and then (mis)use your customers passwords, most of which will have been re-used elsewhere (other sites, email, banking etc.). A breach like that would harm the reputation of your site / company.

With a hash, you can know how a hashed value has been generated, but you won't know the value (their password) that has generated it. Unless, of course, you're not securing the communication between the server at log on (HTTP instead of HTTPS web pages, for example). *

As part of this process, the password should also be salted:

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase.[1] The primary function of salts is to defend against dictionary attacks versus a list of password hashes

Source: http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Again, very basically, this would be where an attacker takes a list of known / common (pass)words, say "letmein" and hashes it. Know they'll know the Hash that corresponds to the password "letmein" and can quickly lookup to see if any of your users have the same password hash. Obviously, this is very easy to automate with a "dictionary" of possible / common (pass)words. Salting helps to prevent this scenario.

As for how to implement it in .NET, see this question (and answers) from Stack Overflow:

https://stackoverflow.com/questions/19957176/asp-net-identity-password-hashing

I'm not terribly familiar with .NET development, but according to the answer from @jd4u the default implementation uses a salt in addition to the user's password when producing a Hash.

* If your site pages (at least the log on) aren't already served over a secure connection, get this done too.

It's better practice to hash a password rather than encrypt it. Very basically, hashing is a one-way mechanism whereas encryption is reversible.

Why's this important? Well, if a malicious entity (which could be an employee) finds how you've encrypted the data (either by brute force or just stealing the key etc.) they can decrypt it - and then (mis)use your customers passwords, most of which will have been re-used elsewhere.

With a hash, you can know how a hashed value has been generated, but you won't know the value (their password) that's generated it. Unless, of course, you're not securing the communication between the server at log on (HTTP instead of HTTPS web pages, for example).

As for how to implement it in .NET, see this question (and answers) from Stack Overflow:

http://stackoverflow.com/questions/19957176/asp-net-identity-password-hashing

It's better practice to hash a password rather than encrypt it. Very basically, hashing is a one-way mechanism whereas encryption is reversible.

Why's this important? Well, if a malicious entity (which could be an employee) finds how you've encrypted the data (either by brute force or just stealing the key etc.) they can decrypt it - and then (mis)use your customers passwords, most of which will have been re-used elsewhere (other sites, email, banking etc.). A breach like that would harm the reputation of your site / company.

With a hash, you can know how a hashed value has been generated, but you won't know the value (their password) that has generated it. Unless, of course, you're not securing the communication between the server at log on (HTTP instead of HTTPS web pages, for example). *

As part of this process, the password should also be salted:

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase.[1] The primary function of salts is to defend against dictionary attacks versus a list of password hashes

Source: http://en.wikipedia.org/wiki/Salt_%28cryptography%29

Again, very basically, this would be where an attacker takes a list of known / common (pass)words, say "letmein" and hashes it. Know they'll know the Hash that corresponds to the password "letmein" and can quickly lookup to see if any of your users have the same password hash. Obviously, this is very easy to automate with a "dictionary" of possible / common (pass)words. Salting helps to prevent this scenario.

As for how to implement it in .NET, see this question (and answers) from Stack Overflow:

http://stackoverflow.com/questions/19957176/asp-net-identity-password-hashing

I'm not terribly familiar with .NET development, but according to the answer from @jd4u the default implementation uses a salt in addition to the user's password when producing a Hash.

* If your site pages (at least the log on) aren't already served over a secure connection, get this done too.