Path: suburbia!proff Date: 27 May 94 09:34:24 GMT Message-ID: Newsgroups: alt.security,comp.security.unix,comp.security.misc,sci.crypt,comp.risks,apana.general Subject: "Chalace" challenge/response sniffer/tap proof password system. Summary: Announcing Chalace 0.10 suburbia.apana.org.au:/pub/proff/hidleho+chalace/* Keywords: password,security,tap,sniffer,sniff,authentification,md5 "Chalace" is a intercept proof password authentification system which can be used over normal communications channels. Chalace is very, very portable, being for the most part pure ANSI-C. However it will not run on a terminal, or calculator alone. You must have secure access to a LOCAL machine in order to run the response client. In an ideal world, everyone would be running something like kerberos - however kerberos is not very portable or, exportable, and runs only over TCP/IP style connections. Chalace is useful under many circumstances and not at all useful under others. Useful for: Connecting from a local (or considered secure) machine to a remote machine over a possibly insecure communications line, without giving any intercepting agents access to your account authentification information (password) and thus your account itself. Not useful for: Protecting the data that is actually transferred from the remote machine, Connection from a dumb terminal, etc where no computer is nearby to run the Chalace client. Chalace can be obtained from suburbia.apana.org.au:/pub/proff/chalace+hidleho/ Below is some brief documentation of some relevance. Note that you do NOT need to run "hidleho" to use Chalace, it just happens to be what I use for the Chalace server. - Julian. ps. You can test out your clients for conformity by connecting to "suburbia.apana.org.au" and logging in as user "chaltest", with the secret "chalace secret". <"chalace.doc"> Some VERY BRIEF docs. All code remains (c) 1993, 1994 Julian P. Assange. Chalace is a challenge - response system based on shared non-disclosed secrets. Chalace key authentification and exchange is not vulnerable to eaves-dropping, tapping, packet-sniffing and the like, as the secret is never sent as plain text though any communications channel. Say we have the caller "bob" and the called party "Alice" (Alice is of course, generally speaking a computer accepting remote logins). At sometime in the past, bob has given Alice a secret over a trusted communications channel (trust being relative of course), now one day bob wants to prove to Alice that he really is bob over a possibly intercepted communications channel without divulging any information about the shared secret - as if such information was divulged, Alice could no longer tell when bob called if he was really bob (current problem with plaintext transmission of password). The chalace secret exchange for bob and Alice would look something like this: Bob Alice --- ---- Generates cryptographically secure random number. <-number sent to bob<- performs a secure hash of number and his secret. ->Secure hash-> Generates secure hash of number and secret, and compares it to result send by bob. IF result is the same, then bob must have the same secret as Alice. Therefor, bob IS bob. Example: (clients perspective) Enter challenge: visit defile Suelette Response = urban curve angel Implementation: A 32bit random number is generated by doing an interactive md5 secure hash of a large number of time and system stats. All information is represented by three words from a table of 2048. For non-automated key exchange this makes the information considerably easier to remember than other commercial systems that use an 8-digit number. The 128bit secure hash of secret and random number is broken down into 32bits then wordified for the response. Limitations: At present the server is only implemented as a simple stand alone program, or as part of Hidleho. However the code is VERY PORTABLE and should be child's play to patch into login(1) ftpd, su, etc. You MUST make sure that all daemons, etc are either patched or disable, there is NO point in just patching login(1) and leaving ftpd, etc wide open. Please see "hidleho.doc" for more information concerning this, and other matters. Vulnerabilities: Though secret space is very large, effective key-space is only 2^32. Assuming that n of bobs logins were intercepted, a challenge/response relational pair table could be constructed so that at each challenge, an attacker would have a 2^32/n chance of being able to find the correct response. e.g if n=1000, the chance per challenge that the attacker can beat the system is 1/4,294,967. This could be considered a problem if the implementation allows many invalid responses, and can process them quickly. If paranoia level security is desired, then just perform a double challenge, which beings the key-space up-to 2^64. <"hidleho.doc"> /* (c) 1993, 1994 Julian Assage (proff@suburbia.apana.org.au) all rights reserved. This software may only be used freely by non-profit non-governmental non-comercial organizations. If your not in this category then you MUST purchase a site license from me. Write to the above address for more information. */ #define VERSION "0.97" # Some VERY BRIEF docs. This is ALPHA software, not intended for distribution, use at own risk. All code remains (c) 1993, 1994 Julian P. Assange. /etc/hidleho.cnf is fairly self documenting. Adapt it to your system. the "hidleho.tar.gz" archive should be extracted in /. Study "passwd_e.g" and create at the least a like "hidleho" entry. chown -R hidleho /usr/hidleho . /usr/hidleho/* should be world-readable and dirs enterable. user/group dirs are AUTOMATICALLY created when users login. group dirs are created and interperated ONLY for the users main group, not the users subsidiary groups, however /etc/hidleho.cnf works with subsidiary groups as well. Modify the shells of all users to be /bin/hidleho and put the original shell in /etc/hidleho.cnf in whatever way you see fit. If TimePer is 0 and TimeLim>0 then that users time runs is "one-shot" mode. If TimeLim is 0 then time is based on time per call. If TimeLim & TimePer >0 then users tiem starts ar TimeLim and is replenished continuously in proportion to TimePer and TimeLim. /usr/hidleho/default:/ is valid for all users and groups. /bin/sh must have the "." command. /etc/hutmp should exist and be owned by "hidleho". in the per-user and per-group dirs one can have the following files: nologin - user/group is refused login and file is displayed login - file is sourced through sh before execing the shell lastlogin - user/group last login details lastlogout - usr/group last logout details. timeleft - time remaining for user numlogins - user/group total number of logins totaltime - user/group total time ever used. permitdeny - user/group hostname / tty / localhostname / ip address patterned matched acceptance or exclusions. All applicable group/user permitdeny files are treated as a single concatenated permit/deny list - thus a user include can override a group exclude. example patterns: -*.edu exclude all edu -/dev/ttyS? exclude all dialups joe accept host joe ttyp? accept psuedo ttys -ttyp0 except ttyp0 secret - user/group 1-79 char Chalace secret. Activates chalace authentification. In the users home directory: .hushlogin - disables hidleho information and messages .secret - as above "secret", but doesn't over-ride above if both present .permitdeny - as above "permitdeny" but checked only if cleared. You must have a version of login which places the IP address in /etc/utmp to correctly use hidleho. If your version doesn't, try the shadow3.1.1+ version. rsh ftp and su currently do not obey permitdeny or chalace authentification. We get around this by being harsh with access restrictions. i.e /bin/hidleho is not placed in /etc/shells, /bin/su is : -r-sr-x--- 1 root staff 21508 May 18 17:33 /bin/su The hidleho.cnf flag "k" will not work correctly if /bin/fuser is not present. /bin/hidleho MUST be setuid root, and the user "hidleho" must be present in /etc/passwd and own the /usr/hidleho/* files. Remember the 'K' flag kills ALL tasks owned by that user system wide- unless the user is root when the user logs out. As I said. BRIEF DOCS. If you want flashy auto-installing man pages and source or ports to another platform/Unix or bug fixes/customisation you got it if you pay me, and my rates are reasonable. Proff