Password Encryption in .Net with C# Examples and VB.Net Examples

[Jayesh Sorathia]

For security purpose there is a need to convert plain string in cryptographic string or encrypt password, so hackers did not understand the password.
You can create cryptographic string using seven different algorithms that provided in .Net Framework.
This is mainly use in encrypt a password and store.

Visit this link to view examples on this. Click Here... http://jayeshsorathia.blogspot.com/2012/08/net-tips-password-encryption-in-net.html

 

[Arne Vajhøj]

For security purpose there is a need to convert plain string in cryptographic string or encrypt password, so hackers did not understand the password.
You can create cryptographic string using seven different algorithms that provided in .Net Framework.
This is mainly use in encrypt a password and store.

For storing passwords (if one can use that term when the password is not
actually stored) salt should always be used. And it should be a
different salt for each user.

Optionally multiple rounds of hashing can be applied.

64 bit random salt
SHA-256
10-100 rounds

should be minimum (too many rounds burn a lot of CPU for legit usage).

Arne

 

[Arne Vajhøj]

Hint: "encrypt" != "hash".

See also "salt", since you claim to be defending against "hackers".
Yep.

Finally note that both MD5 and SH1 are not collision resistant, meaning
they are not cyptographically secure (i.e. even using salt isn't
protective). Hashing a password doesn't give you any real security if a
hacker can easily create a completely different password that results in
the same hash.

????

Creating a password that gives the same hash is not a collision
attack but a pre image attack.

A collision attack is creating two passwords that has the
same hash.

Collision attacks are not in themselves a problem for hashing
of passwords.

Both MD5 and SHA1 are vulnerable against collision attack (both
theoretical and practical).

MD5 is theoretical but not practical vulnerable against
pre image attack (from Pow(2, 128) to Pow(2, 123.4) work).

As far as I know SHA1 does not have any current
vulnerability against pre image attacks.

The reason why MD5 and SHA1 should not be used for hashing
of passwords are:
1) it is often assumed that hashes with known collision attacks
are more likely to become vulnerable against pre image
attacks in the future
2) it is a lot easier to just always use a hashing algorithm that
does not have any known vulnerabilities instead if doing
evaluations and documentation on a per case basis

Arne

 

[Jayesh Sorathia]

For security purpose there is a need to convert plain string in cryptographic string or encrypt password, so hackers did not understand the password.

You can create cryptographic string using seven different algorithms that provided in .Net Framework.

This is mainly use in encrypt a password and store.

Visit this link to view examples on this. Click Here... http://jayeshsorathia.blogspot.com/2012/08/net-tips-password-encryption-in-net.html

Hint: "encrypt" != "hash".



See also "salt", since you claim to be defending against "hackers".



Finally note that both MD5 and SH1 are not collision resistant, meaning

they are not cyptographically secure (i.e. even using salt isn't

protective). Hashing a password doesn't give you any real security if a

hacker can easily create a completely different password that results in

the same hash.



Please, really...if you must keep writing this "Beginning .net [sic]" blog,

and especially if you must keep spamming the "advice" here too, stick to

the things that are truly "beginner" topics and which you yourself actually

have some expertise in.



You are doing the entire computer industry a disservice by pretending that

you know something about security. There are enough servers out there on

the Internet with insecurely-stored passwords as it is without you helping

to make the problem worse.



Pete

Hi,
I publish only those things that I know.
Many people does not know this things. So this articles are helpful for those peoples. I did not anything in this article that, this is complete article on security. This article is beginning of security level. Interested people find on internet more on this.
If you know other things why you not publish on internet ?
Publish on internet so people can know easily.

 

[Jayesh Sorathia]

But you "know" incorrect things.






You just aren't getting it.



"Beginning security" is an ill-conceived notion on your part. Everyone has

to start somewhere, but you can't leave critical details out. Your version

of "beginning security" is worse than not teaching security at all.



See also "law of primacy" as it pertains to education. People who use your

blog as their first resource (and with luck, that's a very small number of

people) are going to learn the wrong habits first, making it that much

harder for them to learn the correct ones.



It's bad enough you don't feel a need to comply with the societal norms

