UGN Security Forums UGN Security: Knowledge Base Programming Web Design, Protocols & Other Languages CHAP (Challege Handshake Authentication Protocol)

Ok. I was studying for Security+ and read about CHAP. It was a replacement for PAP b/c PAP sent passwords in plain-text.

So I have some questions about the actual level of security/benefits of CHAP.

First, here is how I understand CHAP works.

• Client connects and logs in with username
• Server will find UID for username and then find the associated secret (password)
• Server then uses a challenge (string) and sends it to the client
• Client receives the challenge and encrypts it using the password entered by user
• This creates a hash which is then sent to the server
• Server uses the password stored at its location, and generates a hash also
• Server checks its hash w/ clients hash
• Match results in authentication success sent to client, or if no match, the authentication fails

PROS:
Unlike PAP, password not sent in plain-text
Other methods send encrypted, but with CHAP the password isn't even sent encrypted, its a modified hash using challenge.

CONS:
Even though this prevents replay, what is the point of taking it a step further and using a challenge w/ password to create a hash. Doesn't this just mean rather than grabbing a single hash, the hacker must sniff hash/challenge.

Local storage of passwords must be in plain text to allow the ability to hash each session.

-+-+-+-+-+-+-+-+-+-+-+
How does this really provide any benefit over the normal method of sending an encrypted password? And isn't the plaintext storage a larger security risk then sending over an encrypted password like normally done?
-+-+-+-+-+-+-+-+-+-+-+

There is something you're missing I think. If a client sends a plain encrypted password to the server for authentication (however the server chooses to do it) what is stopping a sniffer from using the exact same byte stream? Who needs to know the password when all you need to do is send the encrypted form? It's practically as insecure as sending the password plain-text.

So they seek to make it more secure by using the challenge to be included in the hash so that randomized challenges may prevent sniffers from reusing the hash sent for authentication. It does not matter if the sniffer SEES the challenge, cause the challenge SHOULD change every time it is sent.

That is a fairly secure system.

You are right though about the password having to be stored locally in plain text. That is... if it isn't encrypted using a key and therefor must be decrypted before each hashing. The protocol has no control over how the password is stored - the protocol is secure. It is the local computer's responsibility for local security.

Heh, finally got around to posting in this topic.

For a reeally good breakdown on how chap works check out this link:

http://www.cisco.com/warp/public/471/understanding_ppp_chap.html

As another note, you can encrypt passwords on a cisco router to be used in authentication. Now, I've done some looking around and what I see is two things.

1. You cannot encrypt passwords for use with CHAP

2. The command 'service password-encryption' will encrypt all the passwords on the router.

But nowhere have I seen anything that says these two rules aren't compatible. I looked on the router to see what it had to say about the command. Here's the output if you are interested:
The command we are interested here is 'service password-encryption'. I dunno, just threw this in cause I know you can encrypt the password, I just need to verify that when you do CHAP will fail.

And that's my two cents.

Infinite

While i was studying on my CCNA academy, we had PAP and CHAP on the 4th semester, and in the final exam there were lots of questions bout em. CHAP is realy more secure but i don't wanna go through details coz SR already explained clearly. Although i dunno but i have this feeling that still PAP is more widely used then CHAP...

bp

some points about chap:

it can still be compromised. it is more secure than pap? of course. but is it trustworthy? hardly. but once again, not primarily in the structure of it, but mostly b/c of the crapiness of the LM hash algorithm. anyway, l0phtcrack for example, will sniff for smb authentication attempts. it'll capture the challenge and the users hash (which was encrypted using the challenge) what it'll then do, is try to crack it by encrypting the challenge w/ random strings until it matches the users hash.

but, b/c, like sr said, chap uses random challenges, it'd be impossible to use the hash instead of just using the password. however, it is still possible to use the hash to gain privelages on only a local system (i believe). basically, if you're logged in as a user, and say, have an administrators hash. you could write a program (as i dont' believe there are any available) which'll edit the lsass values stored in memory to change your credentials.

that's all i got for now.//

Gollum, your post confuses me.

I thought chap uses MD5, but I might be wrong. I'll look it up after I finish this post :p

What does SMB have to do with CHAP? This is a totally unrelated protocol, and I'll cover that more below.

Well of course sending the password won't work, CHAP by definition does not ever put a password on the wire.

And this is where you totally lost me. CHAP is an authentication protocol used between peers during the negotion of a PPP link (primarily). For example, one router wishing to establish a PPP link with an adjoining router could have to respond to CHAP authentication challenge from the router it is requesting the link from. Or when you dial up a modem connection the same thing would occur. CHAP has absolutely no use locally. You don't use it to login, access, or otherwise gain priviledged access to a machine you are in front of. I totally don't get where you are coming from here.

That just makes no sense to me. The reasons should be clear now.


*edit*
CHAP requires the use of an 'one-way hash' function to operate. The type of hash does not matter as long as both ends are using the same type. This is all the rfc says about it:

Infinite

http://www.securityfocus.com/guest/1512 - that should explain most of it.

when i said "local system" i also added "(i believe)" indicating i wasn't 100% sure.

and:
"What does SMB have to do with CHAP? This is a totally unrelated protocol, and I'll cover that more below."

SMB is a client server, request-response protocol.
CHAP is an authentication protocol.

while it is true they are not directly related, both are used when you authenticate a user trying to log into shares on a system that uses chap.
therefore, when you sniff smb sessions, you will also pick up the challenge handshake.

as for:

"'but, b/c, like sr said, chap uses random challenges, it'd be impossible to use the hash instead of just using the password. however'

Well of course sending the password won't work, CHAP by definition does not ever put a password on the wire."

i actually meant to say: "...it'd be impossible to use the hash like you would use a password." in other words: the hash isn't a key, unlike a password, it's random every time.

and then:

"I thought chap uses MD5, but I might be wrong. I'll look it up after I finish this post"

http://www.informatik.tu-darmstadt.de/BS/Pagnia/AKSC/NT_passw.html

but more specifically(from the above link):

3. When MS had the chance to do things a different way (ie Network challenge/response obfuscation on NT boxes) they implemented it based upon LM techniques to break up components

basically, i do belive that they use md5 (or 4?) in the nt hash algorithm. but, it won't use that unless the machine is an nt machine.

"The LM hash is incredibly weak and your more secure NT hash is brought down to the lowest common denominator. Thus, the challenge response is completely brute-forcable for the LM-hash. MS made the "oversight" of still sending the LM-hash response along with the NT response even when SP3 was installed. "

i'm not an expert on this, but i do believe that is correct.
//