Password hashes question

I'm studying for the Sec+ and I have a question about the way password hashes are used. So, the way I understand it is that your password is stored as a hash on a server and when you type in your password it's converted to a hash and compared to the hash that is stored. I know they also have rainbow tables that show what original passwords were given a hash. My question is why can't someone just intercept or get your hash and use it to login to a site, say Amazon for example? Why is the actual password needed when that's not even what is stored? Are hashes not really used? What am I missing?

Find more posts tagged with

Comments

PCTechLinc

I think the only part you're missing is using a Salt. With regular password hashing, you are exactly right... it's "fairly" easy to work out the original password if you have the username and the hashed version of the password. Problem is that rainbow tables get VERY large, and a large amount of processing power is required. If you're using a salt, then you are provided a random "key" that is used in conjunction with the hashed password. However, every time a better way is created to protect the password, there are thousands of unethical people doing whatever they can to break it.

To answer your question about people using the hash to break into an online account, it depends on how you're posing the question. If someone uses the same username and password on multiple sites, then yes, getting their account info from one spot makes it simpler to break in elsewhere. However, to grab the username and hash directly FROM the Amazon site, then you have to crack the SSL/TLS session that Amazon uses to communicate with the end user. Of course, there are ways to do that too.

I hope that gives you a better understanding.

PJ_Sneakers

Here's a quick video about salting that should help.

https://www.youtube.com/watch?v=--tnZMuoK3E

GeekyChick

So the Salt is just an extra protection for the hash that makes sense. I may not be asking this right but why do hackers need the actual password instead of using a password hash to login? Isn't that what the site you are logging into compares against? Why do they even have to go through a rainbow table? Because a hash is not unencrypted. It's not like amazon, for example, unencryptes your hash to compare it to a clear text password. Does that make sense? I sure hope this isn't a dumb question.

636-555-3226

when you type "password" in for your password, amazon hashes that value to see if it matches what's in the database. if 5f4dcc3b5aa765d61d8327deb882cf99 is in the database, you're good

if instead you type in 5f4dcc3b5aa765d61d8327deb882cf99 for your password, amazon will hash that and check to see if 696d29e0940a4957748fe3fc9efd22a3 matches what's in the database. problem is, 696... isn't in the database, 5f4 is.

if amazon was smart enough to see you're submitting the hashed value instead of the password then it would work, but amazon is expecting you to provide them your real password. also, you don't have any idea what hash method amazon is using, so you can't give them the hash of your password anyway. you might submit an md5 hash to them but they're using bcrypt, instead.

PJ_Sneakers

Well, the hash itself cannot be passed through the system for authentication if it is done properly.

For instance, if you entered the hash into the password field of a login page, the hash you typed in would be sent, and then it would get hashed. That would be a different result than the original password.

GeekyChick

Oh, I get it, that makes more sense. The hash happens on the server. Duh. I dont know why I didnt think that.

paul78

GeekyChick wrote: »

I may not be asking this right but why do hackers need the actual password instead of using a password hash to login?

It's probably outside the context of Sec+ but there are attack vectors which do not require the actual password. Some weaker protocols such as NTLM as susceptible to pass-the-hash attacks.

One thing to remember is that the hash algo that is used is also very important. Some algo's were designed at a time when the computational expense was different - MD5 for example is no longer considered adequate for password hashes. I have a rig that can brute force any md5 password up to 6 characters in about 16 minutes. And there exist lookup tables for any md5 hash up to 8 chars floating around.

While a salt is useful in defeating lookup and rainbow tables - if the salt's are compromised as well, a brute-force attack can still be launched which is why using a cryptographically expensive hash is important. When databases containing auth info are compromised, not only is the hash exposed but the salt is often exposed as well.

kurosaki00

GeekyChick wrote: »

So the Salt is just an extra protection for the hash that makes sense.

Salt is a random string that is injected to the HASH.
Its like your password is C1sco = hash = 123456789. Adding salt makes it 998gf + 123456789.
Salt is random, so even with the same hash, the password will be different.

paul78

kurosaki00 wrote: »

Salt is random, so even with the same hash, the password will be different.

I think you meant to type that the other way around. In your example:

Salt is random (ideally crypto secure pseudo-random:D), so with the same password, the hash will be different.

destroy8383

Are you talking about passing the hash?
Here's some insight on that
https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283

GeekyChick

destroy8383 wrote: »

Are you talking about passing the hash?
Here's some insight on that
https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283

Yes, that was exactly what I was thinking. It looks like it's only used against SSO, like Kerberos. That makes sense because it only calculates the hash once and uses it to login to multiple systems. My confusion was that it's only used in that situation. Thanks for the link.

@paul78 mentioned the pass-the-hash too. Thanks!

Nik 99

