|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1989)
DOCUMENT: Rutgers 'Security List' for March 1989 (96 messages, 47430 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1989/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- From: "Tarjei T. Jensen" <jensen%hsr.uninett@NORUNIX.BITNET> 2-MAR-1989 8:49:52 To: <security@pyrite.rutgers.edu>
Somebody did something like this at our place. I don't know what they did, but here is my suggestion of how I would do it: I would write a program that would write protect all directories. I know that I could use something like Xtree to do this, but I think that a program will give me more flexibility. I could for example make it leave some directories writeable (scratch files). I would also think of putting the unprotected files in their own partition (drive) on the hard-disk. E.g. dirve C protected and drive D unprotected and in addition perhaps make D small. I would also write a program that would unprotect a drive (for maintenance). These programs would probably make a nice little student project (or assignment). Lastly I would get a program that would reformat the drive without destroying the data. I've heard that one should do a low level format on a hard drive once every 6 to 12 months. I hope this sounds sensible.
-----------[000001][next][prev][last][first]---------------------------------------------------- From: "Kenneth R. van Wyk" <LUKEN@ibm1.cc.lehigh.edu> 2-MAR-1989 8:58:23 To: Security List <security@pyrite.rutgers.edu>
There are a number of products that are designed to do the sort of
thing that you're looking for. I've tried Pyramid's PC/DACS (Data
Access Control System), and it works pretty well if you install all
of the options (hard disk boot protection AND disk encryption).
You can set up individual users, with each one having access to
whatever directories and files that you choose. With the encryption
installed, it seems rather thorough; without it, it's child's play
to get around. Of course, the encryption adds a bit of overhead to
disk activities, but it's pretty reasonable. Pyramid Development
Corp. can be reached at (203)-524-9832.
I have no connection with Pyramid other than being a satisfied
customer.
Ken van Wyk
Kenneth R. van Wyk Calvin: Mom, I'm going to grow a LONG
User Services Senior Consultant beard like the guys in ZZ Top!
Lehigh University Computing Center Mom: That's great Calvin, do it!
Internet: <luken@Spot.CC.Lehigh.EDU> Calvin: Wow, I thought she'd put up more
BITNET: <LUKEN@LEHIIBM1> of a fuss than that!
-----------[000002][next][prev][last][first]---------------------------------------------------- From: GREENY <MISS026@ECNCDC.BITNET> 2-MAR-1989 20:57:51 To: <security@pyrite.rutgers.edu>
> We are about to install a lab with a number of hard drives that will support > training and general student use. When students have access, we would like > to make those programs and files...to be "locked" in some way. What kind of machine are we talking about here? Mac, IBM, etc... On the Mac, it's relatively easy to do -- just set the FILE PROTECT bit in the files that you don't want duplicated or moved (although it will let you TRASH them I think...). A utility such as MacSnoop, or FEdit will usually do the job (I know RESEDIT wont let ya....) As for a PC, well, you could set the HIDDEN bit on them to true so they dont show up in the directory, and then have a batch file call em...This ought to work (but seeing as how I use Macs, and rarely get on PC's...it might not...) Although I have had hidden directories, with the files showing and had batch files like that.... Hope this helps... Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
-----------[000003][next][prev][last][first]---------------------------------------------------- From: "Craig Finseth" <fin@uf.msc.umn.edu> 3-MAR-1989 19:25:03 To: security@pyrite.rutgers.edu Cc: jimkirk@outlaw.uwyo.edu
"Out of band" signalling is great, assuming that you have an out of band path. If you're one of the enlightened (:-) Emacs users, "obscure" sequences that "no one will ever type" are ordinary command sequences. Another important question is "where is the trusted path TO?" In the olden days when all terminals were hardwired to serial ports, you could follow a wire and know where it went. In the current trend towards Ethernet terminal servers, my wire goes to that box. A trusted path could only be guaranteed to that box, not to the host (at least until we improve the network protocols). Unfortunately, the current situation leads to the operating assumption that you don't have a trusted path. "Don't worry, be suspicious," is thus the motto of the day. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
-----------[000004][next][prev][last][first]---------------------------------------------------- From: eleazar!matthews@dartvax.dartmouth.edu (Jim Matthews) 3-MAR-1989 19:45:00 To: misc-security@rutgers.edu
>A real-life example in early November involved a so-called computer virus (a >self-replicating program spread over computer networks and other media as a >prank or act of vandalism), which nearly paralyzed 6,000 military and academic >computers. According to the MIT report on the worm this figure was derived from the infection rate at MIT (10% of MIT hosts were hit, and there are ~60,000 Internet hosts). Has any more credible estimate emerged? The 6,000 figure was a guess but it is becoming a fact by virtue of repetition. In fact, according to published reports the Computer Virus Industry Association furnished the FBI an estimate of $100 million in damages from the worm. The estimate was based on the 6,000 machine estimate and therefore postulates a cost of $16,700 per machine. We had around thirty machines infected here at Dartmouth but I don't think it cost us close to $500,000. Again, is there reason to believe these kind of estimates? Jim Matthews Dartmouth Software Development
-----------[000005][next][prev][last][first]---------------------------------------------------- From: gwyn@smoke.brl.mil (Doug Gwyn ) 4-MAR-1989 0:13:03 To: misc-security@uunet.uu.net
-[Moderator add-on: My impression was always that Cipher locks [electronic, -five bidirectional rocker switches in a big klunky box] were different from -Simplex locks [all mechanical, five buttons in a column or a circle]. Is -there some name crossover or am I confused? _H*] You're not confused; the reason I put "Cipher" in quotes is because they aren't really Cipher electrical locks, they're just called that around here (actually "cipher" without capitalization). I don't know how this misusage started, but probably it was similar to calling all tissues "kleenex". Simplex locks can be manipulated. Genuine electronic locks cannot, although I'm sure there are other ways to defeat them.
-----------[000006][next][prev][last][first]---------------------------------------------------- From: Will Martin __ AMXAL_RI <wmartin@st_louis_emh2.army.mil> 4-MAR-1989 0:29:44 To: Doug Gwyn <gwyn@smoke.brl.mil> Cc: misc-security@uunet.uu.net
Glad to hear that steam-tunnel exploration was common at many different universities. There must be some sort of common mindset amongst the particular student subculture that enjoys such things. Myself, I was a charter member of the "WUASS" - Washington University Artificial Spelunkers Society -- back in '63-'67 at Wash U in St. Louis. There were about 6 of us in that group. There may have been others doing it during the same timeframe, but we never ran into them. I'm sure people did it in the decades before we discovered the pastime, but they left no records that we knew of, either written or in verbal folk culture. I wouldn't be surprised if the activity stopped after we graduated, simply because that later period was one of campus unrest (building-burning, etc.) which would have led to tighter security that might have cut off the relatively easy tunnel access we enjoyed. Things might have loosened up again in the 70's and early 80's, though. Regards, Will Martin
-----------[000007][next][prev][last][first]---------------------------------------------------- From: jad@dayton.dhdsc.mn.org (John A. Deters) 5-MAR-1989 4:10:37 To: security@rutgers.edu
There is some name confusion going on here. We use both Cypher locks and Simplex locks in our stores. You're right about the (lack of) security of a Cypher lock -- I was trying to work in a store after the last person who knew the combination had left, and I had it open in under three minutes (using only a flashlight). The Simplex locks can be much more secure from the viewpoint of 'breaking' the combination, but seem to be physically weaker IMHO. Also, with the Simplex locks, visual surveillance of the combination can be a problem. And they can be defeated by the oldest trick in the book -- sales consultants who tape the locks open because they 'get in the way'. :-) -j
-----------[000008][next][prev][last][first]---------------------------------------------------- From: ron@ron.rutgers.edu (Ron Natalie) 5-MAR-1989 4:54:00 To: misc-security@rutgers.edu
Hobbit is right. Cipher locks are as he described. Five rocker switches run to a box usually above and inside the door. You can program a 4 digit sequence in them by these little patchcords inside the box. Simplex locks are purely mechanical which are programmed by opening them, putting in the old combination, pushing a plunger, entering the new combination, and then clearing it. BRL never had any Cipher locks that I knew about, only Simplex. The Simplex weren't really regarded as any more secure than the plain old Seargent key locks, key distribution was easier. Generally they were used for things like printout rooms and labs where they were used by a large class of people. The secure facilities were actually deadbolted and alarmed when not attended. Even when we used Cipher locks in the SCIF's at other jobs, they were used only when the room was attended inside anyhow. At night we turned on the alarm and spun the big ol' S&G lock on the door. What was amazing to me is the number of people who never bother to change the Simplex locks from the 2-4, 3 combo they all get shipped with. -Ron
-----------[000009][next][prev][last][first]---------------------------------------------------- From: christevt@wpafb_ams1.arpa 5-MAR-1989 5:37:23 To: "security" <security@rutgers.edu>
Just a quick comment about Doug Gwyn's comment about what happened at
Rice...this time regarding MIT hackers who decided to wander up the Chuck a
piece to a little business school called Hahvahd...
Not much happened, mainly because the group was too large...the Hahvahd
CPs saw this group of people wandering around suspiciously (at about midnight
or so) and immediately questioned them about why they were there, what they
were doing, etc...
The main point of all this is to show, once again, that not all
universities tolerate (and NONE, of course, OFFICIALLY approve of) hacking...
and probably especially when the hackers are from another school (who can
forget the great Hahvahd-Yale game where MIT won?!!!)...In general, Hahvahd
DOES NOT approve of MIT hackers...sigh...so what!
ET B ME
VIC
!
Victor ET Christensen "To the last I grapple with thee,
christevt@wpafb-ams1.arpa From Hell's heart I stab at thee,
christevt@p6.ams.wpafb.af.mil For Hate's sake I spit my last breath
christevt%amsp6.decnet@wpafb-ams1.arpa at thee!!!" ~ Khan
-----------[000010][next][prev][last][first]---------------------------------------------------- From: Fred Blonder <fred@brillig.umd.edu> 5-MAR-1989 9:37:08 To: Jeff Makey <Makey@logicon.arpa>
The /dev/passwd could be made write-only. (well, write and compare only.) If it were implemented properly in hardware it could emulate what the Unix one-way encryption is trying to do. In fact it wouldn't need to store the passwords in encrypted form if you could trust the hardware. It would just need to answer a request of the form: "Is this uid/password combination valid?" Presumably it would have some built-in delay and maybe an alarm it could ring if too many invalid attempts were made in a short time. ... would no doubt be subject to its own special class of attacks. Well, the only weakness I can see here (other than a hardware attack, in which case all bets are off anyway) is if someone emulates root and changes someone else's password, which can be done in "standard" Unix already. In fact, the /dev/passwd thingy would be slightly better against even this attack, because the cracker wouldn't be able to restore the old password to clean up after the fact. ----- Fred Blonder Fred@Mimsy.umd.edu uunet!mimsy!fred
-----------[000011][next][prev][last][first]---------------------------------------------------- From: zeleznik@cs.utah.edu (Mike Zeleznik) 5-MAR-1989 9:45:39 To: security
On the subject of reverse authentication (proving to the user that they
are talking to the system), something like the Security Dynamics SecurID
card can provide this. A displayed number on the card changes every so
many seconds; to authenticate you simply type in the current number and
the system can authenticate you since it is time synced. By then
requiring the system to provide the NEXT number, you can compare it with
the next one on your card, thus being assured you are talking to the
actual system.
If the Racal-Guardata product would simply allow the response from one
challenge to become another challenge (rather than forcing a random
challenge), then I think it also could provide reverse authentication.
System issues challenge, you type response. Then your card calculates a
response from that response, which the system must also do, thus proving
who it is. Since each challenge/response is unique, this seems immune
to replay and as safe as the original challenge/response was.
Michael Zeleznik Computer Science Dept.
University of Utah
zeleznik@cs.utah.edu Salt Lake City, UT 84112
(801) 581-5617
-----------[000012][next][prev][last][first]---------------------------------------------------- From: gmz@pbhyg.pacbell.com (Gerry Zeitlin) 5-MAR-1989 12:32:12 To: misc-security@ames.arc.nasa.gov
According to conversations I had last fall with Bob Oechsler, a radio journalist in the Baltimore area, two EMP barges - Empress I and II - were actually deployed near the Patuxent River Naval Air Station and in the Chesapeake Bay. They may have been responsible for several calamities, including the destruction of millions of fish, the irreparable damage to the piers of a new bridge which has now been permanently closed, and the explosion of a Cessna 182 as it flew over one of the barges. The pilot of the Cessna was killed. His family hired a salvage firm to dredge for the remains of the airplane, but no debris was ever found. When I spoke to him, Oechsler was pressing for Congressional action on this affair. He probably wouldn't mind my mentioning his address, which is 136 Oakwood Rd., Edgewater, MD 21037. Gerry Zeitlin 415-841-5910 well!gmz
-----------[000013][next][prev][last][first]---------------------------------------------------- From: (Stephen Tihor) <TIHOR@acf6.nyu.edu> 5-MAR-1989 12:42:44 To: <security@pyrite.rutgers.edu>
Glenn is right in that password length and lifetime can probably be traded back
and forth holding some metric of security constant. If one of my users
complains about our relatively long password lifetimes I offer them a double
for double deal on their password:
twice the lifetime for twice the minimum length.
Glenn is raising an interesting human interface issue when he disparages VMS's
password set of {A-Z0-9$_}*36 for not including random punctuation since the
space of possible inputs is about the right size (informationally speaking) to
collapse into an 8 byte hashed password. [Various studies I have seen quoted
assert that english text has 2-4 bits of real information content bet letter
because of its high redundancy. A good citation would be appreciated.]
This more realistic than the otherwise plausible idea of taking eight ASCII
characters typed in at a terminal. Most terminals require contortions or
surgery to generate many of the possible characters and thus most passwords
will fall in a very restricted portion of the possible space.
[Still a large one but not as large as possible or even I would contend
desirable.]
Is it is better to ask for fewer characters from a wider range or more
characters that people are likely to enter?
That sounds like an interesting problem for some student in a human factors
program to consider.
The question of how many characters people can type without visual feedback and
maintain a low error rate also enters into it. All in all I am suprised
someone hasn't done a thesis on it.
-----------[000014][next][prev][last][first]---------------------------------------------------- From: Dr. T. Andrews <tanner@ki4pv> 6-MAR-1989 11:06:48 To: security@pyrite.rutgers.edu Cc: KARYN@nssdca.gsfc.nasa.gov
) ... Congressman from California spoke about a proposed law, HR 55, ) which would specifically make it a crime to prance about in others' ) computer areas ... The problem with such laws is that they are generally made by congress. I would not trust congress to formulate a law which was both useful in prosecuting those cases which I would want prosecuted, and not applicable in cases where I would not want it to apply. Consider that sending e-mail is dangerously close to "prancing about in others' computer areas", as is news. As for control messages (eg: sendsys, newgrp, rmgrp), well, I'd sure hate to pay a lawyer to try the case. Dr. T. Andrews, Systems CompuData, Inc. DeLand
-----------[000015][next][prev][last][first]---------------------------------------------------- From: "Dennis G. Rears (FSAC)" <drears@ardec.arpa> 6-MAR-1989 11:26:48 To: KARYN@nssdca.gsfc.nasa.gov Cc: security@rutgers.edu
>Also this law would allow civil cases to recover damages from the
>creator of such an item...
You don't need a specific law to collect damages. It's already
covered under existing tort law. Do you mean creator or
distributor? If you mean creator, you will have to prove that he
knew or should have known that it could have been released without
his permission or knowledge. What if he publishes it? You get into
free speech problems. I hope you mean the distributer.
I agree something should be done. DON'T COMPLETELY RELY ON LEGAL
REMEDIES. They normally don't work. The system is screwed up
enough as it is.
Dennis
--------------------------------------------------------------------------
Dennis G. Rears
ARPA: drears@ac4.pica.army.mil UUCP: ...!uunet!ac4.pica.army.mil!drears
AT&T: 201-724-6639 USPS: Box 210, Wharton, NJ 07885
Work: SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806
--------------------------------------------------------------------------
-----------[000016][next][prev][last][first]---------------------------------------------------- From: *Hobbit* <hobbit@pyrite.rutgers.edu> 7-MAR-1989 18:24:36 To: security@pyrite.rutgers.edu
Some of you have asked about archives and such. During the great worm upheaval, pyrite.rutgers.edu didn't have anonymous FTP turned on. At long last I've installed the fixed ftpd and placed the latest archives in /security/security.3 -- there are other files of possible interest there too -- for internet folks to freely swipe. If you need a different format and can't create it on your own, let me know and I'll see what I can do for simple fixes. I won't talk about the continual backlog problem that makes all the messages two weeks out of date... sigh.. _H*
-----------[000017][next][prev][last][first]---------------------------------------------------- From: "David.J.Ferbrache" <davidf@cs.heriot_watt.ac.uk> 8-MAR-1989 7:15:34 To: security
This request has appeared on the bitnet virus-l mailing list, and has
been crossposted to the appropriate comp.sys groups and to comp.risks.
I apologise for any readers who receive duplicate copies.
-------------------------------------------------------------
A review of the threat posed to the security and integrity of
microcomputer systems posed by self-replicating code segments
-------------------------------------------------------------
I am in the process of compiling information on existing computer viruses,
with a view to the production of a technical paper reviewing the threat
to system security posed by both present computer viruses and likely
future developments.
To this end I would be very grateful for information on individual
infections, preferably detailing the symptoms observed, damage caused and
disinfection techniques applied. Naturally I am also interested in details
of the operation of the viruses, although I appreciate the reticence shown
by infected parties to disseminate any details of virus operation, on the
basis that it could lead to development of further viruses.
The technical report is part of a Doctoral research thesis in computer
security, and will be available in late May. Distribution of the technical
report will be restricted to people who have a legitimate interest
(ie systems managers, commercial concerns, research), as I expect to
review the techniques exploited by viruses in a fair degree of detail at
the BIOS/DOS interface level. The report will consider the techniques used by
virus to duplicate, the ways in which viruses gain control of the computer
system, the camouflage techniques adopted and a brief overview of the
existing computer viruses. Finally the report will consider the likely
development of the threat from viruses, and how this developing threat
can be addressed by protective software in both virtual and non-virtual
machine operating environments.
At the moment I know of the following viruses:
IBM PC MS/DOS
1. Lehigh variant 1 and 2 2. New Zealand (stoned)
3. Vienna (Austrian, 648) 4. Blackjack (1701, 1704)
5. Italian (Ping Pong) 6. Israeli variant 1 (Friday 13th, 1813,
PLO, Jerusalem), variant 2, variant 3
(April 1st), variant 4
7. Brain (Pakastani) and variants 8. Yale
Also potentially variant of the Rush Hour and VirDem viruses developed
during the CCC's work on viruses.
APPLE MAC
1. NVir variant A and B, Hpat 2. Scores
3. INIT 29 4. ANTI
5. Peace (MacMag)
APPLE II
1. Elk
AMIGA
1. SCA 2. Byte Bandit
3. IRQ
ATARI ST
1. Boot sector 2. Virus construction set viruses
Mainframe OS worms
1. Internet worm 2. DECNET worm
2. BITNET Xmas chain letter
I would be grateful for any information on these, or any other viruses.
Reports of infection may be given in confidence, in which case they will
only be used as an indication of geographical distribution of infection.
A summary of known viruses, their symptoms, geographic distribution and
known disinfection measures will be posted to the list as soon as
sufficient information is available to prepare an interim report.
As part of the paper I will also be reviewing the effectiveness of viral
disinfection software, and would thus be interested in details of any
software you use, its effectiveness, and availability.
Thanks for your time!
For those interested here is a summary of a few of the virus reports published
on virus-l and usenet,
Subject, author and date Virus Virus-l issue
THE AMIGA VIRUS - Bill Koester (CATS) SCA LOG8805
comp.sys.amiga, 13 November 1987
New Year's Virus Report - George Robbins IRQ
1 January 1989, comp.sys.amiga
The Elk Cloner V2.0 - Phil Goetz ELK
26 Apr 1988
THE ATARI ST VIRUS - Chris Allen ATARI ST
22 March 1988, comp.sys.atari
Features of Blackjack Virus, Otto Stolz BLACKJACK v2.24
24 Jan 1989
Comments on the "(c) Brain" Virus BRAIN LOG8805
Joseph Sieczkowski, Apr 1988
Brain and the boot sequence, Dimitri Vulis BRAIN v2.5
5 Jan 1989
The Israeli viruses, Y.Radai ISRAELI LOG8805
2 May 1988
VIRUS WARNING: Lehigh virus version II LEHIGH v2 v2.35
Ken van Wyk, 3 Feb 1989
The Ping-Pong virus, Y.Radai ITALIAN v2.18
17 Jan 1989
Known PC Viruses in the UK and their effects MOST PC v2.23
Alan Solomon, 1989
Yale Virus Info, Chris Bracy, YALE LOG8809a
2 Sep 1988
New Macintosh Virus, Robert Hammen ANTI
comp.sys.mac, 7 Feb 1989
Hpat virus-it is a slightly modified nVIR HPAT
Alexis Rosen, comp.sys.mac, 7 Jan 1989
INIT 29: a brief description, INIT 29 v2.18
Joel Levin, 18 Jan 1989
A detailed description of the INIT 29 virus INIT 29 v2.30
Thomas Bond, 27 Jan 1989
The Scores Virus, John Norstad SCORES LOG8804
info-mac digest, 23 Apr 1988
Macintosh infection at Seale-Hayne College TSUNAMI LOG8808d
Adrian Vranch, 8 July 1988
DEFENCE DATA NETWORK MANAGEMENT BULLETIN, DECNET (see also v1.59a)
50, 23 Dec 1988,
The internet worm program, an analysis INTERNET
Gene Spafford, Nov 1988
I apologise for any researchers whose articles I have not cited, in what is
currently an incomplete list of references. Hopefully, this article
will be of some use in providing a general list of viruses which have
affected computer systems in the past.
Thanks for your time, and I look forward to any information you can
supply me with.
Dave Ferbrache Personal mail to:
Dept of computer science Internet <davidf@cs.hw.ac.uk>
Heriot-Watt University Janet <davidf@uk.ac.hw.cs>
79 Grassmarket UUCP ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ Tel (UK) 31-225-6465 ext 553
-----------[000018][next][prev][last][first]---------------------------------------------------- From: ron@ron.rutgers.edu (Ron Natalie) 8-MAR-1989 14:00:31 To: misc-security@rutgers.edu
In addition, SIMPLEX had a line in some of their sales literature to the effect that "10,000 possible combinations makes guessing to right one a million to one." We should send their marketing department to Prob 101. -Ron
-----------[000019][next][prev][last][first]---------------------------------------------------- From: 34AEJ7D@CMUVM.BITNET 8-MAR-1989 14:13:03 To: Security Digest <SECURITY@pyrite.rutgers.edu>
An area firm has an office area separated from the factory floor by large windows. Recently, The management thereof decided to enhance the security of their office area, so they installed bullet-proof glass in those windows. The trouble is, the windows are set in a wall made of nothing more than 3/4" plywood and 2x2's. Thus they have given themselves the reassuring *appearance* of increased security, without actually increasing their physical protection one whit!
-----------[000020][next][prev][last][first]---------------------------------------------------- From: Gary J. Rosenblum <rosenblg@cmcl2.nyu.edu> 8-MAR-1989 14:21:19 To: security-request@pyrite.rutgers.edu
I'm not sure if this has been talked about here before, but I was starting to add the code to sendmail (I'm running MORE/bsd from Mt. Xinu, sendmail version 5.61) to log the IP address and socket # on smtp connects. This was part one in a general beefing up of security and logging capabilities. It dawned on me that this was done before - and indeed, many other patches to different programs/daemons have been made by many people. I was wondering if it was possible for people to post these mods (as diffs, or whatever) to the mailing list. I know that there might be some licensing problems, etc. This would free my time, and others, from reinventing the wheel. Thanks. Gary J. Rosenblum UNIX Systems Manager rosenblg@nyu.edu New York University gary@nyu.edu [Moderator add-on: I would have just pointed him at ucbvax for the sendmail distribution, but there may be other things that he needs. In any case, please mail things to him, *NOT* the Security list... _H*]
-----------[000021][next][prev][last][first]---------------------------------------------------- From: nugent@anubis.uchicago.edu 8-MAR-1989 14:33:04 To: *Hobbit* <hobbit@pyrite.rutgers.edu> Cc: security@pyrite.rutgers.edu
> I believe that these are the biaxials ..... A master key for this > system would have two cuts right next to each other that would address > either offset..... Actually one problem with the Medecos is that within a given master key system (typically a building), all of the pin rotations are the same for all of the changes. If you have the lowest key to, say the garbage room, you know the pin rotations to the grandmaster key which opens all doors. Because of this, the Medecos are only marginally better than other precision locks at preventing the usual university problem, which is a student adding a little solder to his office/dorm key and using a file to turn it into a master key. It probably belongs in RISKS, but I can't help commenting that when the Biaxials first came out, the Medeco keying software had some problems with cross-keying, with the result that one of our office keys was also a submaster for a different series....that student had fun! Todd
-----------[000022][next][prev][last][first]---------------------------------------------------- From: nichols@cbnewsc.att.com (robert.k.nichols) 8-MAR-1989 14:35:16 To: misc-security@att.att.com
Some time ago I computed 1152 (as I recall) as the number of possible combinations -- not exactly what is implied by the "thousands of possible combinations" claimed by the Simplex folks (recently I saw some blurb that claimed "more than 2000" combinations). Incidentally, if (through psychoanalysis of the user) you suspect a "complex" combination involving 3 buttons simultaneously, your guessing job is greatly reduced. There are only 10 such 3-button sets, each with only 2 other buttons to consider. There IS a way to generate some additional combinations, although it violates the instructions of the manufacturer to "remove your fingers from the buttons before turning the knob," risking damage to the lock if you're not careful when opening it. At the end of the sequence, an otherwise unused button can be pressed lightly, just to the point of increased resistance, and HELD THERE as the knob is turned. Such a combination is distinct both from pressing the button all the way and from not pressing the button at all. The basic principles for setting/changing such combinations still apply: set the combination using the same actions you're going to use to open the lock; to change the combination, press the present combination and, while holding the final button(s) activate the "change" slide. It is possible to detect such combinations through manipulation and determine the buttons involved, but such combinations would confound the unaware. It never ceases to amaze me the way these very useful locks are mis-applied (largely due to mis-information supplied by the manufacturer). The locks are primarily suited (at least in my mind) to preventing casual entry to a restricted area, provided that the location of the lock is such that anyone attempting manipulation would be immediately observed and challenged. -*- -*- -*- Now that I have located the papers with my old calculations, I find that the actual number of combinations for a Simplex lock is 1082 (even worse than the 1152 I remembered). Just for kicks, I calculated the effect of the "trick" I mentioned (lightly pressing some of the unused buttons and holding them while turning the knob). There are a total of 2163 combinations if you allow this. Perhaps this is what the manufacturer had in mind when claiming "greater than 2000" combinations, but the operating instructions expressly forbid doing this. What puzzles me is why the lock wasn't made with 6 buttons instead of 5. The number of combinations then rises to over a million (without "tricks") and security against manipulation is also improved, at least for combinations that use all the buttons. [Moderator add-on: The above-mentioned "trick" is Simplex's "high-security- mode", which in theory they only point out to their high-muckymuck military customers. Years ago at a locksmith show I had one of the Simplex reps set "some random combo" on one of their demos to see if I could open it; he used one of these and I couldn't get it open at the time, although I rolled out of bed with the answer the next morning... _H*]
-----------[000023][next][prev][last][first]---------------------------------------------------- From: bobd@nisca.ircc.ohio_state.edu (Bob Debula) 8-MAR-1989 20:52:31 To: misc-security@cis.ohio-state.edu
Does anyone know of a public domain or inexpensive encrytion/decryption
package written using the NBS standard for IBM's MVS or VM operating
systems? Please e-mail me directly. Thanks for your help.
--
-------------------------------------------------------------------------------
Bob DeBula | Internet: debula-r@osu-20.ircc.ohio-state.edu
The Ohio State University |
| Disclaimer: These are my views, not the U's
-----------[000024][next][prev][last][first]---------------------------------------------------- From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 20:57:15 To: security@pyrite.rutgers.edu
It has often been said that DES *could* be broken by brute-force using lots of Cray-2 time and so on, and that the NSA caused the DES' key to be just short enough that they could break it but nobody else could. It appears now that such networks of workstations, fiddling in their "spare time" might also be able to pull off the same trick. Having not studied the DES in great detail yet, how easy is it to increase the key to 64 bits or more? Do the key scheduling tables need lots of work to derive? I heard once that the research behind parts of the algorithm were still classified. RSA keeps sounding better and better, if it could only be made reasonably quick. T. Okamoto proposed a much faster method that unfortunately results in ciphertext much larger than the plaintext (3:1); has this method been discredited yet?
-----------[000025][next][prev][last][first]---------------------------------------------------- From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 21:38:57 To: security@pyrite.rutgers.edu
I suppose the following possibilities exist regarding lost keys --
1. Permanently lost. In a field, down a rain gutter, dropped in
curing cement, accidentally thrown out with the trash. Obviously
no concern about how they're marked.
2. Lost, then found by an honest person who returns them.
3. Lost, found by an honest person who decides calling is too much
bother, or that mailing them to the address is too much bother.
Finder throws them away.
4. Lost, found by a dishonest person who would like to burgle you
but is put off by the lack of a usable address.
5. Lost, found by a dishonest person who is both clever and intent
on using the key(s).
That last, and probably least likely, is what worries me. Given just phone
number, what can be done?
1. Sequential search of the phone book. Not too likely, even here in
Laramie :-)
2. Call Phone company and trick them into giving customer name and
address, or just even name. I've heard varying stories on this such
as claiming you got billed for a long-distance call to that number
and wanting to know name & address to jog your memory before really
getting angry at the company; or posing as a telco employee who needs
address to work on the line. Bribes might work well too if you know
the right people. Telling the truth might even work ("I found this
key with the number...").
3. There may be on-line ways to get this info, legitimately or otherwise.
4. There may be published cross-references (or maybe I'm thinking of street
number back to name).
5. Call the phone number and ask for a street address so a free trip to
Las Vegas can be awarded (YOU may not fall for this, especially if you
KNOW you recently lost your key, but what about your 13-year old son?)
Variations include long-lost cousins, and so on.
Clearly, using a work number as described reduces possibilities. However,
some companies may be more lax about giving out phone information or lists
than THE phone company, and the list may be small enough to make a sequential
search feasible.
Given just a PO box number --
1. Walk up to box, peek in window (if windowed) to try and find a readable
name. Go to phone book. Even if you have an unlisted number or use
your PO box in the phone book, there are other publications in the
county library that may list your name and address given name. County
records might also be a source.
2. Get the street address from the window jockey (may involve fast talk
and/or bribe). I had to give this when I got my box in the first place.
I don't know what the rules are on the USPS giving out this info or what
they want it for in the first place.
The only really safe thing to do is mark keys with somebody else's identity
such as a trusted friend or a security service bureau. Or don't mark them,
and if you lose one, either don't worry or re-key.
Disclaimer -- I do not mean to imply that USPS or telco employees accept
bribes, or to defame them in any way. Just considering possibilities, and
you have to admit it must happen even if only infrequently.
-----------[000026][next][prev][last][first]---------------------------------------------------- From: Steve Lesh (ISC | howard) <lesh@brl.mil> 8-MAR-1989 22:43:41 To: security-request@pyrite.rutgers.edu
If anyone has or knows where I can get a copy of the security programs in the book UNIX System Security by Patrick Wood & Stephan Kochan, I would appreciate hearing from you. I have the book but would like to avoid typing all these programs. Thanks in advance, Steven Lesh
-----------[000027][next][prev][last][first]---------------------------------------------------- From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 22:52:53 To: security@rutgers.edu
I have been reading up on DES and RSA encryption. I have a question that
may or may not point out my ability to read :-)
Let's take public-key encryption as typified by RSA. It is a "block" cypher
in that any large message must be broken into a set of small pieces, then
each piece is separately encrypted. For example if you have a 200-digit
key, each piece should be no larger than 200 digits. Let's say I want to
send the message --
DO NOT (block 0)
DELETE (block 1)
FILE 1 (block 2)
If I encrypt these and send them to the destination, but the first block
simply gets lost, the resulting message is quite different! An active
eavesdropper will not be able to decypt them, but if he wants to be
mischevious (at the expense of possibly exposing himself) he could,
knowing my block length (after all the key is public), just drop a block.
Likewise, upon gathering several messages I've signed, he could mix and
match blocks, and end up with something that I have "provably" signed
(since each block was signed) but is gibberish or by bad luck damaging.
The latter is possible because he has access to both the ciphertext and
plain text (by decrypting using my public key) and could "cut and paste"
previously received encypted blocks. Unless I'm reading things wrong,
RSA can only prove you signed a block, not the entire document.
Am I missing something in the algorithm, that "binds" blocks in some way
to prevent this, or is there an underlying assumption that external
means will be taken to glue the blocks in some way? Clearly you could
include block numbers inside each block to ensure block sequence and
reception of all blocks, but this does not solve the issue of authentication
of signed messages (which could still be cut-and-pasted), and it adds more
overhead (though cheap overhead for RSA where blocks are large, this is
bad news for DES where the blocks are only 64 bits).
-----------[000028][next][prev][last][first]---------------------------------------------------- From: smiller@cs.umn.edu (Steven M. Miller) 9-MAR-1989 11:08:26 To: misc-security@rutgers.edu
I'm looking for a "callback" program. i.e. a utility that will when a user dials into a computer and logs in over a phone line he is automatically logged out and the computer phones the user. Does anyone know of such a program for Unix machines? Preferably PD, but I will pay for one too. Thanks, -Steve -- -Steve Miller, U of MN
-----------[000029][next][prev][last][first]---------------------------------------------------- From: James (J.G.)Borynec <BORYNEC@bnr.ca> 9-MAR-1989 11:19:56 To: security@rutgers.edu
Do not believe that shrink wrap is the safest way to go to avoid viral infection. In the last week, we have been hit by two garden variety nVIR viri. Both came from reputable companies. In fact, one came on the distribution disks for our Texas Instruments MicroExplorer. TI phoned us about it, and sent a virus remedy however. I can control what software I get from other people that I know, but it seems to me that I can't control, or even find out what precautions were taken before the shrink wrap was put on. Cheers ... J. Borynec Borynec@bnr.ca.bitnet (Bell Northern Research)
-----------[000030][next][prev][last][first]---------------------------------------------------- From: eugene@eos.arc.nasa.gov (Eugene Miya) 9-MAR-1989 11:29:29 To: misc-security@ames.arc.nasa.gov
>How can one defend against a virus unless they have one to look at?
Yes there are very legit reasons for writing worms.
You see the problem is that the biological analogy has overpowered your
understanding of some of these programs. That is all they are, programs.
At one time writing compilers and operating systems had a mystic "above"
other programs. Then it was learned mere morals could do them (well,
more mortals at least). This is even less so with worms and viruses
which are much simpler.
These programs are destructive in some way only because of intent.
Programs of this structure can be found in system daemons, and they
will become more prevalent as we increase our use of networks,
distributed systems, remote servers, multiprocessors, and so on.
The seeds of these issues could be found on Schoch et al's CACM paper on
Worm Programs. When they were testing on the Xerox research net,
were they stealing other people's evening cycles? Its gets worse.
The problem is sort of like the popularity of the old TV show:
Mission Impossible. They did neat things technically, but no one
questioned whether they were doing legal or right things. The show went
out of fashion during Watergate, perhaps during a fit of conscience.
But now in the days of Lt. Col. Ollie North, the show reappears.
The same sort of goes with computer security.
Proposed laws are written by people who do not completely understand
these issues. Security experts don't completely understand. It's
interesting to note how many "experts" can't write a simple Trojan horse
shell script.
Remember they are just programs. Their harm is subject to human
intepretation, and machines will have an even harder time discriminating.
Will virus killing programs kill daemons by mistake?
One last note: a short story. I work on some machines which are very fast.
During the testing of one, I had a script of a workload which "got away."
The point was to run continuously by forking a new child and dying.
I tried killing it, but before I could, it always forked. This happened
about 2 weeks before Morris. The initial shock (panic) hit me: multi-million
dollar machine running amuck. If Morris did accidnetly lose his program,
I think I know how he felt. I was at least able to kill mine.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Post follow ups. Contribute to network noise."
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 9 Mar 89 18:57:20 GMT From: lesh@BRL.MIL (Steve Lesh, ISC | howard) To: misc.security Subject: security validation programs
Thanks to all for the rather amazing quantity of responses to my request for the security validation programs mentioned in the Kochan and Woods book on UNIX System Security. I NOW HAVE THE PROGRAMS. I think I responded to all requests to forward these programs. I would be willing to act as a manual file server providing things don't get out of hand. Anyone knowing anything about the legal implications of posting these programs to uunet archives might want to look into archiving the above. There certainly seemed to be a lot of interest! Thanks again for the all the responses to my request.
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 10 Mar 89 06:22:37 GMT From: scarter@CAIP.RUTGERS.EDU (Stephen M. Carter) To: misc.security Subject: Re: appearances vs. actualities
>so they installed bullet-proof >glass in those windows. The trouble is, the windows are set in a wall >made of nothing more than 3/4" plywood and 2x2's. I don't know what they make out on the factory floor, but if it has anything that uses robot arms, milling machines, and the like, *I* would feel a lot better on having that nice thick and hefty glass around me than standard plate glass. A small metal object can be thrown a fair distance coming out of some machines. If that object hits a large plate glass area, watch out. They may not be more secure, but a lot safer.
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 11 Mar 89 21:03:31 GMT From: nichols@iexist.UUCP To: misc.security Subject: Re: Simplex locks
WRT using fluorescent dye to determine used vs. unused buttons, I
suspect that a solution of ordinary laundry detergent would be the most
readily available. The brighteners glow brilliant white under UV.
For Simplex locks, however, who needs it!? It only takes 1 to 2 minutes
of manipulation to identify used and unused buttons, with no apparatus,
power source, or even ambient light required. In the (uncommon) event
that all the buttons were used, there are 541 combinations to try. If
less, the math is definitely on your side.
#buttons #comb
5 of 5 541
4 of 4 75
3 of 3 13
Bob Nichols
nichols@iexist.att.com
-----------[000034][next][prev][last][first]----------------------------------------------------
Date: 12 Mar 89 17:02:48 GMT
From: kdante@NOTE.NSF.GOV ("Katherine J. Dante")
To: misc.security
Subject: Re: Shrink wrap not safe- yet another virus storySince computer stores have the ability to re-shrink wrap software and allow customers to try the software out, I am not sure that shrink wrapping does any more than assure you that the price on the wrap is the price the store wants to charge for whatever is in the wrap. You certainly cannot tell whether you are getting all the disks/documentation that the manufacturer intended. And you have no assurance that some smart-aleck didn't plant a virus while "checking out" the program with his own disk.
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 12 Mar 89 18:14:42 GMT From: rjg@sialis.mn.org (Robert J. Granvin) To: misc.security Subject: Security "journals"
Quite some time ago, someone posted an address and telephone number of
where to locate the "Rainbow Volumes". Would some kind soul email me
that information?
Thanks.
--
Robert J. Granvin "Mueslix: A natural blend of oats, barley,
National Information Services octopi, Toyotas, cement and small furry
rjg@sialis.mn.org animals too slow to escape our field
{amdahl,hpda}!bungia!sialis!rjg agents." --'corsair'
-----------[000036][next][prev][last][first]---------------------------------------------------- From: haynes@ucscc.ucsc.edu (Jim Haynes) 14-MAR-1989 11:54:13 To: misc-security@ames.arc.nasa.gov
>A year or so back, users of the Cambridge University Computing Service were
>hit by a password grabber which infested the BBC Micros used as terminals.
Well, sure, if you're using micros as terminals, and the micros are
publicly accessible or shared, then there are all kinds of possibilities
for security cracking.
In our environment the users who use public terminals seem to like the
personalized password prompts, both for security and because they can be cute.
All we claim for them is that they will sometimes defeat the most
simple-minded password grabber programs; and that was the kind we tended to
see often in the past. Now the method of attack has shifted to modern
high-performance password guessing programs.
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
-----------[000037][next][prev][last][first]---------------------------------------------------- From: "John P. McNeely" <JMCNEELY@utcvm.bitnet> 14-MAR-1989 12:14:13 To: security@rutgers.edu
There are two other books I know of:
1) Dr. Fred Cohen offers a book entitled 'Computer Viruses'. It
is based more on the theory and mathematical side of viruses. The
book is very interesting. In order to get the book you must
first contact Fred himself:
Fred Cohen
c/o Advanced Software Protection
PO Box 90069
Pittsburgh, PA 15224
The book costs $20.00, which is supposed to include mailing expenses,
with checks payable to Advanced Software Protection.
2) Recently, Abacus publishing has released a book which is causing
some disturbance among the computer virus "authorities";
the book is entitled "Computer Viruses - A High-Tech Disease".
This book gets extremely detailed whith actual code for various
viruses on different systems. I'm still waiting on my copy but from
what I hear it is a really good book. You can contact your local
computer book store to get more info.
Hope this helps.
John P. McNeely
BITNET: JMCNEELY@UTCVM.BITNET
-----------[000038][next][prev][last][first]---------------------------------------------------- From: watrous@athos.rutgers.edu (Don Watrous) 14-MAR-1989 14:34:13 To: misc-security@rutgers.edu
Unlike their biological counterparts, computer viruses, worms, or
what-have-you can be designed to die should they escape their test
environment. I would *hope* these test viruses have such precautions
included!
If R. Morris didn't think to take such precautions, I can't have much
sympathy for him.
Don
--
uucp: {ames, cbosgd, harvard, moss}!rutgers.edu!watrous
arpa: watrous@aramis.rutgers.edu
-----------[000039][next][prev][last][first]---------------------------------------------------- From: Xc60039@PORTLAND.BITNET (Douglas Howell) 14-MAR-1989 14:45:22 To: Security@pyrite.rutgers.edu
Hi all,
I was wondering there might be anyone who might be able to send
me a copy of Fred Cohen's disertation on computer viruses? I've tried
getting it thru the college's library but they have not gotten yet and
I really wonder if they can. I was told that Mr. Cohen may be at the
U. of Cincinatti, but as of yet I have not had the chance to confirm
that. Anyone who has a copy of the disertation and is willing to send
me a copy of it let me know okay. I've heard a lot about the paper and
would really like to read it.
Douglas Morrison Howell | Disclaimer: Niether the U. nor my boss
Student of Engineering | knows what I'm saying so don't hold
University of Southern Maine | them responsible for my inept behavior.
-----------[000040][next][prev][last][first]---------------------------------------------------- From: eugene@eos.arc.nasa.gov (Eugene Miya) 14-MAR-1989 14:54:14 To: misc-security@ames.arc.nasa.gov
The discussion about networks, distributed security, etc.
brings up several issues. The issues are similar to the software
licensing issue of program generators (like YACC). If programs
execute programs which perform "irresponsible" acts, who is responsible?
If daemons (written intentionally, obviously) do destructive acts,
can increasing levels of indirection eliminate responsibility?
The issue raised by program generators and licenses was who owns
the generated program. The issue of daemons and program generators
and security is whether continued abstraction will become a problem.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Post follow ups. Contribute to network noise."
-----------[000041][next][prev][last][first]---------------------------------------------------- From: <DAWSONM@IUBACS> 14-MAR-1989 14:55:46 To: SECURITY@OHSTVMA
Hello,
My name is Mark Dawson. I am a student of
Folklore and a computer consultant at Indiana
University. I am currently working on a
folklore project collecting computer folklore.
I am sending this letter to several listservers
to request contributions on the subject.
What is computer folklore? I leave this to
you decide. Some subjects I am interested in
include:
Hacking (feats and/or tech.)
Phone Preaking (feats and/or tech.)
The "Electronic Tribunal"
Electronic executions
These are just my particular interests, I
am taking a "shotgun" approach to the subject.
If you have any sort of computer story please
send it on, whether you think it is folklore or
not. It is not important if the information is
first hand, second hand or 12th hand. Nor is it
important -whether you may think the material
is true or not . Myth and legend has reached
the computer age, and has been going strong
for 20 years.
All contributions are greatly appreciated.
Please send information to:
Mark Dawson bitnet: DAWSONM@IUBACS
ACCESS MicroCenter
IMU 059b
Indiana University 1(812)335-0910
Bloomington, In. 47405
This message has already been posted to the FOLKLORE list, please
feel free to forward this to any other list though.
Thank you
M. Dawson
-----------[000042][next][prev][last][first]---------------------------------------------------- From: hollombe@ttidca.tti.com (The Polymath) 14-MAR-1989 19:34:14 To: misc-security@sdcsvax.ucsd.edu
} A friend of mine (without access to news) plans to write a survey
}paper on network security techniques. Does anyone have any good references
}they could recommend?
DOD 5200.28-STD Department of Defense Trusted Computer System
Evaluation Criteria, December 1985
(aka "The Orange Book")
NCSC-TG-005, v1 National Computer Security Center Trusted Network
Interpretation of the Trusted Computer System
Evaluation Criteria, 31 July 1987
(aka "The Red Book")
Both available for a minimal fee from the U.S. Government Printing Office
in Washington, D.C.
--
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
-----------[000043][next][prev][last][first]---------------------------------------------------- From: Keith Natschke <9070NATSCHKE@MUCSD.BITNET> 14-MAR-1989 19:54:14 To: security@pyrite.rutgers.edu
[Moderator injection: Replies to him, pls.. _H*]
Hello,
I'm interested in any information anybody has on DEC's VAX Encryption. As an
educational site we can obtain it for just the cost of the media and
documentation under DEC's CSLG program. We would be using it for encryption of
confidential data such as payroll information. I'm mostly interested in:
1. How well does it work?
2. Is it easy to use?
3. Has anybody had any problems with it?
4. Can it be called from a program to encrypt specific fields in a file?
5. How is the key given to programs accessing the data?
Thanks in advance!
MM MM UU UU Keith S. Natschke Analyst/Programmer
MMM MMM UU UU Marquette University Systems & Programming
MMMM MMMM UU UU Computer Services Division
MM MMMM MM UU UU 517 N. 14th Street
MM MM UU UU Milwaukee, WI 53233
MM MM UUU UUU Phone: (414) 224-3765
MM MM UUUUUU
BITNET: 9070NATS@MUCSD
Marquette University INTERNET: 9070NATS%MUCSD.BITNET@CUNYVM.CUNY.EDU
UUCP: ...psuvax1!mucsd.bitnet!9070nats
-----------[000044][next][prev][last][first]---------------------------------------------------- From: ssr@cos.com (Dave Kucharczyk) 14-MAR-1989 20:14:15 To: misc-security@uunet.uu.net
stolen from sci.electronics:
From the "Security" column of the February/March 1989 issue of
_Retailing Technology & Operations_, a supplement to
_Women's Wear Daily_/_Daily News Record_.
Reprinted without permission.
MEET MISS ANNIE DROID
By Hassell Bradley
Denver (FNS) -- Don't look now, but that snazzy looking mannequin over
there may be watching you -- and eavesdropping too. With a camera in her
eye and a microphone up her nose, Anne Droid is the latest weapon in the
growing arsenal of antishoplifting technology.
Jerry Gutierrez, who owns Anne Droid Mannequins, a nationally known
mannequin repair firm here, has developed a surveillance system that shoots
videotape through a mannequin's eye and ties in to closed circuit TV
networks.
Besides its potential for spying on thieving shoppers or employees, the
system also could be used to record customers' reactions to new products.
According to Gutierrez, it fits into any type or size of mannequin head
-- infant or adult -- as long as there is an eye opening of one-half inch.
In the past two years Gutierrez has perfected Annie, named his company
Anne Droid (he credits "Start Trek" with inspiring the name) and initiated
patent proceedings.
Although he manufactures mannequins himself, Gutierrez designed the
surveillance system to fit just about any style mannequin a visual
merchandiser wants.
Gutierrez manufactures the various glass and metal fittings for his
surveillance system. They include a special camera carriage, acrylic
eyeballs through which the video camera films, special tubes, and contact
lenses.
"I went to an optometrist and had a prescription written out for exactly
what I wanted for the eyeball," he said. "Then I went to a lens cutter and
had him grind the lenses for me. But I soon learned to do that for myself."
The camera has automatic iris control and automatic focusing, so every-
thing is in focus within a range of lights and distances. Once Annie is
installed inside a mannequin, the result is a fixed, closed circuit TV
camera that shoots only in black and white.
Gutierrez said he's received a positive reception from the stores he's
shown the system to, but none have bought it yet.
Peter Berlin, who runs a shrinkage consulting firm in Jericho, N.Y.,
was skeptical. "I want people to know that we have cameras," he pointed out.
"I want to prevent theft, not detect it. I want a camera capable of shooting
in more than one place at a time."
Gutierrez maintained this device is intended to keep watch over specific,
troublesome areas that the sweep cameras may be missing. "Anne Droid is not
meant to be a full system," he noted. "It's meant to enhance dead spots
-- for example, if you want to watch a particular cash register."
The system shoots videotape in real time and can be hooked up with most
VCRs, Gutierrez said. He suggested, however, that it be used with surveil-
lance systems, which normally use time-lapse VCRs.
The microphone, which is part of the camera, has a range of about 10
feet, depending upon background noise.
"Most people believe, and they are correct, that it is illegal to record
a private conversation. However, when a conversation takes place in a public
setting, it can no longer be deemed private. Annie makes it possible for
retailers to listen to customers discuss new products or services a store
offers. Annie could be installed in dressing rooms, or at counters.
And she would be ideal at trade shows."
Gutierrez also can install Annie "blind:" (sic) After employees see
certain mannequins have cameras in them, he can make all the mannequins look
as though they too contain the system.
Basic price, including the camera, four-inch monitor and 66 feet of
cable, runs between $1100 and $1200. Including a Decter, Co. mannequin,
it would be $1800. The cable length can be extended to 198 feet, but coaxial
cable must be used if the cable has to be any longer. Annie hooks up to most
closed circuit TV systems.
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 13 Mar 89 15:09:39 GMT From: Housley.XOSMAR@XEROX.COM To: misc.security Subject: Re: Question on block ciphers
Jim Kirkpatrick: RSA provides authentication when the blocks are enciphered with the private key of the originator. RSA provides confidentiality when the blocks are enciphered with the public key of the recipient. There is common technique for getting both authentication and confidentiality of messages longer than the "block size" (200 digits in your example). First, encipher the message in a traditional block chaining cipher (like DES CBC). Then, take the key and IV used to encipher the message and encipher them twice with RSA -- once with the private key of the originator and once with the public key of the recipient. This give authentication and confidentiality of the entire message. The DARPA privacy-enhanced electronic mail (RFC 1040) uses this scheme. Russ
-----------[000046][next][prev][last][first]---------------------------------------------------- From: <PGOETZ@LOYVAX.BITNET> (If it doesn't kill you, it's good for you.) 15-MAR-1989 3:26:13 To: security@pyrite.rutgers.edu
Regarding root/etc/passwd: Is there a known algorithm of
reasonable running time that can decrypt passwords from passwd? (Not
encode random combinations & compare the result, but work with the
encrypted text to find the plaintext.) Seems an important question to me.
Phil Goetz
PGOETZ@LOYVAX.bitnet
-----------[000047][next][prev][last][first]---------------------------------------------------- From: eugene@eos.arc.nasa.gov (Eugene Miya) 15-MAR-1989 3:32:19 To: misc-security@ames.arc.nasa.gov
>In fact, according to published reports the Computer Virus Industry
>Association
Who really is this group? They appeared in the paper in prominence
during the November Worm. What makes anyone think they can be trusted?
Or are they a reactionary group?
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Post follow ups. Contribute to network noise."
-----------[000048][next][prev][last][first]---------------------------------------------------- From: rja <rja@edison.cho.ge.com> 15-MAR-1989 3:34:18 To: security@uunet.uu.net
I am looking for information on the Sun Workstations that
have a rated security in the OS and that have passed
Tempest.
Among the areas that I am interested in are:
usability as compared with the standard Sun workstations
ballpark cost differences
the actual rating of SunOS by the NCSC or other agencies
availability of such systems
ability to connect to fibre-optic ethernets
I imagine that these aren't of very general interest, so if people
will Reply to me at one of the addresses below, I will summarise to
the net. If you don't wish your reply quoted in my net summary,
please clearly indicate that in your mail.
Thanks
______________________________________________________________________________
GE-Fanuc North America, Charlottesville, VA, USA 22906
Internet (preferable): rja@edison.CHO.GE.COM
UUCP (if you must): ...uunet!virginia!edison!rja
______________________________________________________________________________
-----------[000049][next][prev][last][first]---------------------------------------------------- From: Yuko Murayama (+44_1_387_7050 ext.3695) <Y.Murayama@purple.cs.ucl.ac.uk> 15-MAR-1989 7:38:05 To: misc.security@purple.cs.ucl.ac.uk Cc: murayama@purple.cs.ucl.ac.uk
Could anyone give me the pointers to papers or books which present a good survey on existing symmetric and asymmetric encryption algorithms, please? I would like to know their pros and cons. Yuko Murayama Dept of Computer Science, University College London
-----------[000050][next][prev][last][first]---------------------------------------------------- From: gwyn@brl.mil 15-MAR-1989 7:43:20 To: security@pyrite.rutgers.edu
There is no credible way to assess the true cost of that worm incident. For example, it is possible that the damage at BRL might have slipped improvements to armored fighting vehicles by a week. What would be the true cost of that, anyway? Dollars aren't a sufficient measure.
-----------[000051][next][prev][last][first]---------------------------------------------------- From: lfoard@wpi.wpi.edu (Lawrence C Foard) 16-MAR-1989 0:16:54 To: misc-security@husc6.harvard.edu
Remember on a PC unless there is hardware with a lock&key any one can still do
anything they want. This software will certainly slow people down but I
wouldn't trust it any more than a mainframe with public access. Even if DOS
doesn't recognize the hard drive it is still possible to write software to
access any section of the hard drive. The Encryption option may provide some
more protection but I have seen programs that will let you crack DES
encryption in about 30 minutes.
Suppose this system has a UNIX like password file and you have just failed a
course and your grades are on this system.... Reading data from the hard drive
while not easy isn't that difficult. You happen to have an account on the
machine so you setup a large file with known contents, and take out your DES
cracker. 30 minutes later you have the encryption key, search the hard drive
for the password file change the system administrator password to nothing.
Login and pass the course.... Actually breaking into the system would take
some work but what if the person just wanted to erase the hard drive? Then it
is only necessary to write a lots of garbage data onto it. Unless the PC is
behind locked doors I wouldn't trust anything important to this system.
Now for something completely different...
At least this isn't as bad as FAX documents being legally binding, I wonder how
long it will take for some one to realize they can undetectably forge legally
binding documents? Lets say you have just failed a course and you feel like
getting back at the "evil" prof? Fortunitly your father law firm (Leech and
son ambulance chasers) happens to have a board for there computer to transmit
fax documents. You find all the paper work the FBI would fax to your local
police department to have a child molester arrested, cut and paste a bit and
fax it down to the police station. Since phone calls don't tell where they are
coming from they will not realize that the documents are bogus until they
deliver the "child molester" to the FBI. And they will never be able to find
out who faxed them the documents.
--
Disclaimer: My school does not share my views about FORTRAN.
FORTRAN does not share my views about my school.
-----------[000052][next][prev][last][first]---------------------------------------------------- From: ishikawa%ultra.DEC@decwrl.dec.com (Jim Ishikawa, DTN_293_5054) 16-MAR-1989 3:28:11 To: security@pyrite.rutgers.edu
It is possible to use encryption to increase the assurance that you can extend the trusted path beyond terminal servers to hosts. This can be done without changing existing network protocols. Along with some node authentication capabilities, data-link layer encryption can provide integrity protection and controlled access analogous to hardwired serial links. Jim Ishikawa DEC
-----------[000053][next][prev][last][first]---------------------------------------------------- From: PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet 16-MAR-1989 3:32:26 To: security%ubvm.bitnet@Hamlet.Bitnet
>A displayed number on the card changes every so >many seconds; to authenticate you simply type in the current number and >the system can authenticate you since it is time synced. 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? If so, it better be more accurate than my digital watch - and that's a good one. I wouldn't trust it near the edges of its time spans. I don't see how else it can work unless it talks to the host to check that they're synched, which severely compromises the effectiveness. Peter Scott (pjs@grouch.jpl.nasa.gov)
-----------[000054][next][prev][last][first]---------------------------------------------------- From: ddp@topaz.rutgers.edu (BiG WavE DavE) 16-MAR-1989 4:11:02 To: misc-security@rutgers.edu
Hiya folks, Remember that virus that hit almost every 'puter on the Arpanet last fall?? Well, I'm writing a paper on the debate on whether or not the source code of that virus (or any other virus affecting any other computer/network) should be accessible by the general public. I'll actually be defending one of the sides. Anyway, I need facts from both sides of the issue and I'm asking the general NET to help me out. So if you think you're qualified to... shall we say..."comment" on the issue, please send me e-mail. Remember, I need FACTS. Any pointers to any published articles about the subject would also be greatly appreciated. (Yes, I will be doing my own research as well.) Anyone wishing a copy of the finished paper can send me e-mail. Thanx in advance... -WavE (a.k.a. David Pascua) ddp@topaz.rutgers.edu ...!rutgers!topaz.rutgers.edu!ddp [Moderator add-on: replies ONLY to him, please. There's already been quite enough flaming about this issue... _H*]
-----------[000055][next][prev][last][first]---------------------------------------------------- From: <PGOETZ@LOYVAX.BITNET> 16-MAR-1989 6:54:29 To: security@pyrite.rutgers.edu
Can someone tell me what the encryption algorithm is for:
1. UNIX crypt (the password encryption)
2. DES
Phil Goetz
PGOETZ@LOYVAX.bitnet
-----------[000056][next][prev][last][first]---------------------------------------------------- From: rogers@marlin.nosc.mil (Rollo D. Rogers) 16-MAR-1989 6:57:29 To: BORYNEC@bnr.ca Cc: security@rutgers.edu
Why not take the same precautions you would for software of unknown pedigree before you let it loose on your fixed disk system? REgards, RollO~~
-----------[000057][next][prev][last][first]---------------------------------------------------- From: Don Chiasson <G.CHIASSON@xx.drea.dnd.ca> 16-MAR-1989 7:13:25 To: security@pyrite.rutgers.edu, jimkirk@outlaw.uwyo.edu Cc: G.CHIASSON@xx.drea.dnd.ca
DES only has a 56 bit key - not 64 bit, which a number of people
feel does not give sufficient security. It is possible to develop a
system similar to DES with more bits, which the original
implementation had. If more security is desired, the data could be
double encrypted with two DES boxes with different keys in series
(somehow my gut feeling does not like this), or with two DES boxes in
parallel (e.g. one does the odd bits and the other the even bits).
Assuming there are no trapdoors in DES, this would give a 112 bit key
encryption without having to develop a new algorithm.
Don
-----------[000058][next][prev][last][first]---------------------------------------------------- From: Don Chiasson <G.CHIASSON@xx.drea.dnd.ca> 16-MAR-1989 7:15:47 To: security@pyrite.rutgers.edu, tihor@acf6.nyu.edu Cc: G.CHIASSON@xx.drea.dnd.ca
The classic reference on letter probabilities in English is Shannon,
"Prediction and Entropy of Printed English", Bell Systems Telephone
Journal, Vol 30 no 1, pp.50-64, January 1951. An old book I have,
"Information Theory and Coding", Abramson, 1961 gives the following
information:
- For a 27 letter equiprobable alphabet (A-Z,space) with no inter
symbol dependency, the entropy or per symbol information content
of the source is 4.75 bits/symbol.
- If the probabilities of the symbols are included, ie ETAOIN....
the entropy becomes 4.03 bits/symbol.
- If each letter depends only on the previous symbol, we
get 3.32 bits/symbol; if on the previous two symbols,
approximately 3.1 bits/symbol.
- If the dependence is on all the preceding text, it is between
0.6 and 1.3 bits per symbol. One bit per symbol is often
assumed. In other words given a long string of text, there is
a 50% chance you can correctly guess the next letter.
Thus using a long and correctly spelled English word does not give a
great deal of password security. Violate one or more of these conditions
and the problem of guessing a password is much more difficult.
Don
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 15 Mar 89 13:01:31 GMT From: greenber@utoday.UUCP To: misc.security Subject: Who really is CVIA?
The CVIA has a rather interesting background. I'm *not* a member of the CVIA, althouhg I am an anti-virus vendor. The head honcho of the CVIA is a fellow named John McAfee. Mr. McAfee is an anti-virus vendor as well. His estimates of the virus infiltration and the damage caused by virus infiltration is a bit higher than I'm comfortable with. When speaking with the press, he oftentimes gets quoted using some rather extraodrinary numbers and facts, based upon his theories of "non-reporting" sites. My belief if that you can't say something like: "Only 15% of the sites with damage are talking about it" and then extrapolate out for the so-called missing sites. I hold his numbers in disbelief. Ross M. Greenberg Author, FLU_SHOT+ Ross M. Greenberg UNIX TODAY! 594 Third Avenue New York New York 10016 Review Editor Voice:(212)-889-6431 BBS:(212)-889-6438 uunet!utoday!greenber BIX: greenber MCI: greenber PCMagNet: 72241,36
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 15 Mar 89 16:17:34 GMT From: stev@VAX.FTP.COM To: misc.security Subject: Unix passwords
* Regarding root/etc/passwd: Is there a known algorithm of *reasonable running time that can decrypt passwords from passwd? (Not yes. (actually, it *may* not generate the original password, but it *will* generate one that will encrypt into the same thing.) scary, isnt it?:)
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 15 Mar 89 16:27:27 GMT From: Hoffman.ElSegundo@XEROX.COM To: misc.security Subject: Theft-proof car lock?
>From: Rodney Hoffman <Hoffman.ElSegundo@Xerox.com>
This piece ran in 'Business Week' magazine, March 13, 1989, p. 77:
TV TECHNOLOGY MAY KEEP CARS SAFER FROM THIEVES
Looking for a better car security system? Take another look at your TV.
Using the same technology that sharpens TV images, GTE Corp. scientists
have up with a new theft-proof locking system. The device uses the
properties of SAW -- surface acoustic waves -- to activate a tiny coil
embedded in a car key. As the key turns to open the door or start the
engine, the coil sends out a coded digital signal needed to unlock or
start the car. GTE makes similar SAW filters to lock in color TV tuners
on each channel.
GTE's auto-lock system, called SAFE for surface acoustic filter encoding,
has the advantage of being completely passive: There are no codes to
memorize or alarms to disarm. And unlike other antitheft locks, SAFE
needs no electrical contact -- or even teeth on the key. Eventually,
keys for individual drivers could be encoded to automatically adjust
the seats and mirrors. So far, GTE has gotten "a strong response" in
Detroit, says Scott L. Atkinson, marketing specialist with GTE's Elec-
tronic Components & Materials Div., who thinks auto makers may offer
SAFE within two years. Also eyeing the system, says Atkinson, are
foreign carmakers and major U.S. car insurers, who are battling $6
billion a year in U.S. car-theft losses.
-----------[000062][next][prev][last][first]---------------------------------------------------- From: Root Boy Jim <rbj@nav.icst.nbs.gov> 17-MAR-1989 1:57:10 To: gwyn@smoke.brl.mil Cc: misc-security@uunet.uu.net
As far as those "Cipher" lox (five bidirectional rocker switches) go, my favorite technique is to take a piece of chalk and rub it over all the ribs on the switches. When you come back a few days later, all the buttons used for the combination have been wiped clean. That leaves you only 24 (4*3*2*1) instead of 5040 (10*9*8*7). Catman Rshd <rbj@nav.icst.nbs.gov> Author of "The Daemonic Versions"
-----------[000063][next][prev][last][first]---------------------------------------------------- From: deh@eng.umd.edu 17-MAR-1989 2:05:05 To: nichols@cbnewsc.att.com Cc: security@pyrite.rutgers.edu
The number of combinations can be cut down quite a bit by spraying or dusting the button tops with an organic dye (or whatever) that will display pretty colors when illuminated with UV light. I always prefered a coupld of strange organic dyes used in dye lasers, but they are expensive, and a lot of comon household things work just as well (the proof is left as an exercise for the reader). For a portable UV light source, you can get fancy, but I like the little EPROM eraser lights. Small, portable, and intense. A battery powerd device would be better of course if 120VAC is not available in the target area. In any case, the buttons without powder left on them are the ones that you want to play with. This works great in elevators that have button code systems in them for after hours use. The MIT Media Lab is a good example of such a facility (I wonder if they still glow over there?). Doug
-----------[000064][next][prev][last][first]---------------------------------------------------- From: <TOM@FANDM.BITNET> (Tom, Tech. Support) 17-MAR-1989 5:08:29 To: security@pyrite.rutgers.edu
Must be a real well-liked management team that feels they need bulletproof glass between them and the troops. I hope this was more to protect from unauthorized access rather than to protect from bullets. If so, it sure is better than window glass, but, as you state, overkill given the 3/4 inch plywood walls. On the other hand, those walls are tougher than you might think provided they are well built. I wouldn't want to try kicking it in! * HAVE A GOOD DAY * * * * Tom Mahoney * * Computer Electronics Tech. * * * * FRANKLIN & MARSHALL COLLEGE * * Computer Services * * Technical Support Center * * Lancaster, PA 17604-3003 USA * * (717) 291-4005 * * Bitnet Address: TOM@FANDM * *********************************
-----------[000065][next][prev][last][first]---------------------------------------------------- From: att!ulysses!smb@research.att.com 17-MAR-1989 5:28:29 To: att!misc-security
For the reasons that you name, and others as well, block ciphers are not normally used straight. What you want to look into are the DES modes of operation; they're in FIPS 81, or ANSI X3.106. There are other, non-standard, modes as well. For message-at-a-time operation, many people use ``cipher block chaining''. It involves exclusive or-ing each input block with the output of the previous step before encrypting. That is, if C[i] is the ciphertext from encrypting P[i], each step looks like this: C[i] = E(P[i] ^ C[i-1]) Decryption is the reverse: P[i] = D(C[i]) ^ C[i-1] An initial value IV is used to start things off for block 1 when there is no C[0]. There is still some chance of cut&paste here; refer to any standard work on cryptography for details of the properties of this and other modes. I suggest Davies and Price's ``Security for Computer Networks''.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 89 04:00:02 GMT From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) To: misc.security Subject: Re: Unix passwords
> Regarding root/etc/passwd: Is there a known algorithm of > reasonable running time that can decrypt passwords from passwd? No, there's no known algorithm. Oh, you want more? Neglecting the salt for the moment, password-hashing is done by repeatedly encrypting a constant string with the user's password as the key. The encryption algorithm used is DES. Deducing the password is therefore the same as the following: given a known plaintext (the constant), and a known ciphertext, find the key. This is equivalent to cracking DES, which has not been demonstrated to be possible, at least to those of us who don't work for the NSA, the KGB, or equivalent. And, given that the encryption is repeated many times (just to slow things down), the problem is harder yet. Finally, even if NSA can crack DES -- and that seems not improbable -- it's quite likely that they require much more plaintext than 8 bytes. (Unless, of course, the S-box is really a trapdoor function, to which they have the matching key.) Two caveats. First, the set of ASCII password doesn't come close to exhausting the DES key space. It isn't clear to me how much of a difference that makes, since all bits in the key are settable. Second, the password hash salt function permutes the E-box; there has been evidence presented that this weakens the encryption somewhat. I have no idea if that would help cryptanalysis in a practical sense, especially given the limited plaintext available. For details on how the password algorithm got to be the way it is, read ``UNIX Password Security'', R. Morris and K. Thompson, CACM, Vol. 31, No. 5 (May 1988), p. 484.
-----------[000067][next][prev][last][first]---------------------------------------------------- From: deh@eng.umd.edu 17-MAR-1989 17:48:31 To: jimkirk@outlaw.uwyo.edu Cc: security@pyrite.rutgers.edu
the way to get the address associated with a number is to call the phone company CNA (Customer Name and Address) bureau. this is used by various telco functions, and if you can get the phone number to it they usually don't require any id, etc. Otherwise, you will have to sweet talk the Business Office, or pretend that you are a long distance supplier and bullshit the group that handles them (different from the business office) into giving you the data. Doesn't sound too hard actually. Doug
-----------[000068][next][prev][last][first]---------------------------------------------------- From: "MARTIN J MOORE" <mooremj@uv4.eglin.af.mil> 17-MAR-1989 17:52:33 To: "security" <security@pyrite.rutgers.edu>
Regarding the relative merits of marked and unmarked keys: Our local PBS television station sends its members a key ring marked with *their* address and a code number (unique to each ring). They keep a record of the code numbers. The idea is that the finder of a lost key ring will mail it back to the station, who will then forward it to the member. If the key ring is found by a dishonest person, there is no risk because there is no other identifying information on the key ring. (This of course assumes that the personnel at the PBS station are honest. But I'm willing to take my chances on that.)
-----------[000069][next][prev][last][first]---------------------------------------------------- From: paul@csc_lons.arpa (paul@tb) 17-MAR-1989 18:07:19 To: security@pyrite.rutgers.edu
Back in the 70's there existed something called a "Lineman's Book"
published by the local phone companies. It cross refrenced name to address
to telephone number. It also cross refrenced by address and by telephone
number. I believe it also included curcuit numbers dealing with the
phone line in question. I was supplied to linemen and listed all (even
unlisted number) so the phone company people could do their work without
calling a controller every 20 minutes. If this type of book still exists,
and I think it would, paying an underpayed lineman $20.00 for a 2 minute
look in "The Master Book". If I remember the lore properly the lineman
had to sign out the book in the morning, and return it when done with
his shift.
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 89 14:12:58 GMT From: lg@computer-lab.cambridge.ac.uk To: misc.security Subject: Re: Fred Cohen
> I was wondering there might be anyone who might be able to send >me a copy of Fred Cohen's disertation on computer viruses? I could have replied via private email, but I think this might be interesting to the general public. I made an enquiry to U. of Southern California where Dr. Cohen did his Ph.D. USC Library replied that there was an indefinite hold on his thesis and could not be released without further notice. After I got this reply, I read in the newsgroup comp.risks that Do. Cohen claimed he could supply the copy with a minimum fee. I emailed his enquirying whether the hold on his thesis has been lifted. Didn't get any response. A paper on the same topic can be found in the Proceedings of the 7th DoD/NBS Computer Security Conf. 1984. ____________________________________________________________________________ | Li GONG (+44223-334650) University of Cambridge, Computer Laboratory | | Pembroke Street, Cambridge CB2 3QG, England | | InterNet/CSnet : lg%cl.cam.ac.uk@cunyvm.cuny.edu (or @nss.cs.ucl.ac.uk) | | UUCP : ...!ukc!nss.cs.ucl.ac.uk!cam-cl!lg Bitnet/EAN : lg%cl.cam@ac.uk | ----------------------------------------------------------------------------
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 89 19:52:22 GMT From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) To: misc.security Subject: Re: Unix & DES
> 1. UNIX crypt (the password encryption) See the Morris and Thompson paper in the November 1979 issue of CACM. > 2. DES Lots of places describe it; I recommend Davies and Price's book ``Security for Computer Networks'', or Beker and Piper's ``Cipher Systems''. The latter includes the full text of the federal publication announcing it.
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 89 20:22:34 GMT From: BRUCE@UMDD.UMD.EDU (Bruce Crabill) To: misc.security Subject: DES Breakability
Double encryption using DES (or anything else for that matter) gives you
an effective 57 bit key, not 112. By doubly encrypting something, you are
just making it twice as hard to break, or one extra power of two. It is
n**2 as much work, not n**n.
Bruce
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 16 Mar 89 22:59:54 GMT From: scc@computer-lab.cambridge.ac.uk (Stephen Crawley) To: misc.security Subject: password grabbers
>Well, sure, if you're using micros as terminals, and the micros are >publicly accessible or shared, then there are all kinds of possibilities >for security cracking. Granted. However, zero knowledge authentication implemented in the right way (e.g. with some sort of smart card) WOULD give security against account stealing/password grabbing. It wouldn't give you secure communications ... but that is a different issue. I'm not sure if I made it clear in my original posting, but a password grabber could well reside in the comm's network. Saying, "don't use micro's as terminals ... " is not a solution. >In our environment the users who use public terminals seem to like the >personalized password prompts, both for security and because they can be >cute. All we claim for them is that they will sometimes defeat the most >simple-minded password grabber programs But unfortunately that is not our experience. I'm talking about how the problem can be solved. Making it harder to steal passwords is not going to deter the determined hacker ... and our experience is that some hackers are VERY determined. >Now the method of attack has shifted to modern high-performance password >guessing programs. Actually, my feeling is that this is an easier problem to solve: 1) Make the encrypted passwords inaccessible to normal users. & 2) Log failed login attempts. & 3) Stop users from setting their passwords to something that is guessable. Use rules like: at least N characters, no words in a dictionary, at least 1 non-alphabetic character, etc. Point 1) means that the hacker grab a file of encrypted passwords and feed them through a password guesser. Instead the hacker has to try each password guess with the login program, which will show up in your logs (hence point 2). Point 3) means that the hacker is going to have to try a LOT of password guesses.
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 89 00:44:56 GMT From: gwyn@BRL.ARPA (Doug Gwyn (VLD/VMB) <gwyn@brl.arpa>) To: misc.security Subject: Re: Unix passwords
> Regarding root/etc/passwd: Is there a known algorithm of >reasonable running time that can decrypt passwords from passwd? None have been published. (Actually, without looking into it in detail, it might be possible that more than one password would produce the same encrypted result, so such an "inverse DES" would compute A password, not THE password.) > DES only has a 56 bit key - not 64 bit, which a number of people >feel does not give sufficient security. It is possible to develop a >system similar to DES with more bits LUCIFER differed from DES in other ways, too. The often-heard suggestion that DES needs a longer key is always based on the notion of making brute-force search of the entire key space impractical. However, that is by no means the only method of attacking such a system; you should therefore not trust increased key length as providing substantially more security. If the 56-bit key space could indeed be affordably searched in a modest amount of time with available computer resources, then indeed it would be too short; a sufficiently long key to render brute-force key searching impractical is NECESSARY but not SUFFICIENT for secure encryption. sci.crypt is probably a better newsgroup for cryptographic discussions. [Moderator tack-on: Agreed. If we move the DES stuff there, traffic will be more balanced between the respective lists. Unfortunately it's harder than I'm willing to deal with to forward the stuff from here to there on a message-by-message basis, so look for a big lump of "the rest of this" in sci.crypt soon. _H*]
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 89 04:51:24 GMT From: deh@eng.umd.edu To: misc.security Subject: Re: DES Breakability
As mentioned, you can make two (or more) passes through the DES for additional security. Dons 'gut feeling' about this maybe not being a good idea pertains I am sure to the possibility of patterns forming from the multiple runs through the data; this is possible with a lot of crypto systems, and I would not be suprised if it was the case with DES. Note that knowing how many passes were made, and with what key length (another GREAT variable you can use) is very important. It is not easy to break things when you have no idea how many passes were made, and what the key lengths were. Still, the best thing is the 300 meg disk pack, delivered to all of the sites on the network by the boys in green armed to the teeth, containing the oh_so_secure one time pad. The military actualy does this in some special cases, and it really is a very good idea; it reduces a comm and computer security risk (which they may not have a lot of experience in) to a straight forward physical security risk (which they have a lot more experience in and are more prepared to handle). Of course, for a network of more than 20 or so sites, it DOES get to be a bit of a bother. Also, if there is a lot of data moving, then you just want to use the one time pad data as keys (but maybe VERY long ones!) and run some normal encryption system. Anyone want to figure out how many packs (oppsss... Its 1989 now, lets use CD-ROMs) it would take to secure the internet? Doug
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 17 Mar 89 16:32:00 GMT From: DLV@CUNYVMS1.BITNET To: misc.security Subject: Re: DES Breakability
Don Chiasson suggests applying DES twice. I just wish to remind that it has not been shown that this differs from applying DES once with some third key (in the appropriate jargon, we don't know whether it's a group). Although it is generally believed to be the case, one should probably make appropriate disclaimers when making such suggestions, etc, etc, ad naus... Dimitri Vulis Math Department CUNY GC
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 20 Mar 89 15:25:52 GMT From: heilpern@BRL.MIL To: misc.security Subject: Re: Unix passwords
> Regarding root/etc/passwd: Is there a known algorithm of >reasonable running time that can decrypt passwords from passwd? (Not >encode random combinations & compare the result, but work with the >encrypted text to find the plaintext.) Seems an important question to me. To the best of my understanding, as stated in a few books I've read (the titles escape me) the algorithm unix uses to encrypt passwords is irreversable, letters being changed according to previous letters before change. Also, the fact that ALL encryptions yield 13 characters (actually, 11 characters and a two character key) seem to suggest this. Mark
-----------[000078][next][prev][last][first]---------------------------------------------------- From: gwyn@brl.mil 22-MAR-1989 12:37:26 To: security@pyrite.rutgers.edu
>It has often been said that DES *could* be broken by brute-force using >lots of Cray-2 time and so on, and that the NSA caused the DES' key to >be just short enough that they could break it but nobody else could. If NSA can indeed break DES, it's because they know more about cryptanalysis, not because they have bigger, faster computers for brute-force searching the key space. So, increasing the key size is not necessarily an effective countermeasure.
-----------[000079][next][prev][last][first]---------------------------------------------------- From: Steve Lesh (ISC | howard) <lesh@brl.mil> 23-MAR-1989 0:32:00 To: unix-wizards@brl.mil, info-unix@brl.mil Cc: security@pyrite.rutgers.edu
Thanks to all for the rather amazing quantity of responses to my request for the security validation programs mentioned in the Kochan and Woods book on UNIX System Security. I NOW HAVE THE PROGRAMS. I think I responded to all requests to forward these programs. I would be willing to act as a manual file server providing things don't get out of hand. Anyone knowing anything about the legal implications of posting these programs to uunet archives might want to look into archiving the above. There certainly seemed to be a lot of interest! Thanks again for the all the responses to my request.
-----------[000080][next][prev][last][first]---------------------------------------------------- From: gwyn@brl.mil 23-MAR-1989 1:43:30 To: security@pyrite.rutgers.edu
>Will virus killing programs kill daemons by mistake? This is a very important point that deserves reemphasis. There is NO practical way to tell the difference between a legitimate utility program and a virus program. If the system privileges permit certain operations and my program performs those operations, it might be for a legitimiate function or it might be that I am maliciously exploiting a loophole in the system protection rules. It may even be in the shadowy area in-between, for example if I remove a huge scratch file that is keeping my application from getting enough disk space to perform its job. Should I be removing the scratch file or not? That's a matter of local system administrative policy. So far as system security is concerned, if the system permits it then it is legitimate. There are two things that can go wrong. A perfectly secure system can be misadministered, so that users are given more capabilities than intended. Or, the system security rules and implementation may have inadvertent loopholes. The combination of both factors was involved in the Internet worm incident. Automatic "virus killers" are completely misguided. If you know enough to identify inadvertent security loopholes or errors in system administration, you should be in a position to get them fixed. If your virus killer acts on any other grounds, then it will interfere with perfectly legitimate applications.
-----------[000081][next][prev][last][first]---------------------------------------------------- From: scarter@caip.rutgers.edu (Stephen M. Carter) 23-MAR-1989 5:36:12 To: misc-security@rutgers.edu
>so they installed bullet-proof >glass in those windows. The trouble is, the windows are set in a wall >made of nothing more than 3/4" plywood and 2x2's. I don't know what they make out on the factory floor, but if it has anything that uses robot arms, milling machines, and the like, *I* would feel a lot better on having that nice thick and hefty glass around me than standard plate glass. A small metal object can be thrown a fair distance coming out of some machines. If that object hits a large plate glass area, watch out. They may not be more secure, but a lot safer.
-----------[000082][next][prev][last][first]---------------------------------------------------- From: GREENY <MISS026@ECNCDC.BITNET> 23-MAR-1989 7:06:46 To: <security@pyrite.rutgers.edu>
> I'm looking for a callback program... Hmmm...I have never seen/heard of such a beastie, as there are a variety of modems that will perform the same function, only with a much lower computer CPU usage rating than a program would have (i.e. the modem does most of the work...freeing up more CPU cycles...) Also, since their passwords are in EEPROM inside the modem, they are less vulnerable to attack than are passwords stored on a disk pack attached to a UN*X box.. Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
-----------[000083][next][prev][last][first]---------------------------------------------------- From: Housley.XOSMAR@xerox.com 23-MAR-1989 20:36:26 To: security-request@pyrite.rutgers.edu, jimkirk@outlaw.uwyo.edu Cc: Housley.XOSMAR@xerox.com
Jim Kirkpatrick: RSA provides authentication when the blocks are enciphered with the private key of the originator. RSA provides confidentiality when the blocks are enciphered with the public key of the recipient. There is common technique for getting both authentication and confidentiality of messages longer than the "block size" (200 digits in your example). First, encipher the message in a traditional block chaining cipher (like DES CBC). Then, take the key and IV used to encipher the message and encipher them twice with RSA -- once with the private key of the originator and once with the public key of the recipient. This give authentication and confidentiality of the entire message. The DARPA privacy-enhanced electronic mail (RFC 1040) uses this scheme. Russ
-----------[000084][next][prev][last][first]---------------------------------------------------- From: WHMurray@dockmaster.arpa 23-MAR-1989 22:25:22 To: security@rutgers.edu
>Am I missing something in the algorithm, that "binds" blocks in
>some way to prevent this, or is there an underlying assumption
>that external means will be taken to glue the blocks in some way?
>Clearly you could include block numbers inside each block to
>ensure block sequence and reception of all blocks, but this does
>notsolve the issue of authentication of signed messages
Yes, you are missing something, but it is not in the DES Standard.
DES is a "block" cipher, i.e., it is designed to encode 64 bit
blocks. Of course, the world is not made up of convenient 64 bit
blocks, so there is another standard that describes the safe ways
to compose it into mechanisms for messages of arbitrary length.
Most of these add so much complexity as to be more secure than the
DES primitive.
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
-----------[000085][next][prev][last][first]---------------------------------------------------- From: WHMurray@dockmaster.arpa 24-MAR-1989 0:06:03 To: security@rutgers.edu
>Having not studied the DES in great detail yet, how easy is it to
>increase the key to 64 bits or more?
It is easy to achieve any effective key length that you desire. IBM
uses a triple encryption technique in its 3848 channel-attached
crypto engine to achieve an effective key length of 112 bits.
(Three encryption steps are used in such a way that if the key is
chosen with 56 bits repeated twice, then steps 1 and 2 cancel each
other out. This permits compatability with the standard 56 bit
software implementation.)
___________________________________________________________________
William Hugh Murray 216-861-5000
Fellow, 203-966-4769
Information System Security 203-964-7348 (CELLULAR)
DOCKMASTER
2000 National City Center MCI-Mail: 315-8580
Cleveland, Ohio 44114 TELEX: 6503158580
FAX: 203-966-8612
21 Locust Avenue, Suite 2D Compu-Serve: 75126,1722
-----------[000086][next][prev][last][first]---------------------------------------------------- From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 24-MAR-1989 1:07:21 To: misc-security@att.att.com
The first step of DES encryption is to convert the 56-bit key into 16 48-bit subkeys. This step is done by a series of shifts (rotates, really) and permutations. Presumably, other algorithms could be used to expand any reasonably-short key to 768 bits, or one could even specify a 768-bit key directly. I've seen something of the sort proposed in Cryptologia, but I'm not qualified to evaluate the merits of the proposal. Certainly, there are weaknesses to be avoided; for example, if all 16 subkeys are the same, the algorithm is much easier to crack. There are other patterns even in standard DES that can give rise to undesirable subkey structures (i.e., semi-weak keys). The controversial section is the S-box. It's undisputed that (a) NSA changed it; (b) there are regularities in it; (c) NSA has admitted to some of the design principles; and (d) no one has yet (publicly) found any way to use any of these quirks. It may even be true that these changes make DES stronger. Meyer and Matyas (in ``Cryptography: A New Dimension in Computer Data Security'') note that random S-boxes take fewer logic elements to implement than do the standard one, when expressed as the sum of Boolean minterms. They conjecture that this is significant. (Note: Meyer and Matas work for the group at IBM that designed DES in the first place. This may or may not make them credible; it does speak well of their knowledge.) > RSA keeps sounding better and better, if it could only be made reasonably > quick. Given recent progress in factoring, are you sure this is a good idea? I've redirected follow-ups to sci.crypt.
-----------[000087][next][prev][last][first]---------------------------------------------------- From: att!iexist!nichols@research.att.com 27-MAR-1989 22:49:35 To: deh@eng.umd.edu Cc: security@pyrite.rutgers.edu
WRT using fluorescent dye to determine used vs. unused buttons, I suspect that a solution of ordinary laundry detergent would be the most readily available. The brighteners glow brilliant white under UV. For Simplex locks, however, who needs it!? It only takes 1 to 2 minutes of manipulation to identify used and unused buttons, with no apparatus, power source, or even ambient light require