|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1989)
DOCUMENT: Rutgers 'Security List' for May 1989 (79 messages, 33398 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1989/05.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 May 89 07:07:41 GMT From: waters@dover.sps.mot.com (Mike Waters) To: misc.security Subject: Re: MEDCO locks
>you can always rekey when an employee leaves (and it's >pretty easy to do so if you use interchangeable-core cylinders). Re-keying is also pretty cheap, it cost me $20 to change all seven locks when I moved into my present house. Don't negelect the obvious and the cheap solutions too! -- *Mike Waters AA4MW/7 waters@dover.sps.mot.com OR waters@cad.Berkley.EDU* Mr and Mrs PED, can I borrow 26.7% of the RAYON TEXTILE production of the INDONESIAN archipelago?
-----------[000001][next][prev][last][first]---------------------------------------------------- From: david paul hoyt <YZE6041@vx.acss.umn.edu> 2-MAY-1989 18:08:19 To: security@pyrite.rutgers.edu
>How many seconds? Does this rely upon a chip in the card keeping time >accurate to within a number of seconds over an operating lifetime of >possibly years? ... This isn't a problem really. There are phone numbers you can dial to get the correct time (international standards, inference clocks) accurate to some fraction of a millisecond. The macintosh pd program "setclock" uses this mechanism to get the 'correct' time. The card only needs to be able to resync before connecting to the remote system (assuming the remote uses an accurate clock as well). Alternatively, the card can sync with the remote as part of the handshake. After all trading times in clear text can hardly pose any kind of security breach. david | dhoyt@vx.acss.umn.edu | dhoyt@umnacvx.bitnet
-----------[000002][next][prev][last][first]---------------------------------------------------- From: _David C. Kovar <daedalus!corwin@talcott.harvard.edu> 2-MAY-1989 19:35:29 To: security@rutgers.edu
I was tracing the phone wires in my house yesterday afternoon trying to find out why my phone was "off-hook" when all of the phones were actually hung up. Just before the lines enter my house I found a gray box labelled "Telephone Network Interface". Curious, I opened the box to find two RJ-11 modular phone jacks with black connectors in them that were held in by clips. I popped the clip, unplugged the plugs and plugged in a normal phone. Lo and behold, a dial tone! I wandered around the neighborhood a bit and found a few more of these boxes. Looks like you can wander around Boston with a phone, plug into someone's circuit, and make as many phone calls as you like. Who needs lineman's equipment? -David C. Kovar Technical Consultant ARPA: kovar@husc4.harvard.edu Office of Information Technology BITNET: corwin@harvarda.bitnet Harvard University MacNET: DKovar Ma Bell: 617-495-5947 "It is easier to get forgiveness than permission."
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 May 89 13:53:48 GMT From: silber@TCGOULD.TN.CORNELL.EDU (Jeffrey Silber) To: misc.security Subject: Access control & accounting
I am looking for accounting and access control software to run a
production Unix (tm) system (2000-3000 users). If anyone has any
suggestions please send e-mail. Thanks.
--
"A billion here, a billion there, and pretty soon you're talking real money."
--Sen. Everett Dirksen
Jeffrey A. Silber/silber@tcgould.tn.cornell.edu
Business Manager/Cornell Center for Theory & Simulation in Science & Engineering
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 1 May 89 20:02:14 GMT From: rogers@MARLIN.NOSC.MIL (Rollo D. Rogers) To: misc.security Subject: Re: car locks
hi, have you heard of the latest lock for vehicles here in S. Calif. which is called the "Club". If yes, what is your opinion as to how secure from theft a car with this club locked onto the steering wheel would be? REgards, RollO~~
-----------[000005][next][prev][last][first]---------------------------------------------------- From: "Michael J. Chinni, SMCAR_CCS_E" <mchinni@pica.army.mil> 3-MAY-1989 7:22:13 To: security@pyrite.rutgers.edu
What we do:
Our site is a government installation (DoD - Army). (1) dealt with verbally
(i.e. those that need to know are told verbally). (2) the non-administrator
doesn't get the password. The passwords are NEVER to be written down, under
any circumstances.
Recommendations:
What we might do if we did write down the password in a "book" would be to
keep this "book" in a combination-type safe. Only those people who were
authorized, in advance, as primary or alternate admins. (or bosses) would have
the combo. to that safe (that includes lock&key control as not have-ers).
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Michael J. Chinni
Chief Scientist, Simulation Techniques and Workplace Automation Team
US Army Armament Research, Development, and Engineering Center
User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey
and dust covered terminal and desk () ARPA: mchinni@pica.army.mil
"System been down long?" () UUCP: ...!uunet!pica.army.mil!mchinni
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
-----------[000006][next][prev][last][first]---------------------------------------------------- From: steve@polyslo.calpoly.edu (Steve DeJarnett) 3-MAY-1989 8:10:16 To: CHRIS@BROWNVM.BITNET, SECURITY@pyrite.rutgers.edu
We deal with the need-to-know problem in a fairly simplistic way. We keep our root password inside of a sealed (and taped-shut) envelope that is stored in a lock-box. Those people who might actually need to know it in an emergency have a key to that lock-box. The envelope is checked daily. If someone needs to know the password in an emergency, they must go into the machine room, where the lock-box is -- only about 12 people have keys to this room, and of those 12, only 8 have keys to the lock-box, and of those 8, 5 already know the root password (whew -- what a great sentence :-). From there, they must sign their name and write down the reason they took the root password. As soon as the system staff come in, the password is immediately changed, and a quick audit is done of the file system (all automated in shell scripts, so it's not too difficult). This does rely on the fact that you know everyone who has access to the lock-box, and that they can be trusted to sign for the password when they take it. We've only had one problem with this, and that was when a new admin on one of our smaller machines thought he had a valid reason to access the password, and did so. When we came in, we found the machine in single-user mode with no one in sight. That operator was "re-educated", and we haven't had any problems since then. It is important to make the envelope fairly tamper-resistant (we use a thick manilla (opaque) envelope with a smaller envelope inside of it. Both are sealed, and the outer one is taped shut. We've never had a problem with someone trying to open it without being noticed. Another security feature you could add to make this safer is to have a video camera trained on the lock-box and run it all day long. If you had any doubts about someone breaking in, just check the tape. Well, that's my $0.25 worth. Steve DeJarnett System Manager Cal Poly San Luis Obispo steve@polyslo.CalPoly.EDU
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 2 May 89 09:29:00 GMT From: SUNDSTROM@aboy2.abo.fi To: misc.security Subject: Re: MEDCO locks
>I have never seen any third party abloy clone
>keys, thereby making abloy your only source for key blanks.
In Finland we have two different types of Abloy locks (or keys) one
'standard' and one with one or two security slots ("scores"). For the later
one, duplicate keys are only obtainable from the factory with an authorized
name signature (=signature of the person who bought the lock). The 'standard'
key is obtainable from any locksmith. The Abloy locks here are absolutly
most common locks a rought approx. is about 95 % of door locks
Hans Sundstrom Internet: SUNDSTROM@ABOY2.ABO.FI
Heat Eng. Lab.
Abo Akademi
FINLAND
[Moderator toss-in: Abloy originally started in Finland, I believe. I just
recently had a longish talk with their Texas office... _H*]
-----------[000008][next][prev][last][first]---------------------------------------------------- From: deh@eng.umd.edu 3-MAY-1989 17:28:37 To: 34AEJ7D@CMUVM.BITNET Cc: security@pyrite.rutgers.edu
I agree that you should use whatever you can get your hands on for illumination of code buttons; I mentioned laser dyes because I happened to have a lot of them around at the time that I first tried this, and it worked very well. Most of the dyes that I have used are pretty common, pretty cheap, and to the best of my knowledge none of the ones that I have used have been toxic.... One consideration in choosing the dye to use (for buttons, not for lasers) is what it looks like in regular light, since you don't want people seeing it on the buttons. ANother consideration is the method of application. One reason the laser dyes worked so well was the fact that they were disolved in solvents, usualy alcohol but also ether some times. In a spritzer bottle, these can be sprayed on the target area where they will dry quickly, leaving a very fine and uniform distribution of the dye material which is very likely to escape detection. DO make sure that the solvent doesn't melt the materials that the buttons, etc. are made of though..... Doug
-----------[000009][next][prev][last][first]---------------------------------------------------- From: "David F. Lambert" <LAMBERT@mitvma.mit.edu> 3-MAY-1989 18:13:42 To: security@pyrite.rutgers.edu
You'll be better off *not* sharing passwords due to the problems you've
raised here as well as other problems that shared passwords can cause.
It is more desirable and auditable for you to be able to logon to
the "commonly shared" userid with other "authorized" passwords. This
method has several advantages:
-provides auditability by requiring the "real" logon persons
to identify themselves (via their password)
-allows you to change passwords of shared userids without contacting
all users who logon to those userids (if you still need the "normal"
logon password)
-makes encrypting passwords more feasible
-no need to memorize multiple passwords for various userids
Of course, this scheme does imply that more than the single standard
password can be used to logon. If you're running VM, which your node
name suggests, VMSECURE implemented this scheme nicely in Release 3.2
I believe. VMSECURE calls it the LOGONBY access rule. I'm not sure
if RACF or other VM security package equivalents have this feature.
-Dave
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 May 89 21:29:57 GMT From: haynes@UCBARPA.BERKELEY.EDU (Jim Haynes) To: misc.security Subject: Re: Telephone line security
These boxes replace the former lightning protectors. Now that you
own, and are responsible for maintaining, the wiring inside your house,
the box provides a way for you to disconnect all your house wiring and
test the circuit at the phone company's demarcation point. Otherwise
if you report trouble and they come out and find it's in your house
wiring they will charge you a lot for their time and trouble.
Just consider it one of the benefits of deregulation...
While it does make it a little easier for someone outside to make
calls on your phone line, the possibility was always there. With
the older units the bad guy had to have alligator clips instead of
a modular plug on his phone, that's all.
haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ...ucbvax!ucscc!haynes
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chronicle
-----------[000011][next][prev][last][first]---------------------------------------------------- From: John Kinne <JDKINNE@MIAMIU.BITNET> 4-MAY-1989 6:07:23 To: security@pyrite.rutgers.edu
To be effective, the number of people who know a pw must be kept to a minimum. The small department that I am associated with insures that each member of that small group is told the new pw, verbally, in a low voice. > how does a non-administrator get the password in an emergency? That service is unavailable until a staff member can fix it. We strive not to have all members of the support staff absent on the same day. When it is necessary that the complete support staff be absent, then we leave forwarding numbers. If that doesn't work, then the service is unavailable.
-----------[000012][next][prev][last][first]---------------------------------------------------- From: Lynn R Grant <Grant@dockmaster.ncsc.mil> 4-MAY-1989 8:18:09 To: SECURITY@pyrite.rutgers.edu
The way to know make sure that everyone who needs to know knows when a password changes is to have only one person per userid. This also gets you accountability. As for data set passwords, if you have a good access control system (like the ones my employer makes) you don't need them; since the one userid/password scheme can assure that the person is who he claims to be, you merely need to tell the access control system who can get at what. (Of course, for the accountability to work, you need to do the ordinary stuff about not writing down the passwords, not using your name, or your girlfriends name, or your social security number, or whatever, etc.) One approach to what to do when the security administrator isn't around is to have a special security administrator userid whose password is in a sealed envelope. If your shop is a mainframe shop, you give it to the night shift operations supervisor. Otherwise you put it in a "break glass" sort of box. Every morning, the real security officer checks to see if the envelope has been opened. If so, he immediately changes the password and investigates what was done with it. There is some exposure here, since this is a detective control. If you don't have an access control system with good logging capabilities, you won't know what was done with the special userid. And if the person who uses it is a very sharp crook, he may be able to wipe out the logging anyway, if the userid in the envelope is powerfull enough. But if you can't afford to have full-shift security officer coverage, it works better than giving everyone security privileges. Lynn R Grant Computer Associates International, Inc.
-----------[000013][next][prev][last][first]---------------------------------------------------- From: jwright@atanasoff.cs.iastate.edu (Jim Wright) 4-MAY-1989 9:11:41 To: misc-security@ames.arc.nasa.gov
The voting period for the new newsgroup comp.virus has just ended. The final vote count was 403 YES, 30 NO. I think it's fair to say that significant interest has been shown in this group. The list of voters will be posted in news.groups so you may verify that your vote was recorded. I'll gladly accept any corrections, although it would take a rather colossal error to affect the outcome of the vote. As per the "official guidelines", the group should be formed in approximately five days. (Today being 24-Apr-89.) Look for it soon at a computer near you. There has been some interest in the mailng list virus-l. Comp.virus and virus-l will contain the same information, the only difference being the method of distribution. The following information should assist you in subscribing to the list. Note that it is NOT necessary to subscribe to virus-l if you receive Usenet. Also, if you receive Usenet and subscribe to virus-l, you should unsubscribe once the group comp.virus is formed. There are currently about 1175 direct subscribers to virus-l, so I'm sure Ken would appreciate the reduced load. > ... So, to get onto the VIRUS-L mailing > list, send a mail message to <LISTSERV@LEHIIBM1.BITNET>. In the body > of the message, say nothing more than SUB VIRUS-L your name. LISTSERV > is a program which automates mailing lists such as VIRUS-L. > ... > If, in the unlikely event, you should happen to want to be removed > from the VIRUS-L discussion list, just send mail to > <LISTSERV@LEHIIBM1.BITNET> saying SIGNOFF VIRUS-L. Finally, we have been hard at work trying to organize a system of anti-viral software archive sites. Through the generous assistance of the individuals at each site, this promises to be a great success. We are still tying up some loose ends. Look for a full announcement of the archive system once comp.virus is in action. -- Jim Wright jwright@atanasoff.cs.iastate.edu
-----------[000014][next][prev][last][first]---------------------------------------------------- From: shipley@tarantula.berkeley.edu (Pete Shipley) 4-MAY-1989 17:36:24 To: misc-security@ucbvax.berkeley.edu
Question:
What problems will using a modified passwd des crypt function will create.
The idea I am tring to present is that if a system was to use a modified
version of crypt(3) (and install it in the libaries) and use it for the local
password file password enteries wont this prevent the grabing of
password files and 'grinding' on a local system.
-Pete
Pete Shipley:
email: shipley@berkeley.edu Flames: cimarron@postgres.berkeley.edu
uunet!lurnix!shipley or ucbvax!shipley or pyramid!hippo!{ root peter }
Spelling corections: /dev/null Quote: "Anger is an energy"
-----------[000015][next][prev][last][first]---------------------------------------------------- From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 4-MAY-1989 17:55:09 To: security@pyrite.rutgers.edu
This has gone far enough. When I was in New York, I was living with a cocaine dealer who had a Medeco lock on her front door. I wanted a spare key for my girlfriend, but the landlady wouldn't give one to me. I took the key to a tiny, Israeli locksmith near 98th street and Broadway. He measuered the hights of each using a tool with a triangular hole in it (with calibrations along the side), and wrote down the orientation of each notch. He then took a blank (that did not say "Medeco" on it) put it in a machine and started cutting the key. On each notch, he would change the orientation of the blank in the machine, in accordance with the original. The process took about 4 minutes and cost $5.00. The key worked the first time. -simson
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 3 May 89 15:48:05 GMT From: kerchen@IRIS.UCDAVIS.EDU (Paul Kerchen) To: misc.security Subject: Re: password security
>password. As soon as the system staff come in, the password is immediately >changed, and a quick audit is done of the file system (all automated in shell >scripts, so it's not too difficult). Hmm, what's the use in using shell scripts if they can be changed by whoever last used the root password? Or, do you keep these scripts off line and just put them on the system when you need to make these checks? If I were a nasty employee (not to imply that you have such people where you are), I would get the password, do my damage, and then change the script to something like: echo "Everything's okee dokee! No reason to be suspicious!" (or whatever the appropriate message is) What's to stop this kind of nonsense? Paul Kerchen | kerchen@iris.ucdavis.edu
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 3 May 89 19:57:49 GMT From: gretzky@UNISON.LARC.NASA.GOV (Mr. Stanley Cup) To: misc.security Subject: System Security
Greetings to all you *net-landers*! I have been recently assigned a task to investigate methods for enhancing security on our "Super Computer Network" (1 Cray 3 Convex). In addition to this, I am supposed to "search and destroy" any security holes. For instance: Our convexes, being 4.2 based, had some *nasty* 4.2 bugs with the set process group, writing to ttys, and chfn. I am trying to compile a set of "test" programs that will check for these and other security holes. Could anyone give me a list of well known and not so well known security holes for 4.2 and 4.3 BSD and System V (UNICOS). Lists, explanations, code to exploit these holes will all be welcome and very much appreciated. Please *do not* post any code, but mail it directly to me at one of the below addresses. Any suggestions for security enhancement (not recently posted) would also be appreciated. Thanks Alot! -=>gretzky<=- .mitch ================================= | gretzky@unison.larc.nasa.gov | root@unison.larc.nasa.gov | gretzky@eagle.larc.nasa.gov | gretzky@uxv.larc.nasa.gov | mitch@teb.larc.nasa.gov | | =================================
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: 4 May 89 18:08:21 GMT From: goldstein@star.DEC.COM (Andy Goldstein) To: misc.security Subject: Re: password security
> The idea I am tring to present is that if a system was to use a modified > version of crypt(3) (and install it in the libaries) Well, the problem is that by virtue of this mail you've now announced to the world that you're running a modified crypt(3) (or might be). So all the crackers have to do is take your version of crypt along with your password file. Your best bet is to convince your users (by moral suasion or, preferrably, software) to not use dictionary words as passwords. - Andy Goldstein VMS Development
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 5 May 89 01:23:00 GMT From: A01MES1@NIU.BITNET (Michael Stack) To: misc.security Subject: Re: password security
> ... I'm not sure > if RACF or other VM security package equivalents have this feature. "group logonids" are a standard feature of ACF2/VM and are intended to provide accountability for the use of VMs like MAINT. Michael Stack Northern Illinois University
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 5 May 89 04:56:27 GMT From: rjg@sialis.mn.org (Robert J. Granvin) To: misc.security Subject: Re: Medeco Keys
Please realize the whole point is that Medeco locks and keys aren't that they can't be duplicated, but that they are normally very difficult to do so. The vast majority of people wanting to make a copy won't go through the effort to find someone as you described, and if they did, they probably wouldn't have the same first time success rate. Doing so, depending on the environment where the key is intended for, may show criminal intent. You can't really say that about your normal household locks you get from the hardware store. On the other hand, picking a Medeco lock is again, significantly more difficult than other locks. Nothing is 100% guaranteed secure, but you can make the "average" criminal go somewhere else and leave you alone. This is generally the goal. The only way that you can prevent keys from being duplicated is don't put a keyed lock on a door, and don't distibute keys for that lock that doesn't exist. -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 6 May 89 17:27:18 GMT From: jaw@SESUN.JPL.NASA.GOV (Joe Wieclawek) To: misc.security Subject: Computer hacker working on another plea bargain
An article in the 6 May 1989 'Los Angeles Herald Examiner' reports: Attorneys said yesterday they are negotiating a second plea bargain for computer hacker Kevin Mitnick, whose first offer to plead guilty was scuttled by a judge because it called for too little time in prison. Mitnick, 25, of Panorama City (CA) offered in March to serve one year in prison and to plead guilty to computer fraud and possessing unauthorized long-distance telephone codes.
-----------[000022][next][prev][last][first]---------------------------------------------------- From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 9-MAY-1989 21:24:34 To: security@pyrite.rutgers.edu
Friends, I've received over 20+ messages asking for a copy of the article. I'm happy to post a copy of it if I retain the copyright (I don't know if whole earth review lets me do that or not.) Please don't send me any more requests for copies. Thank you. -simson
-----------[000023][next][prev][last][first]---------------------------------------------------- From: waters@dover.sps.mot.com (Mike Waters) 9-MAY-1989 22:14:08 To: misc-security@uunet.uu.net
>you can always rekey when an employee leaves (and it's >pretty easy to do so if you use interchangeable-core cylinders). Re-keying is also pretty cheap, it cost me $20 to change all seven locks when I moved into my present house. Don't negelect the obvious and the cheap solutions too! -- *Mike Waters AA4MW/7 waters@dover.sps.mot.com OR waters@cad.Berkley.EDU* Mr and Mrs PED, can I borrow 26.7% of the RAYON TEXTILE production of the INDONESIAN archipelago?
-----------[000024][next][prev][last][first]---------------------------------------------------- From: Victoria Landgraf <VLANDGRAF@eagle.wesleyan.edu> 9-MAY-1989 23:14:32 To: SECURITY@pyrite.rutgers.edu
On the subject of hard-to-copy keys, Russwin makes blanks that they don't sell
to your corner hardware store; and when you try to get such keys copied at a
locksmith's, s/he looks at you funny and says "That's a restricted blank; I
don't carry it; you have to get it copied where you got the original." I
assume this is a fairly standard tactic among lock companies who want to be
able to market a "high-security" line without doing much real work. On the
bright side, there's nothing particularly special or complex about a Russwin
key, so there's always brickstrap...
Victoria
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 8 May 89 22:32:21 GMT From: hazel%unm-la@LANL.GOV (AIDE Hugh Hazelrigg) To: misc.security Subject: orange book
About a week ago someone posted an article to misc.security which had some info on where to find the "Orange Book." Well, someone named Danny at the Federal Information Center had never heard of the "National Computer Security Center [publications office]" (which was the name of the source in the posting), nor the Orange Book nor Rainbow Set. He sounded like he really wanted to help, but needed more information. Can you or anyone in m.s provide it? Thanks in advance. Hugh [Moderator note: "Dunno" -- can anyone else clarify for him? _H*]
-----------[000026][next][prev][last][first]---------------------------------------------------- From: SUNDSTROM@aboy2.abo.fi 10-MAY-1989 17:34:23 To: security@pyrite.rutgers.edu
>I have never seen any third party abloy clone
>keys, thereby making abloy your only source for key blanks.
In Finland we have two different types of Abloy locks (or keys) one
'standard' and one with one or two security slots ("scores"). For the later
one, duplicate keys are only obtainable from the factory with an authorized
name signature (=signature of the person who bought the lock). The 'standard'
key is obtainable from any locksmith. The Abloy locks here are absolutly
most common locks a rought approx. is about 95 % of door locks
Hans Sundstrom Internet: SUNDSTROM@ABOY2.ABO.FI
Heat Eng. Lab.
Abo Akademi
FINLAND
[Moderator toss-in: Abloy originally started in Finland, I believe. I just
recently had a longish talk with their Texas office... _H*]
-----------[000027][next][prev][last][first]---------------------------------------------------- From: hollombe@ttidca.tti.com (The Polymath) 10-MAY-1989 18:39:19 To: misc-security@sdcsvax.ucsd.edu
}WIEGAND is by far the best card technology that is available today
We here at the CAT factory have a different view. We've always thought
our Magic Middle cards were the best technology. (-:
}... WIEGAND cards work
}by having a thin bi-metal wire embedded in the card.
Sorry, I can't talk about how our cards work. I can tell you your
Cyclotron Analyser wouldn't affect them. I've also seen one cut in half
and taped back together and it still worked. Legend has it one hotshot at
Cal Tech was able to crack their encoding. We hired him. (-:
--
The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 452-9191, x2483
Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe
-----------[000028][next][prev][last][first]---------------------------------------------------- From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 11-MAY-1989 3:57:38 To: daedalus!corwin@talcott.harvard.edu Cc: security@rutgers.edu
Indeed, this is why I keep a lock on my Network Interface. Simson Garfinkel
-----------[000029][next][prev][last][first]---------------------------------------------------- From: haynes@ucbarpa.berkeley.edu (Jim Haynes) 11-MAY-1989 4:36:30 To: misc-security@ucbvax.berkeley.edu
These boxes replace the former lightning protectors. Now that you
own, and are responsible for maintaining, the wiring inside your house,
the box provides a way for you to disconnect all your house wiring and
test the circuit at the phone company's demarcation point. Otherwise
if you report trouble and they come out and find it's in your house
wiring they will charge you a lot for their time and trouble.
Just consider it one of the benefits of deregulation...
While it does make it a little easier for someone outside to make
calls on your phone line, the possibility was always there. With
the older units the bad guy had to have alligator clips instead of
a modular plug on his phone, that's all.
haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ...ucbvax!ucscc!haynes
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chronicle
-----------[000030][next][prev][last][first]---------------------------------------------------- From: nichols@cbnewsc.att.com (robert.k.nichols) 11-MAY-1989 5:23:25 To: mmm@cup.portal.com Cc: security@rutgers.edu
I have one of these "CIA letter openers" made by A. G. Russell, Springdale, Ark. I got it as a freebee with an order. I consider it just a novelty. It's pretty ineffective as a knife and too bulky for opening letters. The info sheet that came with it suggested that it could also be used as a tent peg. That's about the best use I can think of for it. Yes, it undoubtedly would pass through a metal detector (but, I am warned, it is NOT invisible to X-ray). If you wanted to sneak something onto an airliner, though, you'd be better off carrying a sharpening stone and using it to hone the cutlery that comes with the "food." -- .sig included a no extra charge. | Disclaimer: My mind is my own. Cute quotes and batteries sold separately. | >> Bob Nichols nichols@iexist.att.com << | [Moderator tack-on: American Airlines has pretty nasty-looking butter knives, that probably wouldn't require too much additional work to be destructive. On a recent round trip I pocketed mine on the way to, and on the way from took it through security and put it in the little metal-things-you're-carrying bucket. They looked real funny at it and wondered why I was carrying it until I pointed out the little "AA" logo engraved into the blade, and told them I was bringing it back. They then let me through with it. _H*]
-----------[000031][next][prev][last][first]---------------------------------------------------- From: steve@nuchat.uu.net (Steve Nuchia) 11-MAY-1989 5:41:35 To: misc-security@uunet.uu.net
A client has a small network of Suns that they would like to connect to the internet. They would accomplish this by bridging to the ethernet operated by the umbrella organization of which they are loosely a part. They have limited experience with this style of networking, having transitioned from VMS/THEnet only recently. They are very concerned about security. Not spooky, just the normal desire to have the system continue to work most of the time. The system is a 3/280 + 4 diskless Sun3 clients; some 386i stuff will be attached soon. All running SunOS4.0.1. The environment is quasi-academic, with lots of students hanging around. The attack scenarios we are most concerned with are the typical things you see at schools rather than sophisticated industrial espionage attacks. I haven't been through this before. I know a bit about security in general and securing a regular timesharing sort of system, but all the networks (and especially NFS systems) I've been responsible for have been isolated. I would appreciate any advice you might have to offer. Something like a checklist of things to button up or turn off seems a good goal, but priciples, platitutes, and references are also welcome. Ultimately I would like to have enough information to be able to tell my client that his system is safe to connect. Please send me mail -- my system is expiring news more often than I can get home to read it. I will condense the suggestions I receive and post a summary. Thank you. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 10 May 89 13:17:00 GMT From: WHMurray@DOCKMASTER.NCSC.MIL To: misc.security Subject: Sharing of Passwords
>To be effective, the number of people who know a pw must be kept to a >minimum. The small department that I am associated with insures that >each member of that small group is told the new pw, verbally, in a low >voice. (I am unable to tell whether this posting is "tongue-in-cheek." I will assume that it is intended to be sincere.) In order to be effective a password must be known by no more than one person. In the kind of open systems in which we deal (i.e., with many privileged users), the only way to be sure that it is known to only one person is to use it only once. The solution to this dilemma, dealt with many times in this forum in One-time password generators. This mechanism also provides for the passing and withdrawing of high privilege, since, unlike a password, the generator can be returned. (The discussion by the "secure" installation where five people know the root password and another copy is kept in a lock box is too absurd to deal with. If a system is so unstable that it takes five people with privilege to keep it up, it cannot be said to be secure in any meaningful sense anyway, but if five people share the password any way, then how you protect and account for the use of any copy is not material.) William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
-----------[000033][next][prev][last][first]---------------------------------------------------- From: silber@tcgould.tn.cornell.edu (Jeffrey Silber) 11-MAY-1989 22:59:15 To: misc-security@rutgers.edu
I am looking for accounting and access control software to run a
production Unix (tm) system (2000-3000 users). If anyone has any
suggestions please send e-mail. Thanks.
--
"A billion here, a billion there, and pretty soon you're talking real money."
--Sen. Everett Dirksen
Jeffrey A. Silber/silber@tcgould.tn.cornell.edu
Business Manager/Cornell Center for Theory & Simulation in Science & Engineering
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 10 May 89 16:11:14 GMT From: biocca@BEVB.BEV.LBL.GOV (Alan Biocca) To: misc.security Subject: Re: MEDCO locks
Rekeying isn't difficult or expensive to do yourself, either. I recently bought a $20 kit for schlage rekeying at the local Home club. It comes complete with instructions and some tools, all you need is screwdriver and pliers. Re-keying requires that you have both new and old keys, so it works best if you have a collection of keys to pick from when rekeying. You could file a key and make a new one, too. There is a gauge included that could be used to determine when the filing had reached a new 'standard' depth. The kit also includes a large quantity of each standard pin size as well as replacement springs in case they get lost or lose their force. I've done fifteen or twenty locks now and since you exchange pins rather than lose them you can almost handle an indefinite number of locks. Eventually you'll run out of a particular size and have to buy more of them or a new kit. Comments by Alan K Biocca
-----------[000035][next][prev][last][first]---------------------------------------------------- From: ns@maccs.mcmaster.ca (Nicholas Solntseff) 12-MAY-1989 19:15:22 To: misc-security@gpu.utcs.utoronto.ca
I have been told by someone in Export Controls in the Pentagon that letting a non-Canadian student (e.g., from the PRC or Poland) use a DES program is legally the same as exporting! Thus, a copy of Dbase III labelled "Not for export" cannot be used in an open lab here. Nick .....
-----------[000036][next][prev][last][first]---------------------------------------------------- From: "S.J.Leviseur" <sjl@ukc.ac.uk> 12-MAY-1989 19:42:14 To: misc-security@kestrel.ukc.ac.uk
>(5) Suppose you take DES binary out and some smart European puts it > back in, over there? As I understand it the terms of the AT&T licence says that I am entitle to use code from all previous releases of Unix. Since I have (legitimately) the DES code from 32V dose this mean that any SysV source code holder can be given it? sean
-----------[000037][next][prev][last][first]---------------------------------------------------- From: Rich Salz <rsalz@bbn.com> 12-MAY-1989 20:57:36 To: hal@gateway.mitre.org Cc: misc-security@uunet.uu.net
Hi. A similar question came up in the Usenet newsgroup comp.unix; this is what I wrote. My interest goes back three years when I posted a DES package to world-wide distribution and got scared. /r$ PS: Any other DES-legal discussion in misc-security I can FTP? --------------------------------- Newsgroups: comp.unix Subject: Re: DES software >I need to find a copy (or, preferably, a summary written in English instead >of legalese) of the American regulations that restrict the export of DES and >other cryptographic software. Does anybody know where I can find this? Let me start with a disclaimer: I'm speaking only for myself here, most definitely not for my employer or anyone else I refer to below, and only as an interested layman. You will not be able to find a non-legalese summary. (Hubris makes me want to add "other than this one." :-) You will only be able to find legalese rules and such. Your best bet is to hunt through a law library and a one that has the US Federal Register. There are two popular researched analyses on DES that were distributed on Usenet. One is by John Gilmore, the other is by DEC's Corporate Law Office. Lots of other opinion and "facts" have been offered, but almost without exception they have been based on ignorance; unless you've done research, or have the two primary sources, it's probably safe to ignore everything you've read other than this. (There's that hubris again.) DES export is a complicated issue, and like all legal issues when you get an opinion you should keep in mind the viewpoing of the person who gives it. John wants to spread open information as widely as possible, DEC doesn't want to get hauled into court. I agree with John. >From his readings of the rules and regulations, John determined that DES is technical information, and software. This means that it is under the control of the Department of Commerce. As such, once it is in the open literature, it can be passed around the world. In terms of Usenet and distributing source, this might mean someone would first have to publish their code in a journal somewhere. The only exception to this is if you're on a small list of banned countries, and even that might not hold. DEC claims that John is wrong, that DES is specifically called out as munitions, and therefore is under the control of the Department of Defense, specifically the Munitions Control Act. The upshot is that you can't give it outside of the USA. I'm not a lawyer, but the took John's analysis apart sentence by sentence, ending with "It is imperative that no Digital employee act in reliance on Gilmore's analysis or his conclusions." They even used SCREAMING all-caps. Since neither Department is an expert, the NSA acts as the technical advisory expert. Based on a couple of phone calls, chats with some former employees, and a DES-related meeting, the NSA's position is that DES should not leave the country. Because of this, many Unix vendors have two versions of their software, and it depends on whether they ship the DES cryptographic stuff or not. I remember reading a note from one of the Unix originators, that the only reason there were two versions of Version 7 was more administrative than legal. Perhaps if someone back then was able to fight the red tape we'd be spared all this mess today, perhaps not. I've heard Amdahl got the right permissions to export DES, but I don't know for sure; it was only "planned" at the time I read that note, they may have backed down. DES export has been discussed, at times, in sci.crypt, and in the Kerberos and Internet Engineering Task Force mailing lists. Switching from reporter to interpreter, let me say that I think the situation is changing, and that the stupid US rules may -- applicable or not -- may be lifted soon. Note that soon is measured on a beaurocratic time scale, which is similar to geologic time. The technical community, in particular the Internet, has a good channel into the Department of Defense, and the right word seems to be reaching the right people. There is a need for DES to be used globally, and there has been world-wide publication (in comp.sources.unix/unix-sources) of a package written in Finland, posted from Australia. I no longer have John's analysis at all (it was mostly private email, that he later posted), and I do have the DEC analysis. I don't like to distribute it since it has the look of a DEC internal thing (even though it was forwarded, second-hand, to sci.crypt), and especially since I don't have John's work. It is, however, interesting reading, and if someone is going to take up the fight (as opposed to just idle curiousity), let me know. If you want to play lawyer, here are some places to start: Department of State You want sections 120-126, at least, of the International Traffic in Arms Regulation 22C.F.R Subch. M (I don't know what that last part means.) Office of Munitions Control, Department of State They're responsible for saying if something is "munitions." The National Security Agency I've heard their DES tech expert left, and they're in the lurch. It's funny the way the answer their phones. Department of Defense You want Section 38 of the Arms Export Control Act. Department of Commerce You want the Commodity Control List, and Export Administration Regulations, Section 370.10 and 379.3 (General License GTDA). I like to know what's going on, and I seem to be in touch with the several areas where this is discussed, so if you start digging around, I'd like to know. Yes, that means I'm offering to be a "point man" on this. /rich $alz PS: if ANYONE has a copy of John's research, please let me know; I'll pay you for a copy.
-----------[000038][next][prev][last][first]---------------------------------------------------- From: Sean Casey <sean@ms.uky.edu> 13-MAY-1989 5:31:15 To: security@rutgers.edu
>I'm trying to find out what's going on with US DES export laws:
No problem. A guy in Finland or somewhere wrote a version of DES, which
was posted to comp.sources.unix with worldwide distribution. Since it
originated outside the US, it does not fall under the export restriction
laws.
It is a verified version of DES.
Sean
--
*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
*** Quid, me vexari? {backbone|rutgers|uunet}!ukma!sean
*** ``A computer network should be considerably faster than a calendar.'' -me
-----------[000039][next][prev][last][first]---------------------------------------------------- From: kerchen@iris.ucdavis.edu (Paul Kerchen) 13-MAY-1989 6:15:17 To: security@pyrite.rutgers.edu
>password. As soon as the system staff come in, the password is immediately >changed, and a quick audit is done of the file system (all automated in shell >scripts, so it's not too difficult). Hmm, what's the use in using shell scripts if they can be changed by whoever last used the root password? Or, do you keep these scripts off line and just put them on the system when you need to make these checks? If I were a nasty employee (not to imply that you have such people where you are), I would get the password, do my damage, and then change the script to something like: echo "Everything's okee dokee! No reason to be suspicious!" (or whatever the appropriate message is) What's to stop this kind of nonsense? Paul Kerchen | kerchen@iris.ucdavis.edu
-----------[000040][next][prev][last][first]---------------------------------------------------- From: *Hobbit* <hobbit@pyrite.rutgers.edu> 13-MAY-1989 6:22:38 To: security
I've often advocated the following around our shop, but nobody else wanted to bother with it: Administrators would normally be non-privileged, just like any other user, but they'd be able to run a magic program that accepts a *different* password that is unique to the person [taken from /etc/magicpasswd or some such], and if correct drops a root shell [privileged job for non-unix folks] on their terminal. We currently have such a magic program, but it doesn't ask for a password. Okay, so you have to remember an extra password, but BFD. Unfortunately this still doesn't prevent someone from trojan-horsing your .cshrc or other init files, but it does prevent someone random from finding a terminal you left logged in by mistake and whomping all over the system right then. Now, the remaining question is, whether it asks for a password or not: how do you tell before invoking such a thing if you've been trojan-horsed for the next time 'round after something like that happens? You certainly aren't going to want to sit there and read over your own login init every time you want to do something privileged. Answer a is, of course, don't leave yourself logged in on a public terminal; answers b, c, d.. are left to the reader. On a vax I ran a while back I had a fairly elaborate mechanism which would checksum as many of the various init files that the privileged job would invoke that I could find; and if any of them failed it would yell loudly. Said mechanism was protected from prying eyes; it had a separate built-in password, etc, etc. and was probably far more than anyone would normally want to deal with. Naturally, I'd have to go update the mechanism whenever I updated my init files. But by throwing up enough firewalls, even for myself [and typing the appropriate things needed quickly became microcoded into my fingers] made the machine quite a bit more secure. _H*
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 15 May 89 04:54:02 GMT From: steve@POLYSLO.CALPOLY.EDU (Steve DeJarnett) To: misc.security Subject: Re: password security
>Hmm, what's the use in using shell scripts if they can be changed by >whoever last used the root password? Or, do you keep these scripts off >line and just put them on the system when you need to make these checks? The version I use to check things lives in my bedroom at home. If these people can break into my house and modify the tape, then I guess I have larger problems than system security :-|. The fact that few people (until I sent this note out :-) knew that such scripts even existed makes it a little less likely that they'd be found (they also live so far down in the filesystem that I occasionally have trouble remembering where they are). When we do check the system, though, we either make a visual check of the scripts before running them, or bring my tape in from home. Of course, University security requirements aren't QUITE as stringent as those required by, say, the DoD. Steve DeJarnett Cal Poly San Luis Obispo steve@polyslo.CalPoly.EDU
-----------[000042][next][prev][last][first]---------------------------------------------------- From: Clive Dawson <AI.CLIVE@mcc.com> 16-MAY-1989 13:04:22 To: steve@polyslo.calpoly.edu Cc: CHRIS@BROWNVM.BITNET, SECURITY@pyrite.rutgers.edu
I'm always amused by the notion of "tamper-resistant" envelopes. I would hope that your scheme includes some means of authenticating the original envelope. What would prevent somebody from tearing open the envelope(s) and placing the contents into identical envelopes sealed in the same careful manner, etc. Are you using sealing wax and a secret signet ring? :-) Clive -------
-----------[000043][next][prev][last][first]---------------------------------------------------- From: Mr. Stanley Cup <gretzky@unison.larc.nasa.gov> 16-MAY-1989 13:43:00 To: @uxv.larc.nasa.gov:security@pyrite.rutgers.edu
Greetings to all you *net-landers*! I have been recently assigned a task to investigate methods for enhancing security on our "Super Computer Network" (1 Cray 3 Convex). In addition to this, I am supposed to "search and destroy" any security holes. For instance: Our convexes, being 4.2 based, had some *nasty* 4.2 bugs with the set process group, writing to ttys, and chfn. I am trying to compile a set of "test" programs that will check for these and other security holes. Could anyone give me a list of well known and not so well known security holes for 4.2 and 4.3 BSD and System V (UNICOS). Lists, explanations, code to exploit these holes will all be welcome and very much appreciated. Please *do not* post any code, but mail it directly to me at one of the below addresses. Any suggestions for security enhancement (not recently posted) would also be appreciated. Thanks Alot! -=>gretzky<=- .mitch ================================= | gretzky@unison.larc.nasa.gov | root@unison.larc.nasa.gov | gretzky@eagle.larc.nasa.gov | gretzky@uxv.larc.nasa.gov | mitch@teb.larc.nasa.gov | | =================================
-----------[000044][next][prev][last][first]---------------------------------------------------- From: ron@ron.rutgers.edu (Ron Natalie) 17-MAY-1989 0:35:09 To: misc-security@rutgers.edu
Not ANY duplicators are set up to do them. To get additional keys, we used to have to order them by number from the manufacturer. -Ron
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 15 May 89 17:04:09 GMT From: MOG::REX@ISDMNL.MENLO.USGS.GOV (Rex Sanders) To: misc.security Subject: RE: passwords
On our 4.3 BSD Unix system, we have three people that need root permissions. We used to all know the root password. Then, a security directive came around: one account, only one person knows the password. We set up three accounts, with names other than "root", and uid 0, gid 1. Each account has it's own password, and I changed the "root" password to something I've already forgotten. We put hooks in /.login and /.cshrc to source files of our own. This scheme has worked fine for several years now. To help other users identify "root" users when logged in, we named the other accounts with root vegetable names - mine is "radish". -- Rex rex@isdmnl.menlo.usgs.gov
-----------[000046][next][prev][last][first]---------------------------------------------------- From: rogers@marlin.nosc.mil (Rollo D. Rogers) 17-MAY-1989 1:06:35 To: NCASTELLANO@eagle.wesleyan.edu Cc: security@pyrite.rutgers.edu
hi, have you heard of the latest lock for vehicles here in S. Calif. which is called the "Club". If yes, what is your opinion as to how secure from theft a car with this club locked onto the steering wheel would be? REgards, RollO~~
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 15 May 89 18:14:32 GMT From: andrews@APPLE.COM (Richard Andrews) To: misc.security Subject: Re: DES Export
>From my own experience, it seems to me that DES per se is not excluded from export. It just depends on how you use it. I worked on a product, the AppleShare File Server, that uses DES to encrypt passwords, and that was granted a Commerce Jurisdiction (meaning Apple is free to export it). Clearly, we would not have been able to export it if we used DES for file encryption.
-----------[000048][next][prev][last][first]---------------------------------------------------- From: Mr. Stanley Cup <gretzky@unison.larc.nasa.gov> 17-MAY-1989 12:31:41 To: @uxv.larc.nasa.gov:security@pyrite.rutgers.edu
Subject: Password Security and multiple users per account (password) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DON'T (it's that simple) Two comments: 1) On the system that I am running, I have a program called "do" which will allow users to execute commands as root. The user must be in a "doers" file and a member of the "cando" group. The "doers" file can also restrict members of "cando" to a limited set of commands. All commands executed using do are logged (including failed command attempts), of course one can get around the logging by "doing" a command which allowed shell escapes (but I am working on that). 2) Have overhead accounts, 1 for each person that needs the password, and give them all the same user-id. (ie). root:/\/\/\/\/\/\:0:1:Root of All Evil:/:/bin/tcsh nobody:*:-2:-2::/: daemon:*:1:1::/: ... audit:*:9:9::/etc/security/audit:/bin/tcsh ... need1:abcdefghij:9:9:Mr. John Doe:/etc/security:/bin/csh need2:klmnopqrst:9:9:Ms. Jane Doe:/etc/security:/bin/csh ... Now if "need1" logs in with his password, then he becomes "audit". The same goes for "need2", but with her password. You can check wtmp for the last time that they logged in, and use lastcomm to see what they did (under "audit"). Of course this is *NOT* a good idea for root access. -- For root acess, use something like "do" -- >>> Just my 6 pence worth <<< -=>gretzky<=- .mitch
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 16 May 89 05:04:30 GMT From: alo@KAMPI.HUT.FI (Antti Louko) To: misc.security Subject: Re: DES export laws
> Thus, a copy of Dbase III labelled
> "Not for export" cannot be used in an open lab here.
Software vendors could do the following:
Take their software product without any non-export stuff to some of
their labs outside US. At that site, include some outside-US
DES-package into their product, or even better, ship their product in
relocatable form, so customer can link any encryption package with it.
My DES-package can be used freely for non-commercial purposes. If a
vendor ships my DES-package in source code (and optionally in
relocatable code) with their product so that customer can link it
together himself, I consider this as non-commercial use. The idea is
that the customer could do the same even if the vendor wouldn'n
provide the DES-package.
If the vendor packages their product and DES together (eg. linking
them into an executable) I consider this as a commercial use.
In my opinion:
Software vendors should ship all their software also in reloacatable
form!!
My DES-package is available by ftp at kampi.hut.fi (128.214.3.9) at
directory /alo/
------------------
alo@santra.UUCP (mcvax!santra!alo) Antti Louko
alo@hut.fi Helsinki University of Technology
alo@fingate.bitnet Computing Centre
alo%fingate.bitnet@cunyvm.cuny.edu SF-02150, Espoo
FINLAND
tel. +358 0 4514314
------------------
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 16 May 89 17:26:01 GMT From: ron@RON.RUTGERS.EDU (Ron Natalie) To: misc.security Subject: Re: System Security
UNICOS, at least as I saw it two years ago, had no pretense at security. It was quite easy to do things that would crash the machine, and only moderately more difficult to get unauthorized access to root. You might ring up your colleagues at NASA-AMES, who certainly have much more experience with UNICOS that I do. They're also pretty sharp on the security scene. -Ron
-----------[000051][next][prev][last][first]---------------------------------------------------- From: AIDE Hugh Hazelrigg <hazel%unm_la@lanl.gov> 18-MAY-1989 9:32:38 To: hobbit@pyrite.rutgers.edu
About a week ago someone posted an article to misc.security which had some info on where to find the "Orange Book." Well, someone named Danny at the Federal Information Center had never heard of the "National Computer Security Center [publications office]" (which was the name of the source in the posting), nor the Orange Book nor Rainbow Set. He sounded like he really wanted to help, but needed more information. Can you or anyone in m.s provide it? Thanks in advance. Hugh [Moderator note: "Dunno" -- can anyone else clarify for him? _H*]
-----------[000052][next][prev][last][first]---------------------------------------------------- From: nugent@anubis.uchicago.edu 18-MAY-1989 10:07:49 To: security@pyrite.rutgers.edu Cc: simsong@idr.cambridge.ma.us
Medeco patents each of their key blanks. The patents on the older keyways ran out a couple of years ago and blanks started showing up, which is one of the reasons that Medeco has moved into the Biaxial locks. I would be interested to know if the key you had copied had a round or a square shoulder end(the part you hold onto). I think all the older keyways had round keys. It is certainly interesting news if the Biaxial Medeco key blanks are available in spite of the patent infringement. Of course as people have pointed out, if you are good with a machinest's file or a milling machine, not having the key blank is not a problem. But that kind of person is difficult to keep out of a bank vault as well. Todd
-----------[000053][next][prev][last][first]---------------------------------------------------- From: rjg@sialis.mn.org (Robert J. Granvin) 18-MAY-1989 10:30:45 To: misc-security@uunet.uu.net
Please realize the whole point is that Medeco locks and keys aren't that they can't be duplicated, but that they are normally very difficult to do so. The vast majority of people wanting to make a copy won't go through the effort to find someone as you described, and if they did, they probably wouldn't have the same first time success rate. Doing so, depending on the environment where the key is intended for, may show criminal intent. You can't really say that about your normal household locks you get from the hardware store. On the other hand, picking a Medeco lock is again, significantly more difficult than other locks. Nothing is 100% guaranteed secure, but you can make the "average" criminal go somewhere else and leave you alone. This is generally the goal. The only way that you can prevent keys from being duplicated is don't put a keyed lock on a door, and don't distibute keys for that lock that doesn't exist. -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg
-----------[000054][next][prev][last][first]---------------------------------------------------- From: Clive Carmock <cca@cs.exeter.ac.uk> 19-MAY-1989 0:42:24 To: misc-security@ukc.ac.uk
For some time I have tried to have a duplicate Medeco key cut, which operates a key switch. The kwy switch is effectively useless to me until I get spare keys. It was part of a disused lift (elevator) car panel and was the SERVICE keyswitch. The panel was imported from the US from a company called GAL Elevators of (I think New York). The key bears the number R63 LF. I was told by a UK locksmith that the number meant nothing to him, but he did know that the final two letters were connected with the company/locksmith who issued the keyswitch. I wonder if anyone could throw some light onto this and tell me where I may be able to get spare keys cut. Thanks CLive Carmock (cca@expya.uucp OR cca@cs.exeter.ac.uk)
-----------[000055][next][prev][last][first]---------------------------------------------------- From: biocca@bevb.bev.lbl.gov (Alan Biocca) 19-MAY-1989 1:18:46 To: misc-security@ucbvax.berkeley.edu
Rekeying isn't difficult or expensive to do yourself, either. I recently bought a $20 kit for schlage rekeying at the local Home club. It comes complete with instructions and some tools, all you need is screwdriver and pliers. Re-keying requires that you have both new and old keys, so it works best if you have a collection of keys to pick from when rekeying. You could file a key and make a new one, too. There is a gauge included that could be used to determine when the filing had reached a new 'standard' depth. The kit also includes a large quantity of each standard pin size as well as replacement springs in case they get lost or lose their force. I've done fifteen or twenty locks now and since you exchange pins rather than lose them you can almost handle an indefinite number of locks. Eventually you'll run out of a particular size and have to buy more of them or a new kit. Comments by Alan K Biocca
-----------[000056][next][prev][last][first]---------------------------------------------------- From: *Hobbit* <security_request@pyrite.rutgers.edu> 19-MAY-1989 4:34:26 To: ???
An amazing number of replies came in. I have included a couple of the most informative for the benefit of anyone else who was curious. Hugh's question has been answered, in serious overkill fashion -- y'all can stop sending them in now, I'm drowning over here! Thanks to everyone else who passed on information... _H* **************** Date: Thu, 18 May 89 09:04:34 -0400 From: (Jeffrey A. Edelheit) <edelheit@smiley.mitre.org> <edelheit> Subject: Re: orange book To: AIDE Hugh Hazelrigg <hazel%unm-la@lanl.gov> The "orange book" is actually titled "Department of Defense Trusted Computer System Evaluation Criteria." It is a DoD standard (DOD 5200.28-STD) and is dated December 1985. The orange book (sometimes also called the TCSEC), is one of a number of publications put out by the NCSC in the so-called Rainbow Series. Each publication has a different color cover and all deal with some aspect of computer security. The "red book", also called the TNI, is the Trusted Network Interpretation of the TCSEC. There are also books on passwork guidelines, guide to audit, guide to discretionary access controls, etc. The best source is the US Government Printing Office. There may be one near you; otherwise, you can reach them at (202) 783-3238. "All prices include postage and handling" and "Use your MasterCard or VISA" (These quotes come from a GPO Catalog.) The telephone number I gave is for Washington, DC and is open from 7:30 am to 4:00 pm Eastern time. The GPO order # for the TCSEC is 008-000-00461-7 and costs $6.00. The GPO should also have other titles within the rainbow series for sale. Jeff Edelheit (edelheit@gateway.mitre.org) The MITRE Corporation 7525 Colshire Drive McLean, VA 22102 (703) 883-7586 **************** Date: Thu, 18 May 89 07:29:39 PDT From: faigin@aerospace.aero.org Subject: Re: orange book To: security@rutgers.edu The "Orange Book", also known as the Department of Defense Trusted Computer System Evaluation Criteria, is DoD Standard DOD 5200.28-STD. You should be able to get it via this number through the US Goverment Printing Office. As for the other "rainbow" books... the ones I have sitting on my desk are: Colour Number Title Lt. Green CSC-STD-002-85 Department of Defense Password Management Guideline Yellow CSC-STD-003-85 Computer Security Requirements Yellow CSC-STD-004-85 Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements Tan NCSC-TG-001 v.2 A Guide to Understanding AUDIT in Trusted Systems Red-Orange NCSC-TG-003 v.1 A Guide to Understanding DISCRETIONARY ACCESS CONTROL in Trusted Systems Red NCSC-TG-005 v.1 Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria Peach NCSC-TG-006 v.1 A Guide to Understanding CONFIGURATION MANAGEMENT in Trusted Systems Dark Red NCSC-TG-007 v.1 A Guide to Understanding DESIGN DOCUMENTATION in Trusted Systems Grey NCSC-TG-009 v.1 Computer Security Subsystem Interpretation of the Trusted Computer System Evaluation Criteria (if there are ones I am missing, I would like to know) In terms of ordering, I would check with the US Govt Printing Office, or directly with the NCSC. Their address is NCSC, 9800 Savage Road, Fort George G. Meade, MD 20755-6000. Daniel -- Work :The Aerospace Corp M8/055 * POB 92957 * LA, CA 90009-2957 * 213/336-3149 Home :8333 Columbus Avenue #17 * Sepulveda CA 91343 * 818/892-8555 Email:faigin@aerospace.aero.org (or) Faigin@dockmaster.ncsc.mil Voicemail: 213/336-5454 Box#3149 * "Take what you like, and leave the rest"
-----------[000057][next][prev][last][first]----------------------------------------------------
Date: 17 May 89 21:16:49 GMT
From: URSJ@MARISTC.Berkeley.EDU ("John Schlosser")
To: misc.security
Subject: Car locksFrom what I've seen, the "club" only blocks the steering wheel from turning more than a few degrees any way because of the way the club is attached. This works great if a would-be thief has the intention of driving away with your car, but what if he/she/it just wants to strip it bare of anything that's in it? A large metal pole that's attached to the steering wheel isn't going to do much good then, will it? John P. Schlosser (URSJ@MARISTC) Student Staff Programmer Marist College Computer Center .Nothing I say in any way reflects anyone's opinion other than my own. .I am not affiliated with THE CLUB's makers, distributors, advertisers or anyone else.
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 18 May 89 18:41:22 GMT From: hollombe@ttidca.tti.com (The Polymath) To: misc.security Subject: Re: car locks
} hi, have you heard of the latest lock for vehicles ... called the "Club".
Probably a little less secure than with the type of lock that runs from
the steering wheel to the brake or clutch pedal. (The "Club" just locks on
the steering wheel, making it difficult or impossible to turn completely
around).
I'd guess a large pair of bolt-cutters would get either one off in a few
seconds. (If they won't cut the lock, cut the steering wheel. Car thieves
aren't known for finesse).
--
The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil
Citicorp(+)TTI Carborundum
3100 Ocean Park Blvd. (213) 452-9191, x2483
Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe
-----------[000059][next][prev][last][first]---------------------------------------------------- From: goldstein%star.DEC@decwrl.dec.com (Andy Goldstein) 21-MAY-1989 0:17:31 To: misc-security@ucbvax.berkeley.edu
> The idea I am tring to present is that if a system was to use a modified > version of crypt(3) (and install it in the libaries) Well, the problem is that by virtue of this mail you've now announced to the world that you're running a modified crypt(3) (or might be). So all the crackers have to do is take your version of crypt along with your password file. Your best bet is to convince your users (by moral suasion or, preferrably, software) to not use dictionary words as passwords. - Andy Goldstein VMS Development
-----------[000060][next][prev][last][first]---------------------------------------------------- From: "Craig Finseth" <fin@uf.msc.umn.edu> 21-MAY-1989 0:50:59 To: shipley@tarantula.berkeley.edu Cc: security@pyrite.rutgers.edu
What problems will using a modified passwd des crypt function will create. I assume that you mean "modifed from UNIX" and not "modified from DES". wont this prevent the grabing of password files and 'grinding' on a local system. This wouldn't stop someone from compiling the grind program on your system and running it from afar. I suggest putting your effort into (1) creating a shadow password file and (2) making /bin/passwd reject "too-obvious" passwords. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 19 May 89 19:22:52 GMT From: lamaster@AMES.ARC.NASA.GOV (Hugh LaMaster) To: misc.security Subject: Re: Consensus on locks?
I have seen many postings on a variety of problems with so-called high security standard-cylinder-type locks. While no such lock is perfect, it would seem that there might be a consensus that some particular product line is the least likely to be easily picked or forced by garden- variety burglars, and may even slow down an expert. If there is such a consensus on a company/product line, I would appreciate knowing what it is. A sort of related question is: I have seen locks with automatic "dead bolts" - meaning, locks in which opening the door with a key from the outside (not in the handle) pulls back a full-sized spring loaded bolt, which closes when the door is closed. The obvious idea is to prevent "loiding" (I think this is the term...), and also to provide more resistance to forcing than the relatively narrow bars which are used on some locks for the same purpose. Does anyone know the availability of these locks and whether they have any advantage over the standard narrow bar type? (I am no lock expert, in case it isn't obvious :-) ). I assume that such a lock would have to be well lubricated to allow the torque of a key to open a large bolt, but what other disadvantages are there? Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117 [Moderator toss-in: The usual way manufacturers of spring-loaded latches prevent carding, loiding, sliding, whatever you want to call it, is to provide an extra latch piece that is pushed into the mortise edge when the door is closed, and engages a catch that prevents the main latch from being pushed in. These are well-known to, um, not work in many installations. The sure- fire way to lock the door is a dead bolt or better, but you can't just slam the door closed. If you're a chronic loser of keys, this could be good! _H*]
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 19 May 89 20:24:07 GMT From: rwb@viusys.UUCP (Rick Butland) To: misc.security Subject: Encryption Software For PC's
As the subject says, is anyone aware of a software package that will encrypt files on DOS? Actually, what's desired is the ability to compose a msg on a PC, encrypt it, and mail it to another PC user, where both PC's are attached to a Unix host. Most likely, though, rather than mail, the messages will just be uploaded/downloaded. Thanks in advance, Rick Butland (rwb@viusys)
-----------[000063][next][prev][last][first]---------------------------------------------------- From: Joe Wieclawek <jaw@sesun.jpl.nasa.gov> 22-MAY-1989 1:33:00 To: security@pyrite.rutgers.edu
An article in the 6 May 1989 'Los Angeles Herald Examiner' reports: Attorneys said yesterday they are negotiating a second plea bargain for computer hacker Kevin Mitnick, whose first offer to plead guilty was scuttled by a judge because it called for too little time in prison. Mitnick, 25, of Panorama City (CA) offered in March to serve one year in prison and to plead guilty to computer fraud and possessing unauthorized long-distance telephone codes.
-----------[000064][next][prev][last][first]---------------------------------------------------- From: heilpern@brl.mil 22-MAY-1989 2:00:37 To: security@pyrite.rutgers.edu
In theory, you can use any encryption you would like in place of the crypt command (or, for that matter, no excryption whatsoever.) The problem presented is this: All old excryptions will obviously be incompatable with the new encryption routine, so for every user on your system, you will have to erase their password and create another, using the new encryption method. (This can probably be accomplished by creating a program that is similar to 'passwd', but operates on a copy of the /etc/passwd file, give users, say, 2 days to 'install their future password', and after that two days, replace the login command and the /etc/passwd file.) However, if this is a new system you are setting up, things will be extremely easy for you!! --M.
-----------[000065][next][prev][last][first]---------------------------------------------------- From: Dr. T. Andrews <tanner@ki4pv> 22-MAY-1989 2:23:49 To: shipley@tarantula.berkeley.edu (Pete Shipley) Cc: security@pyrite.rutgers.edu
I suspect that you would be OK if you made the change to crypt(3), and assured that the few minor items mentioned below have been seen to. (a) Only the password encryption routine is affected. anyone using the standard setkey/encrypt package in the same module must be left unaffected! (b) You get ALL of the programs re-built and installed at the same time. That includes passwd(1), login(1), newgrp(1), su(1) wheel(1), wheelg(1), &c. (c) You have some magical way to get your users to (1) all be logged in when you make the change, and (2) get them to all change their passwords NOW. (d) You ferret out the local stuff which also depends on crypt(3) and re-build it. Someone has something which needs a password to run, and he didn't tell you about it. (e) Something at boot-up may want a password, too. Don't forget to fix it! (f) You replace your old back-ups with the old encryption in /etc/passwd and /etc/group and /etc/d_passwd and any other files with passwords. Summary (too late to do you much good:-) Considering the effort, and the danger, and the certainty that you will miss something important, I would advise that you give up the idea. Otherwise, you will likely be unhappy. Even if you think you are happy, what happens when you get the next version of the OS? Dr. T. Andrews, Systems CompuData, Inc. DeLand
-----------[000066][next][prev][last][first]---------------------------------------------------- From: Michael Stack <A01MES1@NIU.BITNET> 23-MAY-1989 5:25:27 To: "David F. Lambert" <LAMBERT@mitvma.mit.edu> Cc: Security Topics Discussion List <SECURITY@pyrite.rutgers.edu>
> ... I'm not sure > if RACF or other VM security package equivalents have this feature. "group logonids" are a standard feature of ACF2/VM and are intended to provide accountability for the use of VMs like MAINT. Michael Stack Northern Illinois University
-----------[000067][next][prev][last][first]---------------------------------------------------- From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 23-MAY-1989 5:52:25 To: RS@ai.ai.mit.edu Cc: security@rutgers.edu
Why use a 7/16" socket wrench and a butt set when you can just walk to the next network interface? That's the whole point of security; make it more difficult to break into you than to break into somebody else, and more difficult than its worth. ---simson From: "Robert E. Seastrom" <RS@AI.ai.mit.edu> Subject: Re: Telephone line security To: idr!simsong@garp.mit.edu Yep. A lot of good it will do you if someone should come along with a 7/16" socket wrench and a butt set. Try it. ---Rob
-----------[000068][next][prev][last][first]---------------------------------------------------- From: WHMurray@dockmaster.ncsc.mil 23-MAY-1989 6:18:04 To: security@rutgers.edu
>To be effective, the number of people who know a pw must be kept to a >minimum. The small department that I am associated with insures that >each member of that small group is told the new pw, verbally, in a low >voice. (I am unable to tell whether this posting is "tongue-in-cheek." I will assume that it is intended to be sincere.) In order to be effective a password must be known by no more than one person. In the kind of open systems in which we deal (i.e., with many privileged users), the only way to be sure that it is known to only one person is to use it only once. The solution to this dilemma, dealt with many times in this forum in One-time password generators. This mechanism also provides for the passing and withdrawing of high privilege, since, unlike a password, the generator can be returned. (The discussion by the "secure" installation where five people know the root password and another copy is kept in a lock box is too absurd to deal with. If a system is so unstable that it takes five people with privilege to keep it up, it cannot be said to be secure in any meaningful sense anyway, but if five people share the password any way, then how you protect and account for the use of any copy is not material.) William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
-----------[000069][next][prev][last][first]---------------------------------------------------- From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 23-MAY-1989 23:48:45 To: security@rutgers.edu
Date: Fri, 5 May 89 16:02:57 EDT From: vicka@vax.ftp.com (Vicka Corey) To: simsong@idr.cambridge.ma.us Subject: security Oops, that's a paper, not an RFC. Reference follows: ps. For the rest of the tcp-ip community... it's an excellent paper, and it isn't very long. As the add says, "if you only read one paper this year, make it _Security_Problems_in_the_TCP/IP_Protocol_Suite_, by S.M. Bellovin in the ACM Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989."
-----------[000070][next][prev][last][first]---------------------------------------------------- From: cme@cloud9.stratus.com (Carl Ellison) 24-MAY-1989 19:43:36 To: linus!misc-security@ursa-major.spdcc.com
You don't have to erase old encrypted passwords when you change algorithms -- just be prepared to accept either, for a while -- ie., use both algorithms to create two strings to match against the password file -- and if either works, the user is logged in. If it's the wrong one which worked, you can nag or threaten.... --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course)
-----------[000071][next][prev][last][first]---------------------------------------------------- From: nevin1@cbnewsc.att.com (nevin.j.liber) 24-MAY-1989 20:17:42 To: misc-security@att.att.com
|So all the crackers have to do is take your version of crypt along with |your password file. But what if the new version of crypt is not public (the source code does not exist on a publicly accessible machine, and the appropriate permission bits are set so that the executables are not readable, etc.)? Unless one is willing to apply cryptographic techniques to determine the algorithm (in which case you probably need more security than just password protection, anyway), this still seems like an improvement over using the standard crypt for passwords (assuming the new algorithm is sufficiently good, of course). -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
-----------[000072][next][prev][last][first]---------------------------------------------------- From: steve@polyslo.calpoly.edu (Steve DeJarnett) 24-MAY-1989 20:24:25 To: kerchen@iris.ucdavis.edu, security@pyrite.rutgers.edu
>Hmm, what's the use in using shell scripts if they can be changed by >whoever last used the root password? Or, do you keep these scripts off >line and just put them on the system when you need to make these checks? The version I use to check things lives in my bedroom at home. If these people can break into my house and modify the tape, then I guess I have larger problems than system security :-|. The fact that few people (until I sent this note out :-) knew that such scripts even existed makes it a little less likely that they'd be found (they also live so far down in the filesystem that I occasionally have trouble remembering where they are). When we do check the system, though, we either make a visual check of the scripts before running them, or bring my tape in from home. Of course, University security requirements aren't QUITE as stringent as those required by, say, the DoD. Steve DeJarnett Cal Poly San Luis Obispo steve@polyslo.CalPoly.EDU
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 23 May 89 19:48:27 GMT From: cme@cloud9.stratus.com (Carl Ellison) To: misc.security Subject: Re: password security
You don't have to erase old encrypted passwords when you change algorithms -- just be prepared to accept either, for a while -- ie., use both algorithms to create two strings to match against the password file -- and if either works, the user is logged in. If it's the wrong one which worked, you can nag or threaten.... --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course)
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 23 May 89 20:26:13 GMT From: hal@GATEWAY.MITRE.ORG (Hal Feinstein) To: misc.security Subject: very fast DES is near
I've just gotten the word that a substantially reworked version of DES will soon become public. The version eliminates the piple-line structure of FIPS 46 and replaces many of the bit picking that slows most computer implementations. I havn't been told how much of a speed up this will have over the FIPS 46 version of the algorithm. The new version has eliminated some of the "rounds" structure of the current algorithm and still computes the same DES process. Speculation is that it will make file and bulk based DES faster and less expensive and will provide a base for faster IC implementations. More as I find it out.
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 24 May 89 21:13:21 GMT From: gretzky@UNISON.LARC.NASA.GOV (Mr. Stanley Cup) To: misc.security Subject: password security
> You don't have to erase old encrypted passwords when you change
> algorithms -- just be prepared to accept either, for a while --
How about having both algorithms available for a "real short" time and do
this with them:
if (strcmp(new_crypt(reply ,salt),pass) == 0) {
/* all is ok, let 'em in */
}
else if (strcmp(crypt(reply, salt), pass) == 0) {
new_version_pass = new_crypt(reply,salt);
/* update the passwd file */
/* let 'em in */
}
else {
/* password was no good, do whatever */
}
After all of your users have logged in at least once, you then have all of
their passwords converted to the new algorithm without ever knowing what
their password is/was and the user will not know that anything was done
to the encryption algorithm for logging in.
-=>gretzky<=-
.mitch
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 25 May 89 13:17:10 GMT From: fred@DTIX.ARPA (Fred Blonder) To: misc.security Subject: Re: password security
You don't have to erase old encrypted passwords when you change algorithms -- just be prepared to accept either, for a while -- Or just silently store the new encryption. In fact, changing the encryption algorithm on a regular basis, combined with accepting either the current or previous encryptions, would be one way of implementing password aging, assuming you really want to do that. ---- Fred Blonder <fred@dtix.arpa> David Taylor Research Center (202) 227-1428
-----------[000077][next][prev][last][first]---------------------------------------------------- From: gwyn@brl.mil 31-MAY-1989 3:36:38 To: security@rutgers.edu
Not long ago I got inside word that AT&T had asked for a determination of the export status of their UNIX crypt routines, the outcome of which was essentially that individual approval would have been readily obtained, but not blanket "warehouse" approval. This seems pretty silly to me..
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: 31 May 89 03:45:16 GMT From: spaf@CS.PURDUE.EDU (Gene Spafford) To: misc.security Subject: Need list of names
For purposes of checking for weak passwords, I'de like to obtain a
list of common names (Al, Fred, George... Alice, Kathy, Susan...)
Does anybody have such a list online they'd be willing to share with
me?
Please e-mail -- don't post.
Thanks in advance!
--
Gene Spafford
NSF/Purdue/U of Florida Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |