At 09:58 PM 9/27/95 -0700, you wrote:
For two programs communicating via TCP/IP and exchanging authentication information, I want to make sure that the authentication info, (user's name and password,) doesn't pass in the clear. I can think of a few ways to handle this.
1) Encrypt via shared key using symetric encryption. This works but key management is a problem. 2) Encrypt via public keys using public key encryption. There's licensing issues, and how do you generate public and private pairs for all of the programs? That could be a lot of primes! 3) The "server" could keep user names and passwords stored as hashed values. That way the "client" could do a hash (MD5?) before sending it. This has the drawback of the server not having access to the unhashed values...if it needs that access this method won't work.
[Perry Metzger often has good comments about the order of doing things in.] Are you planning to encrypt your sessions, or not? What threats are you worried about? What threats are you aware of but not worried about? How much opportunity do the users of the programs have to set up communications beforehand? Is this one-shot, or will a given client and server do a lot of repeat business? Are you concerned about privacy from machine to machine, or also from user to user? Are you worried about man-in-the-middle attacks? Are you worried about protecting the user's name, or only their password? Are you willing to buy hardware, or do you want software-only? How critical is setup speed? How slow are your processors? Are you worried about your TCP sessions getting hijacked once you've done the authentication? For some applications, Diffie-Hellman is a good answer - the basic protocol doesn't do authentication, but does do secure key negotiation as long as you either don't have a man-in-the-middle or else have authentication such as digital signatures on your key-parts. Once you've created a shared key by DH, you can then use it to encrypt your session, or at least exchange passwords securely. If you're willing to buy a bit of hardware, there are cryptographic smartcards that let you generate time-varying one-time passwords; some of them are decent. Phil Karn's S/Key technology (ftp-able from and I think patented by Bellcore) takes a nice approach using hash functions - let h^n(m) denote message m cranked through hash function h n times, = h(h(h(...(h(m))...))), where h is a secure one-way hash like MD4 that's tolerably fast. To set up, calculate h^n(m), and store it in the server's password file. When you log in for the first time, the server tells you n-1, you calculate h^(n-1)(m), send it as your password, the server hashes it to get h^n(m), and compares it with the saved value. If it works, the server now saves h^(n-1)(m); the next time it'll ask you for n-2, you give it h^(n-2)(m), the server hashes to get h^(n-1)(m), etc. Obviously you've got to reset after n-1 uses. If you have an environment where you can store secret keys safely on the server, you can use secret-key challenge-response methods effectively - the server sends a random number, and you send back the number, encrypted, or there are variants where you modify the number by 1, with or without timestamps, and maybe the server sends the number encrypted also. If you can't secure a general-use machine, but are able to secure a machine that just does authentication and keep it locked in a room with only network access and power, pretty soon you've invented Kerberos. Do you need separate public keys for each application X user? Depending on what you're trying to authenticate, you could have a public key for the application or even just the machine it runs on, and send passwords encrypted with that; again there are variants with timestamps, random challenges, etc., to deal with issues like replay attacks. Or maybe you can have the server issue random numbers as challenges that you sign with your registered public key. If you do that, though, better have the server sign with _its_ public key also, since you'd probably rather not just go signing any random number anybody hands you. And what if there's a man in the middle there helping you log on...? #--- # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---