that guide our (albeit small) community here. But when you teach the wrong

thing, that's worse than just having bad manners.

If you claim that you know right thing than upload on net

 

[Arne Vajhøj]

I publish only those things that I know. Many people does not know
this things. So this articles are helpful for those peoples. I did
not anything in this article that, this is complete article on
security. This article is beginning of security level. Interested
people find on internet more on this. If you know other things why
you not publish on internet ? Publish on internet so people can know
easily.

People can only write what they know.

But you have now known for a couple of days that hashing
of passwords should be done with salt (a different salt for
each user) and your example still do not use salt.

And from a security perspective that is not good. It is
not a matter of beginner versus advanced. It is so bad that
not even beginners should do it this way.

Arne

 

[Anders Eriksson]

But you have now known for a couple of days that hashing
of passwords should be done with salt (a different salt for
each user) and your example still do not use salt.

Not knowing anything about encryption and such I will ask a silly question!

If I use a salt that's different for each password as you suggests. Will
I not need to save the salt together with the hash to be able to check
if the user has entered the correct password?

Isn't that a security risk?

// Anders

 

[Arne Vajhøj]

Not knowing anything about encryption and such I will ask a silly question!

Questions are never silly.

Answers sometimes are.

If I use a salt that's different for each password as you suggests. Will
I not need to save the salt together with the hash to be able to check
if the user has entered the correct password?
Yes.

Isn't that a security risk?

No.

It does not impact the function of salt.

The use of salt prevents the usage of precomputed tables
to go from hash to valid password.

You can precompute tables with all English words, all
combinations of A-Za-z0-9 up to length 7 etc..

But with a random salt added those tables (commonly
known as "rainbow tables") becomes useless.

And this is not a theoretical concept such tables
are available on the internet.

The use of different salt per user makes it harder
to crack a large user database.

If the salt is the same you calculate hash(salt + common
password) and look if any of the N users has used that
password.

With different salt you need to do all the calculations
for each user.

Neither function require the salt to be kept secret.

The secret part is the password. If "more secrecy" is
needed then enforce longer passwords.

In many sense salt for hashing is the equivalent of
IV (initialization vector) for encryption.

It is important that it is random - it does not need
to be kept secret.

So salt is stored together with username.

And IV is often send unencrypted first in the message.

Arne

 

[Anders Eriksson]

Questions are never silly.

You haven't seen some of my questions yet ;-)

The use of salt prevents the usage of precomputed tables
to go from hash to valid password.

So the salt it to force anyone wanting to break the password to do so
calculating for each password and not be able to use a Rainbow Table.

I googled a bit about this and also found that there are some crypto
functions that iterates the hashing a number of times, this making it
slower to calculate and therefor harder to break. Not sure about the
correctness of this...

Two "libraries" that was mentioned was:
bcrypt - http://bcrypt.codeplex.com/
PBKDF2 - http://msdn.microsoft.com/en-us/magazine/cc163913.aspx

I usually make Desktop application and when I need to have some extra
"security" (permission) I normally use Local Group and make the program
check if the logged in user is a member of a specific group. If not then
the extras is disabled...

// Anders

 

[Arne Vajhøj]

You haven't seen some of my questions yet ;-)


So the salt it to force anyone wanting to break the password to do so
calculating for each password and not be able to use a Rainbow Table.
Yes.

I googled a bit about this and also found that there are some crypto
functions that iterates the hashing a number of times, this making it
slower to calculate and therefor harder to break. Not sure about the
correctness of this...

It is a valid and often recommended approach.

I usually suggest not doing too many rounds as it also increases
CPU usage for legit usage in the app itself.

Two "libraries" that was mentioned was:
bcrypt - http://bcrypt.codeplex.com/
PBKDF2 - http://msdn.microsoft.com/en-us/magazine/cc163913.aspx

Those are a few of the more well known.

I usually make Desktop application and when I need to have some extra
"security" (permission) I normally use Local Group and make the program
check if the logged in user is a member of a specific group. If not then
the extras is disabled...

You then piggy back in Windows security.

Windows uses hashing. Actually it does not use salt, but it
uses a "challenge" which has a very similar function.

Arne