Storing Passwords Versus Hashes in Challenge-Response Authentication

I'll add that no-one should store the PT, for a system to work storing the hash is better than the PT obviously. My article explains why and how some hashes are more expensive for an attacker, and even are setup to combat specialized hardware, the PT makes no sense to STORE, it should only be input when needed, and only to memory, never written to disk or stored. Accept PT as input, then hash it, then use Challenge-Response, against another hash that is stored.
-rich

Coincidentally enough, I just found out who Schneier is last night while surfing YouTube. What are the odds?

P.S.

I briefly scanned through your article just now. I think it will make for an interesting read later  = )

Did I hit someone with my gauntlet?

@richrumble, well phrased answer, also your linked article.

Did I hit someone with my gauntlet?

Ha! No, I think it was skullnobrains. My understanding of such authentication was along the same lines:  you store the hash, not the true password. So my first impression of skullnobrain's comment was that it was incorrect. But to give the benefit of the doubt, I wanted to open a thread dedicated solely to discussing that topic (since the original question wasn't concerned with this issue). I wanted to have a friendly discourse on the topic in the hopes that I might learn something myself  = )

If you know one or the other, the hash and or the plain-text you can still authenticate against challenge response. This is how "pass-the-hash" works, an attacker extracts the hash of the password, and when challenge response prompts, the challenge is put with the hash, and the response is sent, and will be accepted. So even if you don't know the PT pass, if you have the hash, you can still authenticate.
With windows, you pass the pass (see mimikatz, or wce), or use pass-the-hash.
http://en.wikipedia.org/wiki/Pass_the_hash
Both require Admin, well technically you can get hashes by reading HDD's when the OS isn't booted, but ordinarily you use admin/system priv's to get the hashes and or the PT password from memory.
2-factor authentication can thwart both attacks, but in the windows world you don't get to use 2fa when \\ip.ip.ip.ip or using WMI/PowerShell or SMB/CIFS in general.
(See my other articles :)
-rich

@sdstuber

OK, point taken. I have modified the question.

Gentlemen, unless I'm misunderstanding something, you never "pass the hash". You simply store the hash. End-users always remember their passwords, not the hashes. The user sends his password, and the system generates a hash against the supplied data. If it matches what was previously hashed (when the user originally registered), BINGO!; otherwise, "unauthorized."

