[RESOLVED] Password Hashing and Salt

[GBeats]

Hi

im just studying best practices for using and storing login information, it seems the best way to store passwords right now is with a SHA-2 Hash function and also salting the password, my question is regarding salting.

the reason you hash a password is to secure against a compromise within your database...... but if your storing a salted password thats been hashed WITH the salt how does that actually provide more security?

its like having an encrypted file and storing the key next to it is it not ....

forgive my ignorance it just seems that way to me.

[jmcilhinney]

It's not necessarily easy to answer that question quickly, but it is easy to find an existing answer quickly. I just searched for "why salt a hashed password" and this was the second result:

https://www.addedbytes.com/blog/why-...t-your-hashes/

By the way, this question has nothing specifically to do with VB.NET so it doesn't belong in the VB.NET forum. General Developer would have been more appropriate.

[GBeats]

Hi, ok yes sry i was going to lead onto the best ways to implement this with vb.net. but i think another thread would be more appropriate.

i did however just spend a little time researching and it seams that the whole point is to slow down an attack rather than prevent it... which makes sense regarding using lookup tables etc.

thanks ill have a look through the link you provided too.

[techgnome]

Hashes are one-way... the salt is used to encrypt the value... but it cannot be used to decrypt the data, so it's not really a key. It's more like a one-way tamper proof screw.

-tg

[Shaggy Hiker]

You're right that it takes longer to crack. The reasons are complex, but this link might be a start....down a rabbit hole:

https://blog.codinghorror.com/youre-...s-incorrectly/

If you follow links from that article, you'll find some pretty detailed explanations of just HOW salting protects you. One of the points is that it doesn't matter all that much whether the salt is protected, because it just makes the effective password MUCH longer, and that makes the options for cracking the hashed password vastly more costly.

[Sitten Spynne]

The most common attacks are the easy, fast ones. For many hash algorithms, people have created HUGE (sometimes Terabytes in size) lookup tables of "every possible password hashed with this algorithm". The hashes for passwords like "password" and "password123" can be cracked instantly with these lookup tables, because the same word always hashes to the same value.

So if you have 10 users that all have a well-known password, all 10 of them will be cracked immediately in an unsalted database.

The way salt works is you pick some big, random value and add it to the password, THEN hash it. So instead of hashing "password", now you hash something like "passwordaspdlkjfa;isdhf;laihsdj;lfiajhosiuejpoij". That is very long, and very unlikely to be in someone's lookup table. Generating a lookup table for passwords that long would take many, many Terabytes of disk space and potentially years of time.

It has to be DIFFERENT salt for every user though. Let's say you ALWAYS use the word "orange" as salt. If the attacker knows this, they can generate a lookup table for passwords like "passwordorange", and you're right back to being cracked every single time.

So you use very long, random salt for each user. This way the attacker has to consider making a lookup table for EVERY password in the system, row-by-row. This takes a LOT longer per row. People with weak passwords are still likely to be cracked, but the attacker has to decide if it's worth spending "several minutes" instead of "several seconds". That actually causes some people to get bored and move on.

That's really it. It's like putting a lock on a door. The people who just want to turn the knob and push are now deterred. But a skilled lockpick can defeat the average lock in less than 10 seconds. Thing is, there's millions of "turn the knob" thieves but only thousands of "skilled lockpicks". So it's worth turning away the "casual" thieves.

[Shaggy Hiker]

Originally, salts may not have started out as different ones, or perhaps there were only three or four different ones. As long as the hacker knew the salts you used, they could generate a table for those salts, but that was still a sufficient pain that it was good enough. That's not really the case anymore, and a random salt isn't hard to generate. Better still, you can store that random salt in plain text....for now. At this point, it's still too daunting a task to create those huge lookup tables for each and every salt, so just knowing the salt isn't enough. That's likely to change, though. Cheap GPU processors will likely be able to generate lookup tables on the fly, and terabytes just aren't what they used to be (my first computer had a 44 MB HD, and I thought I was pretty cool...now look at us).

So, require a lengthy password (I would argue for a pass phrase, at this point, just so that you can require over 13 characters and still be able to remember the darn thing), create a random salt....and recognize that you may end up encrypting the salt.

[Sitten Spynne]

Yeah, the #3 thing people do that hurts security (after storing encrypted passwords or unsalted hashes) is they put a maximum length like 12 or 16 on passwords. Set your maximum password length to something like 128.

#4 is "I'm going to be cute and have rules like "2 capitals, 2 lowercase, 2 digits"". That excludes millions of passwords and makes it faster to generate a custom lookup table. There is never a case where those rules increase password security.

#5 is "I'm not going to support Unicode", as in "Please use only numbers, letters, and these special characters." I feel like (at this moment) a 4-letter password made entirely of Emoji is 99% likely to go uncracked. No one's got lookup tables for "all of Unicode" as far as I know. I'm not even sure why people restrict character sets. Probably because some yokel copy/pasted his username validation regex for a password field one day, and a million dumber yokels copied it and assumed it was "for security".