This thread was well worth reading. I'm also studying for my security+ and this one confused me too. I figured all an attacker would have to do was intercept the hash and use it themselves to gain access. Makes so much more sense that the hashing is done on the server end and that trying to enter a hashed password would generate an altogether different hash.

I've got another hash related question though. From what I remember reading, CHAP and MS-CHAP do not send passwords/credentials as cleartext, instead they hash the passwords first then send it off. There must be more to the explaination because this suffers the same problem of an attacker using the intercepted hash to login. Can someone explain this one to me?

PCTechLinc

Nik 99 wrote: »

This thread was well worth reading. I'm also studying for my security+ and this one confused me too. I figured all an attacker would have to do was intercept the hash and use it themselves to gain access. Makes so much more sense that the hashing is done on the server end and that trying to enter a hashed password would generate an altogether different hash.

I've got another hash related question though. From what I remember reading, CHAP and MS-CHAP do not send passwords/credentials as cleartext, instead they hash the passwords first then send it off. There must be more to the explaination because this suffers the same problem of an attacker using the intercepted hash to login. Can someone explain this one to me?

You are pretty much correct that it is still easy for an attacker to intercept the hash. That is why there are better ways to authenticate users, specifically by using EAP (Extensible Authentication Protocol) and using certificates. Back in the hayday, security researchers were still trying to figure out the most secure way to exchange information. Comparing MS-CHAPv1 to MS-CHAPv2 however, there are extra mechanisms that protect the sent hash. The technical differences between the different protocols are explained here:

https://technet.microsoft.com/en-us/library/cc957973.aspx

Note these two points excerpted from that page:

"Separate cryptographic keys are generated for transmitted and received data.

The cryptographic keys are based on the user's password and the arbitrary challenge string. Each time the user connects with the same password, a different cryptographic key is used."

Nik 99

Thanks for your answer to that. That makes more sense now. So the hashed password still needs to be encrypted for there to be any real security in place.

[Deleted User]

Yes and no. For logging into Amazon or a web service no. However, let's say you managed to get a hold of LM or NTLM hashes. Not a SHA1 or MD5 hash but LM or NTLM used for Windows to store passwords via SAM database. You could (via psexec in metasploit or pth-win.exe) use a technique called Pass the hash via a protocol such as SMB. So to answer your question, yes and no. Read here for more info from SANS. Best of luck for Security+

https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283

TechGromit

GeekyChick wrote: »

My question is why can't someone just intercept or get your hash and use it to login to a site, say Amazon for example? Why is the actual password needed when that's not even what is stored? Are hashes not really used? What am I missing?

Actually there is a type of attack called a Replay or Playback attack where they do record the password/hash as you logging into the server. It needs to be recorded at the exact time authentication occurs, and the attacker has to guess the correct session id number to eavesdrop for the attack to be successful. Not easy to do, but if successful, they do not need to know your password, they just replay the recorded hash and they can access the server as it was you.

gespenstern

paul78 wrote: »

It's probably outside the context of Sec+ but there are attack vectors which do not require the actual password. Some weaker protocols such as NTLM as susceptible to pass-the-hash attacks.

Actually, not really or at least not a good illustration.

On the wire either NTLMv1 or NTLMv2 structure (which is a hash of a hash and a challenge) is protected against intercepting and replaying it, so you can't use the captured hash as authentication token by replaying it later. This is a feature of any challenge-response protocol.

Good example illustrating the thesis would be some earlier protocol, such as some protocols that were used in remote car door openers or remote garage door openers before everybody started using challenge-response protocols.

As for pass-the-hash it is a result of a necessity to produce a value of an expected size out of a random length user password and MS uses MD4 to hash the passwords (and LM-hash earlier) and stores them in both NTDS and SAM up to this date (which is known as NT-hash or sometimes, I say, erroneously as NTLM hash), it's not something you can intercept and replay. What you can capture, again, is a hash of a hash and a challenge, on-the-wire NTLMv1 or NTLMv2 structures are called NetNTLMv1 or NetNTLMv2 among hashcat users. NT-hash is just a password equivalent here, used for the purpose of making sure that the code used for calculations is of the same size no matter what size actual password is.

More on this here: https://msdn.microsoft.com/en-us/library/cc236699.aspx

If you are arguing that NTLM is weaker than Kerberos, then you can't argue that it is weaker in this particular regard, as MS version of Kerberos relies on MD4 hashes as well and it's not required to know the password to craft a Kerberos pre-authentication request, all you have to know is MD4 (=NT-hash) of user's password.

paul78

gespenstern wrote: »

More on this here: https://msdn.microsoft.com/en-us/library/cc236699.aspx

Interesting read - thanks for the link. There's always something great to learn on TE.

GeekyChick

gespenstern wrote: »

More on this here: https://msdn.microsoft.com/en-us/library/cc236699.aspx

.

I may be able to understand that in a few years.