-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Challenge-Response Authentication for Dummys -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To often, I see hackers design systems that need security, but they send passwords out as cleartext. Generally, secure authentication is thought to be difficult to do, and often not worth the trouble. However, in our networked world, secure authentication is vital. Automated password sniffers are not only theoretically possible, but doubtlessly already in common use on large, high-bandwidth routers and NAT devices, placed there by hackers or crooked network admins. Ideally, all network communication should be encrypted, but sometimes this is not necessary, possible, or even legal! In any case, if you do develop some sort of network program that needs authentication devices, and you aren't willing to encrypt all traffic, at least use challenge-response authentication. What is Challenge-Response Authentication? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Challenge-Response Authentication (CRA) is a method for proving your identity over an insecure medium without giving any information out to eavsedroppers that may enable them to identify themselves as you. It should also be noted that CRA is still secure, even if an attacker can modify your messages to the server, although, if you send plain-text messages to the server, and the attacker can still modify THAT, the attacker will just wait for you to authenticate, then take over your connection. How does it work? ~~~~~~~~~~~~~~~~~ CRA fundamentally depends on the existance of "one-way hashes". A one-way hash is a function that takes an input, and returns a "hash". Finding the input of the function from the hash is "computationally infeasible", which, in the case of a decent hash function, means you'll be crunching numbers until the next stone age. Popular one-way hash functions are MD4, MD5, SHA, and RIPE-MD. Let's call this one-way function h(). When the client connects to the server, the server makes up a random value, X. The server sends X to the client. The client sends the server h(X+P), where P is the password. The servers computes h(X+P) as well, and checks to see if the data from the client matches the computed value. If so, the client must know P. A practical example: This example uses the common unix utility "md5sum", which hashes the data on stdin to a 128 bit hash, displayed as 32 hex digits. This example also substitutes concatenation for addition. Assume the password is "mysecretpass" and both the client and the server know this. The client connects to the server. The server makes up some random data, say "sldkfjdslfkjweifj". The server sends this data to client. The client concatenates the random data with the password, resulting in "sldkfjdslfkjweifjmysecretpass" The client computes the MD5 hash of this value: 5>doug@saturn:/home/doug$ echo sldkfjdslfkjweifjmysecretpass | md5sum 4fab7ebffd7ef35d88494edb647bac37 5>doug@saturn:/home/doug$ The client sends "4fab7ebffd7ef35d88494edb647bac37" to the server. The server runs the same command, and since the server (hopefully) got the same result, it lets the user in. How does this provide security? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Well, notice how that the password is never actually sent out in the clear, and how in order for an attacker to determine the password would be to bruteforce the hash function: a daunting task. Miscellaneous Info ~~~~~~~~~~~~~~~~~~ You understand why this method is called Challenge-Response Authentication now, don't you? No? Well, I suppose this is a for dummies book after all... Notice how the server "challenges" the client and it "responds". A potential weakness in CRA is if the server sends out the same challenge more than once, an attacker who recorded the hash of the first authentication can simply replay the hash, gaining access without even knowing the password. This is easily solved by making the random data large enough to minimize the odds of such an event as much as you want. Even with 16 random ASCII characters of data the odds of this happening are 1 in 340282366920938463463374607431768211456. Actually, a one-way hash need not be used if you have access to an encryption function. Just use the encryption function in place of the hash function. Of course, one more piece of information needs to be kept secret: The key to the encryption function. May as well just encrypt all traffic, if possible. One interesting application of CRA is in packet radio. There are 2 reasons why encrypting the traffic isn't ideal for this medium. Often, packet radio devices are ancient machines barely even capable of conducting serial communications (my dad still uses a Tandy t-100!), and don't nearly have the processing power to handle a stream of encrypted data, but could manage a hash at the beginning of a conversation, or the operator could even have a hashing program on his palmtop or whatnot. Secondly, the CRTC has stipulated that amateur radio operators use no ciphers whatsoever when transmitting on the airwaves, and this includes packet radio. Now I'm not sure if one-way hashes are considered ciphers, so it's a bit of a grey area... I hope I get some ma1lz from the CRTC. Cease and desist. That'd be sweet. Ah yes, speaking of palmtop hashing programs, none exist that I know of. Any palm c0d0rz looking for something to do: This would be a very cool program. Try porting md5sum to the palmtop. You'll probably want to use RSA's md5sum.c reference implementation as it is much less complicated than the version your unix system uses. For a copy of this, and a usage example, (and a pretty neat program if I do say so myself), see my program coinflip: http://www.hcsw.org/downloads/coinflip-1.1.tgz Fractal HardSoft CoreWare www.hcsw.org Shouts ~~~~~~ theclone - Don't take IBM's k-1ine buyout offer!! phlux - You give shouts, you get shouts. :) rt, magma, cyb, everyone on #hackcanada Special thanks to GOBBLES (haha you're a retard)