[techgnome]

#4a - Use at least 1 capital, AND 1 lower, AND 1 number, AND 1 special character....

That's usually a problem for me... I don't use special characters in my phrases. That makes them less memorable as I then have to remember what I replaced what what and where. Give me a minimum and no max, or a really large max, I'm going to come up with something that's virtually complex enough that it's going to take a loooooong time to brute force. I've done the math. Using the pattern and word files I have, I have enough combinations well in excess of 4-quadrillion and that's before capitalization and other variations come into play.

Oh, and this one was a beaut to encounter recently: no part of the password can appear in a dictionary. Essentially they wanted a 16-lettered "$#%!$%#$%^%$FGGBTG^%^GVTETV%" ... wait... no numbers and no lower case.... so that means "%^$gfjyASD572#$f" instead.

-tg

[Shaggy Hiker]

I use special characters in my speech daily. Printed out it might look like MOSTLY special characters like: @$$#013!

Anyways, this is pretty much my view on passwords:

https://xkcd.com/936/

However, so few systems currently allow such a thing that it barely even matters.

[Sitten Spynne]

Heh, here's a clever, secure way to do it that would fit 90% of peoples' usage pattern:

• Let the password column allow NULL.
• Other column: lastActivity (timestamp), also nullable
• When you sign up, 'password' is set.
• When you log in, or do anything, lastActivity is updated.
• Every 12 hours, any row where lastActivity is older than an hour has password set to NULL.
• Login code notes when the column is NULL and offers the "forgot password" workflow.

End result: every 12 hours or so everyone has to go through the "I forgot my password" process to log in. Odds are this means your system is very rarely holding on to lots of password data, and the data is out-of-date within 12 hours anyway.

This is actually a sort of ghetto implementation of 2-factor auth: you've shifted the question from, "Can you tell me a password?" to more frequently, "Do you control this email address?"

[techgnome]

I don't mind the minimum of one Cap, one Lower, and one number... it's symbols I'm not a fan of, although I can deal with it. But the "can't use anything found in the dictionary" is just uncalled for. I've had my password rejected at two sites because it contained a word - several actually, since I use pass phrases with at least 4 words in it - that was in the dictionary.

-tg

[Shaggy Hiker]

I don't mind the minimum of one Cap, one Lower, and one number... it's symbols I'm not a fan of, although I can deal with it. But the "can't use anything found in the dictionary" is just uncalled for. I've had my password rejected at two sites because it contained a word - several actually, since I use pass phrases with at least 4 words in it - that was in the dictionary.

-tg

Well, I never thought of you as symbol minded anyways.

[techgnome]

"Symbols are for the symbol minded." - George Carlin.

-tg

[DEXWERX]

No ones mentioned Rfc2898DeriveBytes... but I bet some of the links discuss why SHA-1 in this context is fine.

[GBeats]

Hi guys nice conversation ......

restrictions in passwords surely give an undesirable hacker the info he needs to lessen his work. after all if you know this isnt possible ill just not test for it ..... seems counter security, but on the flip side is does force the ignorant people to make a stronger password which is good for those people really .... hard to say which is better or worse ..

anyway i've opted for a 2 stage hashing process

1, App side hashing, ive not decide how i will do this yet, i have another post on this right now

2, a second server side sha512 hashing with a random 64bit cryptic salting

pls check my other thread and give me your insight, i have my process over HERE

[Shaggy Hiker]

Actually, what you started out with isn't quite right. Hackers tend not to "test for possible things". The hash creates a unique string from which the original password can't be obtained. So, the hacker doesn't care what can and can't be used, for the most part. That would be a hacker assuming that passwords were being stored as plain strings, which means that the hacker is assuming that you never had this conversation, or did any research. That's sadly common, but...kind of irrelevant.