Storing the hash allows you to effectively keep the password in your database (I use the term generically) without actually having the password itself. The DBA cannot simply "SELECT password..." nor can an attacker who compromises the system do the same. Further, if a user were to pass the hashed value, then that value would be hashed, which would have an astronomical chance (a snowball's chance in...if you prefer) of hashing to its own value.

This of course assumes 1-way hashing. I believe the game changes when you start talking about 2-way (reversible?) hashes.

The only reason I can think of why you'd possibly want to encrypt the hashes is that on the off-chance that your system is compromised, an attacker would have a list of hashes that they could then spend time and resources on trying to reverse engineer--no small feat, as I understand.

OK, I was looking at "pass the hash" from a web perspective, not from a Windows perspective. The above description puts it into a bit better context. I'll follow up with the articles after work tonight.

@skullnobrains, some things are right, others are wrong. Have a look at my articles regarding hashes and encryption, hex/binary storage|representation of a hash makes no difference in strength/time to crack a hash. Substitution ciphers and codes while difficult to decipher, and not typically cracked using popular software, are often much weaker encryption schemes than what is used today. Some still elude us to be sure (panel 4 of the NSA's sculpture), however they aren't typically useful for computers to use.
Vigenere/Cesar ciphers and others are quite weak and very susceptible to frequency analysis attacks.
If anyone has questions about hashes vs encryption vs ciphers vs codes let me know in another Q and I'll follow up.
To ultimately answer this question:
You need the PT pass to be sent when using a Salted hash, you do not need to store it beyond that point, you can send the hash of a password if the hash is being checked against and unsalted hash like those found in the windows SAM or NTDS.dit files, other hashes too can be unsalted, most are. Another good read for everyone:
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
http://arstechnica.com/security/2012/08/passwords-under-assault/
http://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/

-rich

>obviously as well... which is why they are only useful when applied before a hashing algorithm. if for example you store a number of salted md5, (salted by concatenating the salt with the secret beforehand)
Weak is weak, rot-13'ing, shifting, obfuscating again is trivial for a machine to unravel, before after during, security by obscurity we all know doesn't work. I digress.
The point of this thread is however why a PT is needed, specifically to be stored, we've all I think agreed that is not so, the PT does not need to be stored in a CR system. The only time a PT is needed is to check against a hash that is salted on the auth server.
If it's unsalted, then effectively the hash of the PT is the password, and a CR system can re-hash the password hash using the challenge, and compare the result.
With a salted hash, you cannot do a CR against the hash, because the user only knows the PT. The user doesn't get the salt, and shouldn't, so the client can't hash the PT of the user and then apply a challenge because it would be missing the salt. So a salted hash, the client has to send the PT, so the server can apply the salt, and then check, there is no CR checking against a salted hash like there is with non-salted ones.
That does not mean that a CR isn't taking place, but it's not taking place using the password, like SSH in a linux system, the passwords are hashed and salted, ssh first creates encrypted tunnel, and then the PT of the pass is sent to the server for it to add the salt to and then check. The client can't hash it first, because the salt is applied to the plain-text and not the hash. If the salt is applied after the PT is hashed, then you get no benefit from the salt, the salt has to be applied to the PT not a hash of the PT. If you know the hash and you send that to the server, then it applies the salt and the results work, the salt did nothing to shore up the password, it added one operation, and not a very expensive one at that.
</pwd_101>
-rich

Weak is weak, rot-13'ing, shifting, obfuscating again is trivial for a machine to unravel, before after during, security by obscurity we all know doesn't work. I digress.

you are still missing the point, and this is absolutely not related to obfuscation in any way. in the case i mentioned above, knowing that a vigenere is applied will not help the attacker in any way unless if he knows the key. rot13 would be quite foolish indeed. anyway, this is totally beyond the scope of this thread.

The point of this thread is however why a PT is needed, specifically to be stored, we've all I think agreed that is not so, the PT does not need to be stored in a CR system.

agreed, it is not needed to have the PT. it just makes no difference unless the client and server agreed on a shared secret beforehand, since the hash effectively becomes the password.

If it's unsalted, then effectively the hash of the PT is the password, and a CR system can re-hash the password hash using the challenge, and compare the result.

i think i finally get your point. by "salted" you mean that the authentication mechanism will always apply a non-reproductible transformation to the password before checking it against what is stored in the db.

agreed : by definition, this process does not allow challenge-response authentication. we're still stating the obvious

this is precisely why i do not consider that storing "unsalted" hashes rather than passwords makes much of a difference (if at all).

the only way it could not be the case, is if both the client and server side agreed on a shared secret (which you'd probably like to call "salt") beforehand, which is quite beyond the scope of this thread but does allow cr with salted hashes. in that case and that case only is the security improved by storing hashes.

in a linux system, the passwords are hashed and salted

you probably refer to distributions that use shadow-utils (most of them). true but the salts are stored together with the passwords

If the salt is applied after the PT is hashed, then you get no benefit from the salt, the salt has to be applied to the PT not a hash of the PT. If you know the hash and you send that to the server, then it applies the salt and the results work

whatever this means, i do not get it. applying a salt to a hash does not really ring a bell.

btw, ssh does support challengeresponse and multiple other authentication mechanism



it's high time for me to leave this thread

best regards to all

All,

I'll close this out this evening when I have more time to review all of the responses.

Thank you all for your participation. This was very difficult for me to grade, so I spread the love. I appreciate everyone's comments.