NS-DDN@DDN2.UUCP.UUCP (01/11/87)
I heard of a fascinating alternative to standard access validation which may be right up your alley. Instead of a password, the user is presented with five random numbers and asked to compute the result using his secret access validation algorithm. Traces and taps will only show a plaintext response to the specific access request. The algorithm is not apparent unless many accesses are traced and analyzed. A good algorithm mechanism would support conditionals; e.g., If 3rd number is odd, then result is 4th number minus 5th number, else result is 1st number times 1st number plus 2nd number. While this is complex, it avoids the overhead of DES (I shudder to think what that would do to the ACP's resource consumption). The ICT ACACCESS module (invoked via the PACCESS macro) is not designed to work this way since it assumes it is merely interfacing to an MVS security package which is password-driven. Worse still, the commutator is not party to TCP and VTAM sessions; hence, it cannot solicit the userid, prompt for the result, and capture the result. Consequently, implementation of this idea cannot be easily be centralized within the PACCESS service. There is no standard routine for solicitation of the userid/password. I would suggest adding an A-service to provide a common solicitor routine which would be knowledgeable of both TELNET and VTAM connections to deal with each appropriately. Then modify the modules which obtain this information to use the A-service instead. Another problem with this would be the creation of an access table containing each user's id, privileges, and algorithm. This should be part of ACACCESS. PACCESS and ACACCESS would have to modified to expect six numbers (the prompted five and the user's response) instead of the existing eight-byte password. Be very careful with enhancements to the commutator! While this is not a trivial enhancement, I believe it would serve your needs (and maybe ours, as well). Best regards, Dave Craig Network Solutions, Inc.
ron@BRL.ARPA (Ron Natalie) (01/12/87)
Of course the problem with this is that the users who are likely to be using a Unversity Administration system aren't likely to be able to deal with too hard an algorithm and a Ethernet wiretapper probably could deduce it over a period of time. The only way I can think of getting around it is to use a PC or some other semi-smart device as the user terminal and encrypt some or all of the authentication information. It's really the same idea, except that the terminal has most of the smart algorithm in it, the user just has some key. -Ron
Richard_S._Conto@UM.CC.UMICH.EDU.UUCP (01/13/87)
In the message ( Message-Id: <8701121034.aa13795@SEM.BRL.ARPA>) of Mon, 12 Jan 87, Ron Natalie (<ron@BRL.ARPA>) suggests: > ... The only way I can think of >getting around it is to use a PC or some other semi-smart device as >the user terminal and encrypt some or all of the authentication information. >It's really the same idea, except that the terminal has most of the smart >algorithm in it, the user just has some key. Is this really 'safe'? If you're really so terribly worried about the privacy and the secure validation (which I'd like to consider as seperate, though linked issues), then doesn't this end also need to be secure? I can see specialized hardware possibly being secure, but a program that resides on a PC can be easily duplicated. In fact, with one person borrowing another's copy to get some work done quickly, it would soon seem to loose any real security at all and just become a nuisance. --- Richard ARPA Richard_S._Conto@um.cc.umich.edu USnail Richard S. Conto Computing Center 1075 Beal Ave. University of Michigan Ann Arbor, Mi. 48109 "It's too early in the day to be cute and funny."
ron@BRL.ARPA.UUCP (01/14/87)
Yes, last I heard DARCOM (er, AMC) headquarters was contemplating such a system. I haven't heard if it has been installed yet. -Ron
ron@BRL.ARPA (Ron Natalie) (01/15/87)
Well, any point of the system where the data is going to exist unencrypted is going to have to be secured. But consider the original application. He was concerned about ethernet spies grabbing the passwords and such off the wire. You can do this even if the spy has a copy of your encryption program. Many people have the UNIX password crypt routine, but as of yet no one has announced a way to use it to decrypt totally random passwords (other than by exhaustive search, which even on our X/MP-48 takes a long time...it does vectorize nicely though :-)). Consider the following scenario... A BIG SECURE UNIVERSITY ADMINISTRATIVE COMPUTER named I'm Big Money An IBM PC in the Bursars Office named Petty Cash and the campus ethernet spine with the above plus random PC's and SUNs on it called "RU-YELLOW" Petty Cash: I'd like to talk to Big Bucks ( now big brother makes up a verification string of random letters) I'm Big Money: Encrypt "AWALKER" for me using your password as key. (PC now encrypts the random phrase with the user's password "TUITION") PC: The encrypted string is "*HOBBIT*". (IBM now encrypts "AWALKER" with the user's passord "TUITION" and sees that they match and allows access.) IBM: OK PC...what shall we do today? See at no time did the user's password "TUITION" ever exist in the clear. The Spy, seeing the random string and the encrypted answer can not deduce the password. He can't use the encrypted answer because next time IBM will send a different string. It makes no difference here whether or not he has a copy of the program running in PC or not. Of course, he can probably get all kinds of juicy data if the transactions are not encrypted as the authentication was. In addition, there is always the chance that the spy can infiltrate either end (like by modifying the software in the PC to also keep track of the cleartext passwords). -Ron