MARSELLE%gmr.com@RELAY.CS.NET (03/06/87)
I'm taking an informal poll which concerns the types of user lo- gin names people use on their Unix systems. First, let me pro- vide some background. I work on a Sun system which consists of 2 diskless clients (Sun-3/160's) and a file server (Sun-3/180). In addition, we have numerous VAXen and MicroVAXen, all running VMS. We also have a large IBM MVS system, a VM/CMS system, and a CRAY. Until recently, userids on the Suns consisted of users' last names. Our IBM systems use userids which are unique 6-character alphanumeric codes obtained by taking a user's Social Security Number base 36 (or something like that). As far as the user is concerned, it's a random userid (e.g. QZX1RS). In the interest of security. the powers that be have decided to use this type of userid on the Sun system. Naturally, the Sun users balked. I've tried to reason with the system administrators, but to no avail. I pointed out that enforcing stricter password usage measures would be a better solution (e.g. password aging, computer- generated passwords, minimum length passwords, etc). I notice that nearly every contributor to unix-wizards has a userid which consists of either the user's last name, first name, initials, or some combination of these. Surely you guys are concerned with security?! (the response I got was that csnet users are all university types (and I guess I was supposed to assume that university types aren't security-conscious)). Can anyone come to my defense? Thanks for your time. _________________________________________________ |Jim Marselle | Phone: (313) 986-1413 | |GM Research Labs | csnet: marselle@gmr.com | |30500 Mound Road | | |Warren, MI 48090 | | -------------------------------------------------
bzs@bu-cs.bu.EDU (Barry Shein) (03/07/87)
What are the arguments that non-mnemonic userid's were more secure?
I've never heard that. Is it because it gives a system hacker
something easier to remember to bash passwords at? User id names are
almost always readily available from the (print out) trash cans, but
perhaps it gives a somewhat easier target to guess at from the outside
(of course, they're only gonna bash at 'root' anyhow...)
I always thought the motivation for large systems to use those
automatically generated userids was simply to make their life easier.
On a large system it's hard to come up with a unique name and
collisions are likely so you can go back and forth with a user for a
while ("whaddya want?" "bob" "nope, bob's taken" "uh, bobm" "no, bobm
is taken" etc.) This could clog a bureaucracy. Are you sure you're not
dealing with some sort of cargo cult? Does anyone remember why they
started that automatic userid business?
We solved that on the student systems by writing a little program
which runs dedicated at a terminal and lets you fill out a "form",
among the questions is "what user name do you want?", it then checks
if it's unique immediately and, if it is, reserves it immediately
otherwise asks again. The entries are batched together and checked
over later for inclusion in the passwd file (both the "batch" file and
passwd file are checked for exclusivity.) No big deal, grep goes a
long way here (and a lock.)
You could argue back that if they insist on consistent naming then
once someone has one userid they have it for all systems (and could
try the same password, not that wild a guess if they have the
password.) It's dumb, but what the heck, it throws it back in their
court.
-Barry Shein, Boston Universitykurt@hi.UUCP (03/07/87)
Securing the average UNIX is next to possible (unless you pull the power cable :-). Such measures as making login names more cryptic doesn't really increase security but just makes it harder for the users to communicate (what's joe login name again?) and thus decreases the useability of the system. -- 9ACFH6 -- Kurt Zeilenga Internet: zeilenga@hc.dspo.gov (505) 277-1611 UUCP: hc!zeilenga All opinions are my own.... my boss can air his own.
djfiander@watnot.UUCP (03/08/87)
This is not exactly a Unix userid convention, but it does say something
about security and userids:
A _long, long_ time ago I worked for a certain large computer company
(nudge, nudge) in a research facility that they operate in Toronto.
They were so security conscious that I had to use a mag-strip card to get
from my office to the cafeteria, however my userid, and those of everybody
elses on the system, was my last name and my initials (up to a limit of
eight characters, of course).
I don't see how having cryptic userids does anything but make it difficult
to communicate through the obvious medium of electronic mail.
--
"I don't want to achieve immortality through my work.
I want to achieve immortality through not dying"
- Woody Allen
UUCP : {allegra,ihnp4,decvax,utzoo,clyde}!watmath!watnot!djfiander
CSNET : djfiander%watnot@waterloo.CSNEThenry@garp.mit.edu (Henry Mensch) (03/09/87)
djfiander@watnot.UUCP (David Fiander) wrote:
->I don't see how having cryptic userids does anything but make it difficult
->to communicate through the obvious medium of electronic mail.
Well, sometimes it helps the people who run the place (often these
people are called "bean-counters") keep track of what's going on
without expending much effort. Some time ago, when I worked in the
Midwest, I was assigned a login name of "ag5". This had nothing to do
with security--instead, it seems that these ridiculous login names
(yes, they were all three-character login names) mapped to account
names on an archaic system on which the bean-counting (and lots of
other miscellaneous batch processing) was performed. These login names
were automatically generated, although it seems that (now) if you kiss
the appropriate bottoms there you can get your initials as a login
name.
Nevertheless, I think you're right. Cryptic login names make things
difficult for the user, and if a cracker wants in, (s)he'll get in
whether the login names are obvious or not.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Henry Mensch <henry@garp.mit.edu>
{ames,cca,rochester,mit-eddie}!garp!henryzellich@ALMSA-1.arpa (03/09/87)
Actually, if your installation has a need for the extra login security, then assigning "cryptic" userids is a fairly good idea - the userid and password should \both/ be protected (although you can't really hide the userid from other legitimate users of the system without moving to some kind of a "secure" variant of Unix). No sweat on e-mail - you just set up useful aliases for each user the same way we do now; nothing says a user's login id and mail id have to be the same (and there can be multiple aliases for mail, so nobody has to remember if I'm "richz" or "rzellich" or "zellich" or "amxalfpi" (an office symbol here)).
davids@iscuva.UUCP (03/09/87)
Here where I work we brought in 5 MicroVAX II's running Ultrix and an 11/785 running VMS about a year ago. Other portions of our company were using login names (on our IBM mainframes) of the user's first initial, last initial, followed by the employee number (ds08393). The person who was organizing the installation of our new systems decided that if others used that method then we would use the same method (against both the VMS and Ultrix administrators wishes). This lasted about 3 months before we were allowed to changed to a more user friendly method. Durring those 3 months it was VERY difficult to communicate with other users. We were always looking up names off of printed cross-references or guessing and getting them wrong. We currently use first name, last initial (davids). In the case of duplicates (3 out of 130 users!) we simply added a second letter from the last name to the second user. Communication be INSTANTLY easier for all users. Even those who opposed the change agreed afterwards that it was much better than before. The place for security is not in the user names, it should be in enforcing good password practices (long passwords, password aging, etc.). -- David Schmidt UUCP: ihnp4!tektronix!reed!iscuva!davids ISC Systems Corp. Phone: (509)927-5479 Box TAF-C8 Spokane, WA 99220
mike@BRL.ARPA (Mike Muuss) (03/10/87)
BRL UNIX Release #3 and beyond have a variety of improvements to the security mechanisms of UNIX, especially in LOGIN, where stricter logging/disconnect policies are implemented, and in PASSWD, where user-selected passwords must clear dictionary lookups, local dictionary lookups, and a local administrator "hotlist" which includes passwords like the ever-popular "susan". There is no additional security obtained by having gibberish user names. Not counting the "who" and "ls" commands available to other local users, the first time each user posts mail and/or netnews, their username is "out of the bag". Big deal. For a really cogent discussion of computer security, may I refer you to Army Regulation 380-380 (available from the Government Printing Orifice) -- it's one of the few well written Government security regulations. Observe how it spends most of it's time discussing physical security, and personnel screening. To your IBM folks, just bellow "Egads, it's User Hostile" and beat a hasty retreat. Best, -Mike Muuss Postal: Mike Muuss Leader, Advanced Computer Systems Team Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory Attn: SLCBR-SECAD (Muuss) APG, MD 21005-5066
karl@cbstr1.att.com (Karl Kleinpaste) (03/10/87)
Posting-Front-End: GNU Emacs 18.37.1 of Wed Feb 25 1987 on cbstr1 (usg-unix-v)
zellich@ALMSA-1.arpa writes:
No sweat on e-mail - you just set up useful aliases for each user
the same way we do now; nothing says a user's login id and mail id
have to be the same...
True enough. I have been using a modification to smail (first in 2.1;
added to 2.3 yesterday) which does fullname delivery of mail. Mail
from me now says I am Karl.Kleinpaste@cbstr1.att.com, in both the
From: and From_ lines. Works great. Has a nice heuristic for
variations on a fullname, e.g., for a gecos field in /etc/passwd of
"First M. Last (Nickname)," it'll deliver to First.M.Last, F.Last,
Last, Nickname.Last, or N.Last, all equivalent. Now there is
effectively no relationship between my login name and my mail address;
it could change to "zzrwvjs" tomorrow and no one would know by my mail
address.
Now I need to convince the netnews software to use the same mechanism,
so that outbound news doesn't advertise me by login name, either.
PS- How many people are aware that the current development version of
smail is up to version 2.5? I got mail via floyd yesterday, and its
Received: line said "smail 2.5" in it. Rather volatile software...
--
Karlbrian@asci.UUCP (brian) (03/11/87)
Expires: Sender: Followup-To: Distribution: Keywords: Our company does a large amount of consulting & programming on systems from PC's to IBM main frames, with 90% of the work under Unix, which is divided up about 70-30 between DoD and Private enterprises. Every system can be considered to contain sensitive information to somebody somewhere, whether it be government or private. Generally speaking, under Unix using the user's name is the only good method for userids for the many reasons already mentioned (i.e. e-mail), and most large systems do generate their own account names for their own convenience. However, there are times and systems when a cryptic password, and/or userid is necessary. When a name is used for the userid, and the user is allowed to assign their own password, 90% of the time they will use passwords of some familiarity, their child's name (alla Wargames), religious affiliation, names of great ships. For a great many systems this is no problem. But in large corporate structures, the most pervasive security issue facing Administrators today arises using such a passwording and userid scheme. This is the Internal Infiltrator (I.I.). These security violator, under Unix particularly, usually have no interest getting to the master account (root). Rather, the I.I. is usually interested in viewing data he has no business looking at. For example, a manager writes a confidential memo to another manager that a recently transfered employee was suspected of using cocaine on the job, and for the new manager to keep an eye on him. Later the employee is fired for whatever reason, only to produce a copy of the memo. Legally explosive. Other examples include viewing a competitor's accounting files. An unscrupulous colleague damaging your work for his own gain in the work place. These have and continue to happen in the corporate world, and if an I.I. knows something about you, and your method for passwording, he's already cut down the number of password bangs from hundreds of thousands to tens, or maybe even a few thousand. He probably doesn't even care about root's password. The I.I. is the #1 threat to security in the corporate Unix world. For those situations our method of generating a password is to open a dictionary, point to a word, and take the first letter. Then close the dictionary, open again, p-t-a-w, and take the second letter, etc., etc., through the maximum allowable characters. From, there, it is absolutely forbidden to write down the password, instead a mnemonic is developed (i.e. qazxsw is quite all zebras x-ray session writing). This is drilled into the user. We now are back to hundreds of thousands of possibilities. Under Unix, it makes no sense to be cryptic for the userids, for all the I.I. would have to do is print the passwd file, and then bang on the password to get in under the account desired. Using mnemonic userids is the only viable method to assign these. However, on non-Unix machines, without these types of security deficiencies, cryptic userids do become a powerful tool for internal security. Lastly, the best security method of all is put the system in a TEMPEST approved vault, with all the terminals in the vault, and make everybody sign in and out. But then again, anybody that really wants in can always pull out the most trusted tool of any system penetrator. The time honored practice of bribery. A very hard method to defend against. Brian Douglass Applied Systems Consultants, Inc. (ASCI) P.O. Box 13301 Las Vegas NV 89112 (702) 733-6761
arnold@apollo.UUCP (03/12/87)
In article <4788@brl-adm.ARPA> MARSELLE%gmr.com@RELAY.CS.NET writes: >Until recently, userids on the Suns consisted of users' last >names. Our IBM systems use userids which are unique 6-character >alphanumeric codes obtained by taking a user's Social Security >Number base 36 (or something like that). As far as the user is >concerned, it's a random userid (e.g. QZX1RS). In the interest >of security. the powers that be have decided to use this type of >userid on the Sun system. How about the following: by using your Soc Sec # as your login id, everyone on the system knows everyone else's Soc Sec #. This is pretty absurd. SSN's are a little too useful for accessing info about people to make them public. I sure wouldn't want my SSN to be widely known -- do you? Suggest using bank account #s instead -- that, at least, is only *one* of the peices of info generally available using the SSN. See how they react to *that* suggestion. This is all in addition to the fact that ugly login names are no deterrent whatsoever. My login name is very publicly known -- every time I post to usenet thousands of people can see it. If I want anyone to send me mail *they* get my login name. *Passwords* are the point of security, and many techniques are already available to deal with that. Ken Arnold uucp address: apollo!<censored for security reasons>
apn@nonvon.UUCP (03/12/87)
I don't think that the basic assumption is valid:
scrambled userid's == better security
while, It *is* certainly true that
scrambled userid's == more confusion
Could someone clarify this to me. Why is it , that by having
an obscure sequence of characters in your login name, security
is compromised/enhanced of the ability to login as that user ?
--
UUCP: {sun, seismo, amdahl, lll-crg, 'etc'}!ptsfa!nonvon!apn
{* Only those who attempt the absurd ... will achieve the impossible *}
{* I think... I think it's in my basement... Let me go upstairs and check. *}
{* -escher *}rbj@icst-cmr.arpa (03/13/87)
? Until recently, userids on the Suns consisted of users' last ? names. Our IBM systems use userids which are unique 6-character ? alphanumeric codes obtained by taking a user's Social Security ? Number base 36 (or something like that). As far as the user is ? concerned, it's a random userid (e.g. QZX1RS). In the interest ? of security. the powers that be have decided to use this type of ? userid on the Sun system. Naturally, the Sun users balked. I've ? tried to reason with the system administrators, but to no avail. ? I pointed out that enforcing stricter password usage measures ? would be a better solution (e.g. password aging, computer- ? generated passwords, minimum length passwords, etc). I notice ? that nearly every contributor to unix-wizards has a userid which ? consists of either the user's last name, first name, initials, or ? some combination of these. Surely you guys are concerned with ? security?! (the response I got was that csnet users are all ? university types (and I guess I was supposed to assume that ? university types aren't security-conscious)). ? ? Can anyone come to my defense? Thanks for your time. Sounds like the EDS bozos. Pretty brain-damaged, eh? All you can do is play their game. As mike@brl suggested, get that report. All you other groovy people commenting on this have missed the point: Merely *knowing* that a given user has an account on a machine provides a clue as to where to look. Anonymity provides some `security'. Tell them it's a violation of your privacy to use your SSN as an input to a function. Just wait till those suckers find out the password file is readable :-) (Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa> Why did Paul Simon name his album after Elvis Presley's house? Disclaimer: I speak for myself. NBS doesn't necessarily think likewise of EDS, but just the same, I haven't seen any of them working on any of our contracts either. P.S. Say HI to Myron Ginsberg for me.