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/2...on-in-net.html

On 8/21/2012 3:54 AM, Jayesh Sorathia wrote:
> 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

On 8/21/2012 10:24 AM, Peter Duniho wrote:
> On Tue, 21 Aug 2012 00:54:18 -0700 (PDT), Jayesh Sorathia wrote:
>
>> 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.

> 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

On Tuesday, 21 August 2012 19:54:23 UTC+5:30, Peter Duniho wrote:
> On Tue, 21 Aug 2012 00:54:18 -0700 (PDT), Jayesh Sorathia wrote:
>
>
>
> > 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/2...on-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.

On Wednesday, 22 August 2012 19:49:24 UTC+5:30, Peter Duniho wrote:
> On Wed, 22 Aug 2012 00:53:47 -0700 (PDT), Jayesh Sorathia wrote:
>
>
>
> > I publish only those things that I know.
>
>
>
> But you "know" incorrect things.
>
>
>
> > 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.
>
>
>
> 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

On 8/22/2012 3:53 AM, Jayesh Sorathia wrote:
> 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

On 2012-08-25 03:05, Arne Vajhøj wrote:
> 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

--
English isn't my first language.
So any error or strangeness is due to the translation.
Please correct my English so that I may become better.

On 8/25/2012 3:37 AM, Anders Eriksson wrote:
> On 2012-08-25 03:05, Arne Vajhøj wrote:
>> 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!

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

On 2012-08-25 17:50, Arne Vajhøj wrote:
> On 8/25/2012 3:37 AM, Anders Eriksson wrote:
>> On 2012-08-25 03:05, Arne Vajhøj wrote:
>>> 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!
>
> 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

--
English isn't my first language.
So any error or strangeness is due to the translation.
Please correct my English so that I may become better.

On 8/25/2012 12:22 PM, Anders Eriksson wrote:
> On 2012-08-25 17:50, Arne Vajhøj wrote:
>> On 8/25/2012 3:37 AM, Anders Eriksson wrote:
>>> On 2012-08-25 03:05, Arne Vajhøj wrote:
>>>> 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!
>>
>> 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.

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