If the hacker assumes that you have hashed the password, then the rules for the password don't really matter all that much. The hacker will generate tables of hashed passwords and look for a hash that matches your hash. Sure, those tables could be smaller if you assumed that only letters were used, but not THAT much smaller. If you just went with upper and lower case letters you have 52 possible characters. Digits only add another 10, and symbols don't add that many more (Sitten's point about unicode notwithstanding, since that would allow for FAR larger character sets). So, if you have only one character passwords drawn from upper and lower case, and digits, you have only 62 possibilities. With two character passwords, you have 62 * 62. So, for a password of length N, you have N^62. Even for two characters that's kind of large, but for each extra character in the password, the number of possible passwords increases exponentially.

My point being that rules for what characters must be in a password has less impact than minimum length requirements, and rules for patters in character sets are almost entirely pointless, since that would only weed out the lazy hackers. Sure, they might have a "greatest hits" table that they try first, but if they've got the hash of the password already, It's just a matter of time to find a match. Length impacts that the most, character sets a bit less, and pattern rules not at all.

This is the link I should have put in #5, but didn't find it in time:

https://blog.codinghorror.com/your-p...oo-damn-short/

[Sitten Spynne]

The point I'm going for is something like:

Long passwords with unrestricted character sets are the easiest to implement and provide the most bang for your buck. Restricting length to a "maximum" range is effort and reduces overall security (within reason... there's no need for 1,024 character passwords.) Restricting the allowed characters is effort and reduces overall security. Implementing rules like "2 uppercase letters, 2 digits, etc." is even more effort and reduces overall security.

So the laziest possible thing (12-50 UTF-8 characters) is the most secure. The more complex you make it, the less security you have. I do agree "length" impacts security more than "character set", but the "rules" people implement are a lot harder to get right.

True story:

I have more than a dozen Twitter accounts, for reasons. I needed a new one once, and tried to make a password that included a space since it didn't seem forbidden. At this point in time (hopefully it's changed), creating an account didn't require you to double-type your password: you just put it in once. It turns out the "create an account" page uses different validation code than the "log in" page. So I could create an account with a password like, "eat my shorts", but at login I would be told the password was incorrect (because it contained invalid password characters.) So I had to go through the "forgot my password" process, which was difficult because the account didn't even have a verified email yet.

There's not a good reason to NOT allow spaces in passwords, so I'd argue the bug is in the "log in" page. It thinks some characters aren't valid for passwords, but they're perfectly valid!

[jmcilhinney]

I have more than a dozen Twitter accounts, for reasons.

Troll confirmed.

[Sitten Spynne]

Ha, no, I love them too much and I always worry getting suspended on one account will get me suspended from others.

One's for fun. The other's for "being professional", and I keep them disconnected though they're not hard to connect. One's parking a username I came up with but have never really associated with "me", I used it for a brief stint where my main account was suspended for making a joke that got me auto-banned by @Support. No sense of humor. Two belong to friends who aren't tweeting anymore, but trust me to relay anything interesting that gets DMed.

The other 17 I take great pains to disconnect from but every now and then someone surprises me and sniffs me out. One's got more than 14,000 followers and I'm very proud of the work I've done on it.

The "professional" one is easy to find. The "fun" one might be easily traceable from there. The rest are pretty niche interests.

[GBeats]

coming up with a 100 character password seem to be just as effective as having a 64bit hashed password....

i do sometimes use phrases as my passwords, like maybe some sentence from a book or something like that.

one thing i did notice regarding hashing is, there are far more variations of passwords then there are hash variations, meaning that whole concept of hashing is flawed.

its like someone came up with them and got lazy and said .... well its good enough, ha but in time they never are so it seems.

i true hash function in my opinion should not be limited by length in bytes and should be as varied as password possibilities in terms of providing the best security.

[PlausiblyDamp]

coming up with a 100 character password seem to be just as effective as having a 64bit hashed password....

However if the password store was compromised a 100 character password would be visible, a 64 bit has would still need to be brute forced to obtain the password. The two things are not the same in this case.

i do sometimes use phrases as my passwords, like maybe some sentence from a book or something like that.

Always a good idea, doesn't mean that storing the hash of a passphrase is a bad thing though.

one thing i did notice regarding hashing is, there are far more variations of passwords then there are hash variations, meaning that whole concept of hashing is flawed.

its like someone came up with them and got lazy and said .... well its good enough, ha but in time they never are so it seems.

i true hash function in my opinion should not be limited by length in bytes and should be as varied as password possibilities in terms of providing the best security.

The whole point of a good hash algorithm is to turn a sequence of input bytes into a shorter byte sequence that cannot be decrypted into the original text, using something like a SHA-256 (https://en.wikipedia.org/wiki/SHA-2 is worth a read) you are getting the benefits of some very technical, advanced, and peer reviewed cryptography.

A 64 bit value can contain a lot more variety than you realise, what you are looking at is 2 raised to the power of 64 combinations so according to windows calculator that is 18,446,744,073,709,551,616 combinations. I am not entirely sure what the name for that many zeros is but google reckons it is 18 quintillion. That seems an awful lot of scope for variety.

[GBeats]

The whole point of a good hash algorithm is to turn a sequence of input bytes into a shorter byte sequence that cannot be decrypted into the original text

this is the flaw that i see.... a string is just a byte sequence, logically if you turn a large sequence into a smaller sequence the only logical think to think it that some sequences have doubles..... its impossible to turn 12345 in to just 123 without adding extra bytes which would give u a formula to do it.

but after thinking about it a bit i also noticed that having a hash that increased in size would also give away the size of the hashed string so that is definitely a downfall and a big one....

i dont know, im still thinking about it all , im probably digging a little to deep into this but thats my responsibility

[jmcilhinney]

I'm sure that, if you cogitate on it for a while, you're sure to come up with something that all the great minds in computer science and cryptography who have worked in the field for the past few decades have missed.

After reading that back I thought I should clarify that I'm not talking about us here. I'm talking about the people who have been working on security and cryptography specifically, e.g. those who come up with hashing algorithms. In short, while flaws are found in specific algorithms over time, I don't expect you to stumble upon a flaw in the concept of hashing that has escaped the experts all this time.

[GBeats]

I'm sure that, if you cogitate on it for a while, you're sure to come up with something that all the great minds in computer science and cryptography who have worked in the field for the past few decades have missed.

is that sarcasm or praise

how about this quote (which is not a quote but something i notice)

the people of today know everything plus some compared to the people of yesterday.

[jmcilhinney]

the people of today know everything plus some compared to the people of yesterday.

Yeah but most of what we know is because people who know what they're talking about tell us. As I said, it's quite possible that flaws could be found in specific hashing algorithms or the like but I'm fairly certain that decades of work by many people far smarter than you and me isn't going to be brought down by pointing out that hashes are quite short. If that was actually going to be an issue, I'm confident that someone would have noticed it before now. If my confidence is misplaced then I'd suggest that we can't truest anything in computer science. I'm not saying that you shouldn't try to understand how and why hashing works but I suggest that you assume that it does.

[PlausiblyDamp]

this is the flaw that i see.... a string is just a byte sequence, logically if you turn a large sequence into a smaller sequence the only logical think to think it that some sequences have doubles..... its impossible to turn 12345 in to just 123 without adding extra bytes which would give u a formula to do it.

but after thinking about it a bit i also noticed that having a hash that increased in size would also give away the size of the hashed string so that is definitely a downfall and a big one....

i dont know, im still thinking about it all , im probably digging a little to deep into this but thats my responsibility

If that was all that hashing involved then it would indeed be a rubbish approach. As an example the hash of "12345" using an online SHA256 generator works out at "5994471abb01112afcc18159f6cc74b4f511b99806da59b3caf5a9c173cacfc5" the length of the result is fixed in size, it is not a shorter version of the input unless the input is larger than the hash length.

Did you look at the link I previously posted https://en.wikipedia.org/wiki/SHA-2 as that gives a lot more background information.

[jmcilhinney]

If that was all that hashing involved then it would indeed be a rubbish approach. As an example the hash of "12345" using an online SHA256 generator works out at "5994471abb01112afcc18159f6cc74b4f511b99806da59b3caf5a9c173cacfc5" the length of the result is fixed in size, it is not a shorter version of the input unless the input is larger than the hash length.

Did you look at the link I previously posted https://en.wikipedia.org/wiki/SHA-2 as that gives a lot more background information.

I think the point is that there are far more combinations of bytes that can be hashed than there are possible hashes so each hash must be able to be generated by more than one original data. That would mean that, in theory, someone could successfully log into your account using a password that doesn't actually match yours but generates the same hash. The likelihood of that other data being something of a length that anyone would use as a password is so small as to be basically negligible though. If the entire text of War & Peace hashed to the same result as your password, I don't think anyone will be using that to log in.

[Sitten Spynne]

Keep in mind most of cryptography/computer security is not "make it impossible to break". Most of it is "make it really hard to break".

If you have a sufficiently long password, even with a farm of machines designed to crack hashes, you'd expect it to take several years to reverse your hash. That's why salt helps: it makes EACH password in the database "sufficiently long" plus "cannot reuse the previous results".

On the other hand, some hash spaces (like MD5) are small enough, attackers have generated a table that has a collision for every possible hash value. That's why MD5 is completely broken, not recommended, and illegal in some cases. One day, SHA256 will be broken like this. We'll just move to a "bigger" hash space and start over when that happens.

No hash is uncrackable. We just like to use ones that have a strong probability finding a collision takes 10+ years even with dedicated hardware.

[DEXWERX]

I was trying to elevate the the discussion by mentioning Rfc2898DeriveBytes.

SHA-1 may be considered cryptographically weak or broken, but in the context of File Hashing and Password hashing as implemented by Rfc2898DeriveBytes it is still viable.

https://security.stackexchange.com/q...96/31871#31871

SHA-1 as used Rfc2898DeriveBytes, also takes a work/iterations argument which changes the computation time.

More info on PBKDF2 / Rfc2898DeriveBytes https://en.wikipedia.org/wiki/PBKDF2

[GBeats]

Hi guys

There is a whole host of information on this thread as well as a whole host of different arguments and ideas......

i have actually found what i think works for my current situation and because of that ill just close the thread (or resolve it)....

but i think that anyone else who stumbbles on the thread will have enough information now to at least be aware of the ins and outs of various techniques etc...

thanks for your help everyone..