thettyofGeoffreyS.Goodfellow@BRL.ARPA (06/29/83)
A real easy way of "hacking names" on a host is to just connect up with TELNET and do a SYSTAT or FINGER. Big Deal. A gourmet "name hacker" would use the NIC's informative "WHOIS" Server. Just give the name of your favorite host preceded with a star `*' (i.e. try `*brl' for example) and a nicely formatted list, replete with full name, initials(nic id), mailbox and phone number will promptly be displayed. Happy Hacking.
greep%su-dsn@sri-unix.UUCP (06/29/83)
Other tactics include looking in the Arpanet directory or just trying common names. In addition, many Unix sites have a "who" login that runs the "who" or "finger" program, and most tops-20 sites let you run "finger" or "systat" without being logged in. In fact, you can (at least with some dec-20's) run finger with a null argument and get a list of every user (not just those logged in). It is generally agreed that keeping user names secret is not a reasonable thing to do -- that's what passwords are for.
EE.GDS%MIT-OZ%mit-mc@sri-unix.UUCP (06/30/83)
From: Greg Skinner <EE.GDS%MIT-OZ@mit-mc> There is another way to hack user logins -- just wander around the Arpanet looking for a user named "smith" or "jones" who has an account with no password. I know instances of this happening with Unix machines -- in fact, when the TCP/IP switchover took place the users on our internet vaxes were required to give themselves passwords, or a password was chosen for them different from their name. Actually, if the host has a finger server, you could try all logged-in users looking for a non-password account. Also, some users stupidly have login and password names the same. This happens often when accounts are newly created and the user is not present at the creation time. The operator makes the username and password names the same. As far as I know, non-password accounts are allowed on Unix, and not on TOPS-20. --greg -------
chris@umcp-cs.UUCP (07/01/83)
From: Greg Skinner <EE.GDS%MIT-OZ@mit-mc>
Some users stupidly have login and password names the same.
This happens often when accounts are newly created and the user
is not present at the creation time.
If any sites would like to fix that, I have a program called
``newacct'' which is intended to be run by the user getting the
account. It reads the login name, full name, passwd, etc, and
constructs a mail message (to "mark", but that's a #define) with a
nicely complete passwd file entry. No one ever gets to actually see
the pasword typed; once the password has been accepted the encrypted
one is displayed. It even has a verfiy-password procedure (which
currently just checks the length of the password). It uses my windows
library, which I'm starting to send to net.sources (I sent
documentation early this morning). With a small modification to the
password-verifier you'd have a ``secure'' system. ('A course, ya still
need to change the password-change-program.)
If you want newacct, send me mail. If enough people want it I'll post
it to net.sources.
- Chris
--
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs
ARPA: chris.umcp-cs@UDel-RelayFFM%mit-mc@sri-unix.UUCP (07/01/83)
From: Steve Kudlak <FFM@mit-mc> There are lots of hacks like this one. The legendary, excuse the language, <<FUCK SUSAN BOB>>. Guessing female names is supposedly good on some sites, and some commercial places whose names will remain unmetioned have WHEELED accounts that still have the DEFAULT DEC PASSWORD.
steve%ucl-cs@sri-unix.UUCP (07/01/83)
From: Steve Kille <steve@ucl-cs> There seems to be a definite argument here for separating login name and mail address (as happens on some sites I know of). Steve
MRC@SU-SCORE.ARPA (07/05/83)
From: Mark Crispin <MRC@SU-SCORE.ARPA>
One thing you could do would be to not validate mailboxes in the
SMTP server, but that only delays the error message unless you "black
hole" mail to invalid mailboxes. It's a trade-off between security and
friendliness.
-------msggroup-request%brl@sri-unix.UUCP (07/05/83)
From: Einar Stefferud <msggroup-request@brl> I can see how you connect this question to MsgGroup because of the involvement of SMTP, or mailing lists. But, of course there are lots of other non-mail ways to get login names on most any host. So, I don't think this is a mail system issue after all, beyond your accurate initial observations. So, rather than trying to shut down the ability to extract login names from mail servers, I think attention should be focused on other security techniques. Like, making the penalty higher for failing to login correctly, and making the user start over at the beginning of the whole process when an error occurs before completion. One thing to do is force a delay following any failure, like an extra 5 or 10 seconds, which slows down the hacking rate to less than 6 tries per minute. Then, I think that too many failures in a row should cause a disconnect, which further slows down serious password hackers. Seems to me that it is too easy to put obstacles in the way to let ourselves get sidetracked into trying to conceal names. Whither goest the whole idea of name-servers if we try to close the mail gap? So, lets just chase this issue back to the other lists, unless a more genuine mail connection can be conjured up. Cheers - Stef
JPAYNE@BBNG.ARPA (07/05/83)
From: Greg Skinner <EE.GDS%MIT-OZ@mit-mc> Some users stupidly have login and password names the same. This happens often when accounts are newly created and the user is not present at the creation time. At LSRHS we have an account called new which runs the program newu. Newu asks for login name, a password which has to pass the same tests as the change passwd program, Real name, birthday, Hall, Year of Graduation, and of course a password for the account. It then adds a new entry into the passwd file, and in another file, the inquir file. The new account can't be used until it is validated with the validate program. This is a nice easy way to create accounts with SECURE passwds. Jonathan