From: rtregn@immd3.informatik.uni_erlangen.de (Robert Regn) 24-FEB-1989 23:11:22 To: misc-security@decwrl.dec.com Subj: [361] Want programs from P. Wood and S. Kochan I would like to get the programs in the appendix of "Unix system security" form P. Wood and S. Kochan (Hayden Books). But the written mail addresses {ihnp4|harpo}!bellcore!phw5!secure are no more valid. Can someone - send me these programs or - give the new mail address ?? Thanks Robert Regn rtregn@faui32.uucp rtregn@immd3.informatik.uni-erlangen.de From: 34AEJ7D@CMUVM.BITNET 24-FEB-1989 23:23:24 To: Security Digest Subj: [728] Re: Friction is your friend >This thinking can be applied to numerous other types of locks including ... Along these same lines, not long ago an individual received a certain dubious notoriety for picking the "impossible to crack" (press term, not mine) locks securing coin-operated public telephones. Is *anything* really "impossible to crack"? I may be wrong, but this sounds to me like another case of media hype surrounding a breach of relatively poor security. Yes? No? Maybe? [Moderator add-on: Yes, the "pay phone thief" was discussed at length around a year ago. Nobody ever really knew if it was for real. I can dig up the old msgs if anyone's *really* interested, but without real facts, further arm-waving about it is discouraged... _H*] From: Stephen Crawley 24-FEB-1989 23:30:03 To: security@rutgers.edu Subj: [1205] Re: Zero knowledge passwords? > At least you know you've been had, and can get off > and back on and change your (just-compromised) passsword. That of course assumes that you are alert! A typical user logs in with his/her brains in neutral. Anyhow, it is not enough to protect you against a more sophisticated attack. 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. This program passed through all data in both directions, and kept a record in RAM of the characters that users typed in response to certain prompts (like "Password: "). > And the really good ones are set up so that each invocation of the > login process gives you an authentication at the conclusion of > your login (or maybe at your logout). When you login again, > after you give your userid and before you give your password, > the login processor gives you its authentication counter-sign. That doesn't work either. If there is a possibility of someone EITHER tampering with your terminal OR eavesdropping on your comm's system, you must have an authentication scheme that uses encrypted timestamps and challenges to get secure login. -- Steve From: Tony Ivanov 24-FEB-1989 23:50:10 To: misc-security@tektronix.tek.com Subj: [2128] Password encryption...want feedback. [Moderator note: Please reply to him directly...] Hello out there! I have developed a UN*X lookalike encryption algorithm that does not have the eight character password limit. I am interested in critisism/comments on weak/strong points. Here it is: /* * tcrypt - generate hashing encryption * This function performs an encryption that produces hashed passwords that * look like the ones produced by the UN*X algorithm. The major difference * is that it allows input passwords of unlimited length (as opposed to the * UN*X algorithm which only uses the first eight characters). * * SYNOPSIS: * char *tcrypt (key, salt) * char *key, *salt; */ # define tcrypt_char(a) (_tcrypt_char[((int)a)&63]) char _tcrypt_char[] = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789./"; char * tcrypt (key, salt) char *key; char *salt; { static char buff[14]; /* Buffer to hold encrypted password. */ char *pb; /* Pointer into buffer. */ char *pk; /* Pointer into key (unencrypted password). */ char tmp; /* Value from last encryption loop. */ char s; /* Alternates between first and second character of salt. */ int size_key; /* Length of the key. */ int count; /* Loop variable. */ /* Set up initial conditions. */ strcpy (buff, "Initial_value"); pk = key; tmp = 0; size_key = strlen(key); /* Repeatedly encryt buffer. */ for (count=0; count < 100; count++) /* Re-encrypt passwd this many times. */ { s = salt[count&1]; for (pb=buff; pb < buff+14; pb++) { tmp = *pb = tcrypt_char ( *pb + *pk + s + tmp + ((*pk + s) >> (1+(count&1))) + (pk-key) ); pk++; if (pk >= key+size_key) pk = key; } } /* Set first two characters to the salt, and terminate string. */ buff[0] = salt[0]; buff[1] = salt[1]; buff[13] = '\0'; return (buff); } -- /* My opinions... * Tony Ivanov MS-4B * ...ucbvax! */ /* shared by my company?!... * Grass Valley Group, Inc. * tektronix! */ /* you've got to be kidding! * P.O. Box 1114 * gvgpsa! */ /* "tony@gvgpvd.GVG.TEK.COM" * Grass Valley, CA 95945 * gvgpvd!tony */ From: AMSTerDamn System 25-FEB-1989 0:01:04 To: dlists/amsterdamn.dl@andrew.cmu.edu Subj: [6301] Amsterdamn Vol IV 16 [ Via AMSTerDamn v2.1A ] [ with AMS-auto3.2D/SAM2A/AMSv2A ] From: bee@PURDUE.EDU Subject: Viruses and System Security (a story) The following story was posted in news.sysadmin recently. The more things change, the more they stay the same... Back in the mid-1970s, several of the system support staff at Motorola (I believe it was) discovered a relatively simple way to crack system security on the Xerox CP-V timesharing system (or it may have been CP-V's predecessor UTS). Through a simple programming strategy, it was possible for a user program to trick the system into running a portion of the program in "master mode" (supervisor state), in which memory protection does not apply. The program could then poke a large value into its "privilege level" byte (normally write-protected) and could then proceed to bypass all levels of security within the file-management system, patch the system monitor, and do numerous other interesting things. In short, the barn door was wide open. Motorola quite properly reported this problem to XEROX via an official "level 1 SIDR" (a bug report with a perceived urgency of "needs to be fixed yesterday"). Because the text of each SIDR was entered into a database that could be viewed by quite a number of people, Motorola followed the approved procedure: they simply reported the problem as "Security SIDR", and attached all of the necessary documentation, ways-to-reproduce, etc. separately. Xerox apparently sat on the problem... they either didn't acknowledge the severity of the problem, or didn't assign the necessary operating-system-staff resources to develop and distribute an official patch. Time passed (months, as I recall). The Motorola guys pestered their Xerox field-support rep, to no avail. Finally they decided to take Direct Action, to demonstrate to Xerox management just how easily the system could be cracked, and just how thoroughly the system security systems could be subverted. They dug around through the operating-system listings, and devised a thoroughly devilish set of patches. These patches were then incorporated into a pair of programs called Robin Hood and Friar Tuck. Robin Hood and Friar Tuck were designed to run as "ghost jobs" (daemons, in Unix terminology); they would use the existing loophole to subvert system security, install the necessary patches, and then keep an eye on one another's statuses in order to keep the system operator (in effect, the superuser) from aborting them. So... one day, the system operator on the main CP-V software-development system in El Segundo was surprised by a number of unusual phenomena. These included the following (as I recall... it's been a while since I heard the story): - Tape drives would rewind and dismount their tapes in the middle of a job. - Disk drives would seek back&forth so rapidly that they'd attempt to walk across the floor. - The card-punch output device would occasionally start up of itself and punch a "lace card" (every hole punched). These would usually jam in the punch. - The console would print snide and insulting messages from Robin Hood to Friar Tuck, or vice versa. - The Xerox card reader had two output stackers; it could be instructed to stack into A, stack into B, or stack into A unless a card was unreadable, in which case the bad card was placed into stacker B. One of the patches installed by the ghosts added some code to the card-reader driver... after reading a card, it would flip over to the opposite stacker. As a result, card decks would divide themselves in half when they were read, leaving the operator to recollate them manually. I believe that there were some other effects produced, as well. Naturally, the operator called in the operating-system developers. They found the bandit ghost jobs running, and X'ed them... and were once again surprised. When Robin Hood was X'ed, the following sequence of events took place: !X id1 id1: Friar Tuck... I am under attack! Pray save me! (Robin Hood) id1: Off (aborted) id2: Fear not, friend Robin! I shall rout the Sheriff of Nottingham's men! id3: Thank you, my good fellow! (Robin) Each ghost-job would detect the fact that the other had been killed, and would start a new copy of the recently-slain program within a few milliseconds. The only way to kill both ghosts was to kill them simultaneously (very difficult) or to deliberately crash the system. Finally, the system programmers did the latter... only to find that the bandits appeared once again when the system rebooted! It turned out that these two programs had patched the boot-time image (the /vmunix file, in Unix terms) and had added themselves to the list of programs that were to be started at boot time... The Robin Hood and Friar Tuck ghosts were finally eradicated when the system staff rebooted the system from a clean boot-tape and reinstalled the monitor. Not long thereafter, Xerox released a patch for this problem. I believe that Xerox filed a complaint with Motorola's management about the merry-prankster actions of the two employees in question. To the best of my knowledge, no serious disciplinary action was taken against either of these guys. Several years later, both of the perpetrators were hired by Honeywell, which had purchased the rights to CP-V after Xerox pulled out of the mainframe business. Both of them made serious and substantial contributions to the Honeywell CP-6 operating system development effort. Robin Hood (Dan Holle) did much of the development of the PL-6 system-programming language compiler; Friar Tuck (John Gabler) was one of the chief communications-software gurus for several years. They're both alive and well, and living in LA (Dan) and Orange County (John). Both are among the more brilliant people I've had the pleasure of working with. Disclaimers: it has been quite a while since I heard the details of how this all went down, so some of the details above are almost certainly wrong. I shared an apartment with John Gabler for several years, and he was my Best Man when I married back in '86... so I'm somewhat predisposed to believe his version of the events that occurred. -- Dave Platt Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 From: elevav@mcdurb.Urbana.Gould.COM 25-FEB-1989 9:29:48 To: misc-security@uxc.cso.uiuc.edu Subj: [305] Re: SCOMP I don't know about SCOPM Plus, but from conversations with NCSC people I concluded that if submitted for evaluation nowdays SCOMP would not have been approved as an A1 system. Erez Levav @ Motorola, UDC erez@xenurus.gould.com uunet!uiucuxc!mcdurb!erez [expect addresses to change in a few months] From: *Hobbit* 25-FEB-1989 9:49:48 To: security Subj: [968] more sophisticated medecos Our campus key shop guru told me that we have even a more advanced Medeco than the standard, and was almost foolproof... I believe that these are the biaxials. They are no big deal; the chisel points are offset forward or back by .025". It effectively gives each pin twice the keying versatility, since the key cut can be the right depth and twist, but if it's not under the chisel tip, you lose. A master key for this system would have two cuts right next to each other that would address either offset [and I believe they would be at the same height, since it's difficult to cut two different heights only .050" apart and have enough "meat" left to turn the pin]. With regard to picking, it essentially makes no difference. In fact, it was a biaxial that I first started working with to develop the current theory.. Lessee, (6 cuts * 3 rotations * 2 offsets) = 36 positions per pin, to the 6th power gives you something like 2 gigapossibilities... _H* From: jjq@prlb.philips.be (Jean_Jac. Quisquater) 25-FEB-1989 10:13:19 To: misc-security@uunet.uu.net Subj: [2817] collision in DES We (Jean-Paul Delescaille and Jean-Jacques Quisquater) were able to find 3 collisions in DES using a network of workstations during some weeks. Definition of a collision: given a message M and an cryptographic algorithm f with 2 parameters M and K (the key), a collision is a pair (K1, K2) such that f (M, K1) = f (M, K2), that is, for a fixed message M and using a cryptographic algorithm f, the key K1 and the key K2 give the SAME encrypted message. Jean-Jacques devised a new probabilistic distributed asynchronous algorithm for finding collisions without any sorting and with a small storage (a la Pollard). We used a fast implementation of DES in C (by Jean-Paul: about 2000 * (encryption + change of key) /second/machine) We used the idle time of a network of 20 SUN-3's and 10 microVAXes (a la Lenstra and Manasse). Total: about 100 Mips during one month. 37 2 encryptions performed (about 20 potential collisions) only in software! The message M is 0404040404040404 (hexadecimal form) for the 3 collisions. Collision 1: found Fri Jan 13 23:15 GMT (birthday of Jean-Jacques! Yes, it is another birthday attack (Hi! Don Coppersmith)). cipher = F02D67223CEAF91C K1 = 4A5AA8D0BA30585A K2 = suspense! Collision 2: found Fri Jan 20 19:13 GMT cipher = E20332821871EB8F K1, K2 = suspense! Collision 3; found Fri Feb 3 03:22 GMT suspense! Conclusion: Friday is a good day for finding collisions :-) Well, there is a problem because there is no proof we effectively found such collisions. Question 1: Find a protocol for proving or for convincing you that we know K2 for collision 1 (zero-knowledge protocols are useful in this context). Question 2: Find a protocol for proving or convincing that we know K1 and K2 for collision 2 (idem). Question 3: Find a protocol for proving or convincing that we know 3 different collisions (idem). Useful information: the nice paper by Brassard, Chaum and Crepeau, ``Minimum disclosure proofs of knowledge'', 1987. The complete information will be given at EUROCRYPT '89, Houthalen, Belgium, with the restriction that the submitted abstract is accepted :-) The paper will be sent in April if you want it. Thanks are due to Paul Branquart, Frans Heymans, Michel Lacroix, Vincent Marlair, Marc Vauclair, the members of PRLB for permission and active help in the effective implementation of the distributed algorithm on their workstations. Warning: There is no implication about the security of DES used for encryption. Indeed these experiments only prove that DES is a good random mapping (a necessary property for any cryptographic algorithm). However the use of DES for protecting the integrity of files is not very easy and needs very careful studies. Jean-Jacques Quisquater, (Program chairman of EUROCRYPT '89) From: wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) 25-FEB-1989 10:29:47 To: security@pyrite.rutgers.edu Subj: [469] Re: Sargent & Greenleaf Lock I assume you mean the kind mounted on a door, as opposed to a padlock or something? We had to break one once - one of the screws holding it to the door came loose and wedged inside the mechanism, so it wouldn't open. Took the locksmith about 1.5 - 2 hours to drill it. Shouldn't be hard to reset, though - find a good locksmith. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # # News. Don't talk to me about News. From: 28-FEB-1989 23:22:13 To: security@pyrite.rutgers.edu Subj: [1786] Desperately seeking research help... Dear fellow Netlander: I am developing research for a thesis, tentatively titled, "Computer Security in the Process Control Environment". I am seeking anyone's assistance in obtaining information relevant to this topic, as there currently exists no published data. Specifically, I would like to reach people who have (or have had) involvement in Computer Integrated Manufacturing (CIM), Computer Aided Manufacturing (CAM), process control, and related fields. Helpful information could include policies and procedures (current or past), actual experiences, etc., regarding this area, in its broadest interpretation. Suggestions gladly considered. Please feel free to pass along a copy of this letter to anyone who might be of further help. *ANY* information, even if just deemed peripheral, would be of great value, as such data can lead to other relevent information. Please, if you think you might have some helpful info, or think you might know someone or somewhere that more info can be obtained, send me a note! Data obtained will be compiled and published in Spring 1989, as my thesis. Thank you for your attention, and please excuse any inconvenience... +----------------------------------+ | Michael Kielsky | +----------------------------------+ \ Bitnet: AGMGK@ASUACVAX.BITNET \ \ \ \ 1902 East St. Catherine Ave. \ \ Phoenix, Arizona 85040 \ \ (602) 276-4663 (Home) \ \ (602) 891-6927 (Work) \ +----------------------------------+ | All opinions expressed are the | | author's and in no way reflect | | the opinions of the Sane. :-) | +----------------------------------+ From: kerchen@iris.ucdavis.edu (Paul Kerchen) 28-FEB-1989 23:22:39 To: security Subj: [1036] Re: "Viri Logicum" Here at UC Davis, we are doing research on computer viruses under the direction of Lawrence Livermore Nat'l Lab. Here at UCD, we write anti-viral programs and virus detectors. We ship them to LLNL and they test them there on a completely isolated system with viruses which they have. Now, supposed that someone accidentally attached an Ethernet cable to this isolated system. What happens now? A virus is released on the Internet unintentionally. No one gets any satisfaction from seeing this happen. However, there is a legitimate purpose for writing these viruses. If R. Morris really didn't mean to release his worm onto the Internet, imagine the horror he probably felt when he realized what he had done (put yourself in his shoes! :-) No flames, please. I don't want to debate RTM's guilt or innocence.). So, what's the point? The point is that there are legitimate reasons for writing viruses, worms, etc. How can one defend against a virus unless they have one to look at? Paul Kerchen | kerchen@iris.ucdavis.edu From: jjmhome!cpoint!martillo@cloud9.stratus.com 28-FEB-1989 23:24:46 To: security Subj: [3035] Layer Encapsulation in OSI [This was forwarded from comp.protocols or some such. _H*] >Anyone know of any references to layer encapsulation in official >OSI or CCITT documents. The problem is as follows: >LLC type II is reliable and one might want to provide security >on a per logical link basis, Unless you want to provide reliability >in the security layer itself, to make sure that applications which >run in a secure environment, you want to put the security layer >between LLC and the MAC layer, but at that point in the stack >the protocol software should only be looking at the MAC addresses >and security cannot be provided on a per logical link basis. >And if the security layers lives at the top of LLC, then the >security layer has to provide reliability. >I vaguely remember having this problem at Bell Labs when working >on Data Teleconferencing and the solution was layer encapsulation >where the security procedures would encapsulate the protocol >layer, but I simply don't remember where this was described in >the CCITT or OSI documents. If someone could give a pointer, >I would be grateful. I am following the current deliberations of the 802.10 committee on this issue. Tony Bono had what I consider a good original proposal for an architecture to deal with the issue. Apparently, the committee could not shoot down the proposal, but because he did not give a detailed functional specification (which was not what I understood to have been originally requested), the committee decided that they would only provide security procedures at the boundary between LLC and the MAC (based on pairwise MAC addresses) and not at the boundary between the Network Layer and LLC based on LSAP/DSAP pairs for a given MAC layer connection. Personally, I can think of many reasons why one might want to provide pairwise LSAP/DSAP security rather than simply point-to-point MAC address based security. It seems to me perfectly reasonable that Network Management communications streams, OSI communications streams or TCP/IP communications streams might all require different security procedures at the boundary between LLC and the network layer. Personally, I would think distributed multi-level security would be a nice thing. Providing security procedures on a per LSAP/DSAP basis would give the possibility of multi-level security at the link-layer, so that a given host might be able to realize that a given data stream from a host was trusted at a secret level because the user had logged into the console in a room guarded by guys with machine guns while another data stream from the same host was not trusted at all because the user had dialed in from outside. I see this situation all the time. Everytime someone wants to incorporate some new idea into OSI which actually give some reason to switch from TCP/IP to OSI, it gets shot down at the committee level. Now I understand why the best standards are those which were ad hoc standards first, and only much later standardized by the international committees. Any comments? From: KARYN@nssdca.gsfc.nasa.gov 28-FEB-1989 23:57:22 To: security@pyrite.rutgers.edu, (cbds080@ccs.csuscc.calstate.edu) Subj: [2105] Virus Legislation Spock, In answer to your questions... 1. Background behind viri: Everybody's stories differ. 2. Good Books on Viri: None. Now, to answer your question: Books are present, but they may not be good: I have one called: "The Computer Virus Crisis" authors: Fites/Johnson/Kratz Publisher: Van Nostrand Reinhold, NY NY I bought this one because it has skads of references in the back, & its copyright Jan 1989. I found it in a local B. Dalton store (in the nonfiction section) 3. Legislation: You asked the right person. My office-mate is now looking through his stash of info, and already has found a 20-page paper titled, "Computer Crime Legislation" dated Nov 1987. I won't bore the readers of this list with a long-winded description of which states have what laws, but in general, there are: "The Computer Fraud and Abuse Act" Fed Law TITLE 18 Part I Sect. 1029; (same law) Part I Chapt 47 Sect 1030 Chapt 119 sects 2510-2521 Chapt 121 sects 2701-2709 All states except Arkansas, Indiana, Vermont, and West Virginia had at least one statute as of the time of the paper. 4. Newer Legislation: Rep Wally Herger (R-Cal) introduced HR 5061 last July (The Computer Virus Eradication Act of 1988) but Congress was not able to vote on it last year. He re-introduced the same bill (now called HR 55) on Jan 3, 1989; 42 House members are currently co-sponsors. Who knows when this one will be voted upon. This is different from the above law because this one covers EVERYONE, while the above law only covered Government computers. 5. The "Computer Security Act of 1987" (HR 145), which you may have heard of, has nothing to do with Computer Fraud or Viruses. 6. I heard a rumor through the mill that Morris is getting off with nothing but a slap on the wrist because the places he affected don't want to get together to really give it to him. for more info, send mail to: Karyn@nssdca.gsfc.nasa.gov From: FLORY 1-MAR-1989 12:01:07 To: security@pyrite.rutgers.edu Subj: [1334] Virus psychology information In response to "Commander Spock"'s question about sources of information on why people write virus's, I suggest he look at a few recent magazine articles (I really doubt any books have been on the topic as of yet) In the Summer issue of 2600 magazine there is an article by "The Plague" called "How to Write a Virus: The Dark Side of Viruses". He claims to have written a viruse called CyberAIDS which attacks the Apple II series, but besides his "qualifications" you can get a pretty good idea of the twisted kind of mind who enjoy this kind of thing (Mr. "Plague" claims to have no moral objections to trashing people's hard work) The article goes into the theory of virus writing (not system specific) A careful reading between the lines can provide a psycological outline of one kind of virus writer. you can get a back issue of 2600 by writing to 2600 Magazine, PO Box 752, Middle Island, NY 11953-0752. You also may want to look up the Winter 1988 issue of "High Frontiers Reality Hackers" for an article called "Cyber Terrorists / Viral Hitman" Reading it between the lines also reveals a lot about the type of person who would voluntarily release a virus. David James Flory PS I don't support, condone, or agree with any of these authors, I am just bringing them up for a view of why people would write these things. From: "H.Ludwig Hausen +49_2241142426" 1-MAR-1989 12:11:12 To: security@pyrite.rutgers.edu Subj: [1395] Certification of Software Hello netters, we are going to start a European initiative on software certification (SWC) and therefor we would appreciate to receive any information on - needs for SWC - objectives for SWC - effective procedures for SWC - tools for SWC - who is doing SWC - who should do SWC - etc. Certification, in our view, includes all methods and procedures do validate, verify, test examine, measure or assess software as a product or software beeing developed by a 'certified' development process. Thanks for any help. H. L U D W I G H A U S E N .................................. : Telephone +49-2241-14-2440 or 2426: : GMD Schloss Birlinghoven Telefax +49-2241-14-2618 or 2889: : D-5205 Sankt Augustin 1 Teletex 2627-224135=GMD VV : : West GERMANY Telex 8 89 469 gmd d : : E-mail hausen@dbngmd21.BITNET : : hausen@kmx.gmd.dbp.de : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : GMD (Gesellschaft fuer Mathematik und Datenverarbeitung) : : German National Research Institute of Computer Science : : German Federal Ministry of Research and Technology (BMFT) : ...................................................................... From: "Kevin S. McCurley" 1-MAR-1989 12:28:27 To: security@pyrite.rutgers.edu Subj: [4179] Crypto '89 The following conference may be of interest to this distribution list: ====================================================================== CRYPTO '89 CALL FOR PAPERS The Ninth Annual Crypto Conference sponsored by the International Association for Cryptologic Research (IACR) in cooperation with the IEEE Computer Society Technical Committee on Security and Privacy, and the Computer Science Department of the University of California, Santa Barbara, will be held on the campus of the University of California, Santa Barbara, on August 20-24, 1989. Original research papers and technical expository talks are solicited on all practical and theoretical aspects of cryptology. It is anticipated that some talks may also be presented by special invitation of the Program Committee. INSTRUCTIONS FOR AUTHORS: Authors are requested to send ten copies of a detailed abstract (not a full paper) by March 17, 1989, to the Program Chairperson at the address given below. Abstracts should contain sufficient detail, as well as references to and comparisons with relevant extant work, to enable Program Committee members to appreciate their merits. It is recommended that abstracts start with a succinct statement of the problem and discussion of its significance and relevance to cryptology, appropriate for a non-specialist reader. In order to facilitate blind refereeing, the names of authors and their affiliations should only appear on the cover page of the paper; it should be possible to remove this page and send the papers to Program Committee members. Limits of 10 double-spaced pages and 2500 words (not counting the bibliography and the cover page) are placed on all abstracts. If the authors believe that more details are essential to substantiate the main claims of the paper, they are asked to include a clearly marked appendix that will be read at the discretion of the Program Committee. Abstracts that significantly deviate from these guidelines risk rejection without consideration of their merits. Abstracts received after the March 17 deadline WILL NOT BE CONSIDERED, unless they are postmarked not later than March 13 and arrive a reasonable time thereafter. Authors will be informed of acceptance or rejection in a letter mailed not later than May 26. A compilation of all abstracts accepted will be available at the conference. Authors of accepted papers will be given until July 14, 1989 to submit revised abstracts for this compilation. Complete conference proceedings will be published in Springer-Verlag's Lecture Notes in Computer Science series at a later date. The Program Committee will consider abstracts that have also been submitted to other conferences. However, if a submission is accepted for presentation at more than one conference, the authors may present the results more than once, but may publish them in at most one proceedings. The Program Committee consists of Josh Benaloh (University of Toronto) Russell Brand (Special session chairperson, Lawrence Livermore Laboratory) Gilles Brassard (Committee chairperson, Universite de Montreal) Claude Crepeau (Massachusetts Institute of Technology) Whitfield Diffie (Bell Northern Research) Joan Feigenbaum (AT&T Bell Laboratories) James Massey (ETH Zentrum, Zurich) Jim Omura (Cylink Corporation) Gustavus Simmons (Sandia National Laboratories) Scott Vanstone (University of Waterloo) Send abstracts to the For other information, program chairperson: contact the general chairman: ---------------------------- --------------------------- Gilles Brassard, Crypto '89 Kevin McCurley Departement IRO IBM Research, K53/802 Universite de Montreal 650 Harry Road C.P. 6128, Succursale ``A'' San Jose, CA 95120-6099 Montreal (Quebec) U.S.A. CANADA H3C 3J7 telephone: (408) 927-1708 telephone: (514) 343-6807 Internet: mccurley@ibm.com email: brassard@iro.umontreal.ca Bitnet: mccurley@almvma From: hollombe@ttidca.tti.com (The Polymath) 1-MAR-1989 13:51:12 To: misc-security@sdcsvax.ucsd.edu Subj: [1411] Re: Security equipment }If you install an alarm }system... you may be eligible for a discount (on your insurance). I asked my insurance company about this when I lived in an apartment. We'd had some burglaries and people were putting up window bars (the landlord wouldn't )-: ). They told me there was no insurance discount for window bars. A friend (Hi, Marvin!) explained the rationale: If you have a fire, you generally lose everything and the insurance company is stuck for the maximum payout. So, smoke alarms get you a premium reduction. Burglars, on the other hand, generally only take a few items. The insurance company isn't all that much out of pocket (unless you're a multi-millionaire with lots of expensive toys to be stolen) and the relevant premium reduction isn't worth offering. Bars also hinder fire fighters. Except for hindering fire fighters, I'd guess the same logic applies to alarm systems. They might save you some inconvenience by scaring away a burglar, but they generally don't save the insurance company enough for them to take an interest. Not that they're a bad idea, mind you. They just won't save you any insurance money. -- 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 From: "Craig Finseth" 1-MAR-1989 14:17:15 To: security@pyrite.rutgers.edu Subj: [1952] Additional security to login Cc: Makey@logicon.arpa Unfortunately, you missed the point. The supplied permissions: > drwxr-xr-x 13 root 1024 Jan 9 13:31 / > drwxr-xr-x 2 root 3584 Jan 23 03:42 /etc > -rw------- 1 root 2899 Jan 10 12:48 /etc/passwd will break most UNIX systems as /etc/passwd must br readable to the world: -rw-r--r-- 1 root 2899 Jan 10 12:48 /etc/passwd Shadow password files are in theory not required. In practice, when someone can read the entire file (and hence all encrypted passwords), run a password cracking program over it (that allows me to test candidate passwords at at rate a thousand times faster than simply attempting to log in), and people pick lousy passwords to begin with, the assumptions behind the publicly-readable encrypted passwords break down. Hence, one would like to move the encrypted passwords to a place where no one can read them, but otherwise leave the password file unchanged (so that UNIX still runs fine). > This scheme will have virtually no benefit on a well-administered UNIX > system, whereas the cost is moderate and may be very high (if early > implementations are easy to subvert). Since I feel that the assumptions behind the current UNIX system are violated, I disagree with this statement. I feel that the (shadow password file) scheme should be considered *mandatory* on a well-administered UNIX system and the cost is minimal (you need to change login, passwd, and su, less than a week's work even if you don't have source). While subvertable in principle, the shadow password file scheme is definitely less so than the current system. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 [Moderator note: Sun already has one in their version 4.0 and up; it sits in /etc/security/passwd.adjunct and is protected -rw-------. It seems reasonable that producers of other unix systems would soon come up with something similar... _H*] From: Mark Nelson 2-MAR-1989 0:29:51 To: misc-security@uunet.uu.net Subj: [338] Network security references? 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? I know this is pretty vague, but I don't think he has narrowed the topic yet. I will summarize if there is any demand. Thanks. Mark Nelson nelson@dewey.udel.edu From: goldstein%star.DEC@src.dec.com (Andy Goldstein) 2-MAR-1989 0:36:03 To: security@rutgers.edu Subj: [793] RE: using RSA Cryptographic Algorithm In a recent posting, James Galvin solicits implementations of and experiences with the RSA public key algorithm. Please be aware, folks, that the RSA algorithm and most of its applications are protected by a patent held by MIT and licensed to RSA, Inc. While I don't think anyone could mind if you read the textbooks and implemented your own version for some private hacking around, any sort of public distribution or serious use without a license from RSA, Inc. is likely to draw unfavorable attention from their lawyers. Don't get me wrong - I've met R & S and they're incredibly nice guys. But the corporation paid MIT a considerable amount of money for its license and it's going to get its money's worth. Anyway, the RSA patent is one of the few that's really worthy of being patented. From: (Tom, Tech. Support) 2-MAR-1989 0:39:42 To: SECURITY@pyrite.rutgers.edu Subj: [1415] Burglar tools In this state, trespassing is considered a crime and that crime, by itself, _can_ sustain a charge of burglary. This would especially be true in the case where a search incidental to the arrest produced a set of lock picks. In that situation I would charge with Criminal Trespass, Burglary, and Possession of Instruments of Crime. Safe to assume that a plea bargain would result, the felony charge of Burglary would be dropped and the deft. would plead guilty to the misdemeanors. (Unless I forgot to Mirandize him, which is another issue). I would say it would depend on a jury. If burglar tools (lock picks, and the like) are in possession, then there _IS_ a presumed intent. And, in our state, as I noted earlier, the entrance into a building with intent to commit _any_ crime constitutes burglary. Therefore, an unlawful entry into a building while in possession of burglar tools pretty well nails it. >Consider the *incidental* thief who is also regularly and >legitimately employed as a carpenter/plumber/construction worker/whatever >and just happens to carry all these around in his vehicle I agree with what you have said in context; but once the tools of the ligitimate trade have been removed from the vehicle and used to gain access to a locked building you have another situation. No luck needed - the tools become burglar tools ("instruments of crime" per PA Crimes Code). From: Joe Keane 2-MAR-1989 5:49:52 To: security@pyrite.rutgers.edu Subj: [184] Re: Hard disk protection There's really no way to protect a PC's hard disk, since the user has full control of the machine. The right thing to do is get some networking software and a dedicated file server. From: Jon Loux 2-MAR-1989 6:06:57 To: security@pyrite.rutgers.edu Subj: [2004] Re: Hard disk protection In regards to locking hard disks on IBM type PC's used for student labs, there are several security packages available for this kind of thing. At the University of Connecticut, we have been testing a product called PC/DACS. (Pyramid Development Corp. 20 Hurlbut St, West Hartford, Ct. 06110). This product will allow you to create user ID's and profiles similar to a Mainframe configuration. There must be at least one security administrator, who can create new ID's and write resource rules. A PC can be set up with a default user ID which gets automatically logged on when the machine is booted from the C drive. We use this feature in the labs, where we what the PC to boot without any user intervention. The default ID is given read only access to the entire hard disk. In one lab, they set it up so that the default ID has write access to a \TEMP directory so they can keep data for graphics programs on the hard drive while running the programs. The /TEMP directory gets purged at every boot. There is a boot protect option, which, when activated, will make your hard drive unrecognizable if you boot from the A drive. I think it relocates the FAT, or something insidious like that. There is also a disk encrypt option which will scramble your entire hard disk for you, if you're into scrambled hard disks. I haven't played with this option, since we really don't need anything quite that cloak and dagger here. We are mostly guarding against accidentally deleted files and cluttered hard disks. A new feature in the latest release of PC/DACS allows you to write resource rules for floppy drives as well. I've been thinking of using this to disallow the running of programs from floppies. If it works out, this may be an acceptable way of limiting the spread of viral programs. By the way, The State of Connecticut has contracted Pyramid Development Corp. for the use of PC/DACS in all State agencies. This is not intended to be an endorsement of the product, merely a critique. From: heilpern@tbd.ARPA (Mark A. Heilpern ) 2-MAR-1989 6:09:23 To: misc-security@uunet.uu.net Subj: [598] Re: Hard disk protection One way is to put all 'restricted' programs on one hard disk, or one section of the hard disk, and simply unmount that section when students are in the area. This is rather drastic, but the most secure. Another method: assign group access to the files and place all users who need to access them inside this group. One final, and least secure method: (If you are assured to what times students will have access) set up an 'at' daemon to remove/restore all permissions to the required files. NOTE: If you choose this method, think about the possible login via modem at these times... Mark From: lg@cl.cam.ac.uk (Li GONG) 2-MAR-1989 6:09:52 To: security@rutgers.edu Subj: [1575] A Simple Trick (Re: Dangers of password changes) Prof. Wheeler mentioned a scheme which is being recommended to customers of a credit company to securely remember ALL your PINs. This could be adopted to remember those passwords a user has to change periodically. The trick is simply as this: suppose you want to remember your PIN for VISA card which is 1234 and that for ACCESS card which is 3456 and that for Diners which is 7890. 1) Write down A to Z and choose a word (gray, for example). 2) Write down your PINs in such a way that each PIN is on a separate line and the 4 digits are under the four letters g, r, a, y. Leave other places blank. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z VISA 3 1 2 4 ACCESS 5 3 4 6 Diners 9 7 8 0 3) Fill in all blank spaces with random digits. Now the task to remember a number of passwords is reduced to remember an easy word. Also, this list can be made public with virtually no loss in security ( although try to keep it secret). There are many variations, for example to allow repeated letters in a word. Well, then what ? ____________________________________________________________________________ | Li GONG (+44223-334650) University of Cambridge, Computer Laboratory | | 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 | ---------------------------------------------------------------------------- From: "Tarjei T. Jensen" 2-MAR-1989 8:49:52 To: Subj: [937] Re: Hard disk protection 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. From: "Kenneth R. van Wyk" 2-MAR-1989 8:58:23 To: Security List Subj: [1149] Re: Hard disk protection 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: Calvin: Wow, I thought she'd put up more BITNET: of a fuss than that! From: GREENY 2-MAR-1989 20:57:51 To: Subj: [1020] re: Hard disk protection > 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 From: "Craig Finseth" 3-MAR-1989 19:25:03 To: security@pyrite.rutgers.edu Subj: [863] Login Insurance, CDC style 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 From: eleazar!matthews@dartvax.dartmouth.edu (Jim Matthews) 3-MAR-1989 19:45:00 To: misc-security@rutgers.edu Subj: [1007] Re: Breaking into computers is a crime, pure and simple >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 From: gwyn@smoke.brl.mil (Doug Gwyn ) 4-MAR-1989 0:13:03 To: misc-security@uunet.uu.net Subj: [701] Re: Friction is your friend -[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. From: Will Martin __ AMXAL_RI 4-MAR-1989 0:29:44 To: Doug Gwyn Subj: [984] Re: MIT hacking ethics 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 From: jad@dayton.dhdsc.mn.org (John A. Deters) 5-MAR-1989 4:10:37 To: security@rutgers.edu Subj: [685] Re: Friction is your friend 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 From: ron@ron.rutgers.edu (Ron Natalie) 5-MAR-1989 4:54:00 To: misc-security@rutgers.edu Subj: [1116] Re: Friction is your friend 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 From: christevt@wpafb_ams1.arpa 5-MAR-1989 5:37:23 To: "security" Subj: [1216] Re: MIT hacking ethics 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 From: Fred Blonder 5-MAR-1989 9:37:08 To: Jeff Makey Subj: [1051] Re: Additional security to login 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 From: zeleznik@cs.utah.edu (Mike Zeleznik) 5-MAR-1989 9:45:39 To: security Subj: [1209] Re: Zero knowledge passwords? 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 From: gmz@pbhyg.pacbell.com (Gerry Zeitlin) 5-MAR-1989 12:32:12 To: misc-security@ames.arc.nasa.gov Subj: [862] Re: EMP (Electro-Magnetic-Pulse) 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 From: (Stephen Tihor) 5-MAR-1989 12:42:44 To: Subj: [1557] Password Length versus Duration 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. From: Dr. T. Andrews 6-MAR-1989 11:06:48 To: security@pyrite.rutgers.edu Subj: [704] Re: Computer virus crime 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 From: "Dennis G. Rears (FSAC)" 6-MAR-1989 11:26:48 To: KARYN@nssdca.gsfc.nasa.gov Subj: [988] Re: Computer virus crime 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 -------------------------------------------------------------------------- From: *Hobbit* 7-MAR-1989 18:24:36 To: security@pyrite.rutgers.edu Subj: [569] Administrivia 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* From: "David.J.Ferbrache" 8-MAR-1989 7:15:34 To: security Subj: [6407] Virus Technical Review 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 Heriot-Watt University Janet 79 Grassmarket UUCP ..!mcvax!hwcs!davidf Edinburgh,UK. EH1 2HJ Tel (UK) 31-225-6465 ext 553 From: ron@ron.rutgers.edu (Ron Natalie) 8-MAR-1989 14:00:31 To: misc-security@rutgers.edu Subj: [225] Re: Simplex locks 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 From: 34AEJ7D@CMUVM.BITNET 8-MAR-1989 14:13:03 To: Security Digest Subj: [470] appearances vs. actualities 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! From: Gary J. Rosenblum 8-MAR-1989 14:21:19 To: security-request@pyrite.rutgers.edu Subj: [985] Request for patches to improve security 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*] From: nugent@anubis.uchicago.edu 8-MAR-1989 14:33:04 To: *Hobbit* Subj: [981] Re: more sophisticated medecos 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 From: nichols@cbnewsc.att.com (robert.k.nichols) 8-MAR-1989 14:35:16 To: misc-security@att.att.com Subj: [3086] Re: Simplex locks 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*] From: bobd@nisca.ircc.ohio_state.edu (Bob Debula) 8-MAR-1989 20:52:31 To: misc-security@cis.ohio-state.edu Subj: [476] NBS Encryption program for MVS or VM 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 From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 20:57:15 To: security@pyrite.rutgers.edu Subj: [831] On DES' "breakability" 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? From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 21:38:57 To: security@pyrite.rutgers.edu Subj: [3225] RE: Burglar Invitations 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. From: Steve Lesh (ISC | howard) 8-MAR-1989 22:43:41 To: security-request@pyrite.rutgers.edu Subj: [282] UNIX security programs 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 From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 8-MAR-1989 22:52:53 To: security@rutgers.edu Subj: [1927] Question on block ciphers 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). From: smiller@cs.umn.edu (Steven M. Miller) 9-MAR-1989 11:08:26 To: misc-security@rutgers.edu Subj: [342] Callback program wanted 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 From: James (J.G.)Borynec 9-MAR-1989 11:19:56 To: security@rutgers.edu Subj: [591] Shrink wrap not safe- yet another virus story 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) From: eugene@eos.arc.nasa.gov (Eugene Miya) 9-MAR-1989 11:29:29 To: misc-security@ames.arc.nasa.gov Subj: [2646] Re: "Viri Logicum" >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." From: haynes@ucscc.ucsc.edu (Jim Haynes) 14-MAR-1989 11:54:13 To: misc-security@ames.arc.nasa.gov Subj: [907] Re: Zero knowledge passwords? >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 From: "John P. McNeely" 14-MAR-1989 12:14:13 To: security@rutgers.edu Subj: [1133] More virus references 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 From: watrous@athos.rutgers.edu (Don Watrous) 14-MAR-1989 14:34:13 To: misc-security@rutgers.edu Subj: [405] Re: "Viri Logicum" 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 From: Xc60039@PORTLAND.BITNET (Douglas Howell) 14-MAR-1989 14:45:22 To: Security@pyrite.rutgers.edu Subj: [761] Fred Cohen 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. From: eugene@eos.arc.nasa.gov (Eugene Miya) 14-MAR-1989 14:54:14 To: misc-security@ames.arc.nasa.gov Subj: [959] "Entering" by daemons 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." From: 14-MAR-1989 14:55:46 To: SECURITY@OHSTVMA Subj: [1288] Computer folklore 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 From: hollombe@ttidca.tti.com (The Polymath) 14-MAR-1989 19:34:14 To: misc-security@sdcsvax.ucsd.edu Subj: [861] Re: Network security references? } 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 From: Keith Natschke <9070NATSCHKE@MUCSD.BITNET> 14-MAR-1989 19:54:14 To: security@pyrite.rutgers.edu Subj: [1219] VAX Encryption [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 From: ssr@cos.com (Dave Kucharczyk) 14-MAR-1989 20:14:15 To: misc-security@uunet.uu.net Subj: [4052] Spying on Consumers 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. From: (If it doesn't kill you, it's good for you.) 15-MAR-1989 3:26:13 To: security@pyrite.rutgers.edu Subj: [312] 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. Phil Goetz PGOETZ@LOYVAX.bitnet From: eugene@eos.arc.nasa.gov (Eugene Miya) 15-MAR-1989 3:32:19 To: misc-security@ames.arc.nasa.gov Subj: [620] Who really is CVIA? >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." From: rja 15-MAR-1989 3:34:18 To: security@uunet.uu.net Subj: [986] Secure Sun Workstations 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 ______________________________________________________________________________ From: Yuko Murayama (+44_1_387_7050 ext.3695) 15-MAR-1989 7:38:05 To: misc.security@purple.cs.ucl.ac.uk Subj: [260] an enquiry on papers 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 From: gwyn@brl.mil 15-MAR-1989 7:43:20 To: security@pyrite.rutgers.edu Subj: [280] Re: Breaking into computers is a crime, pure and simple 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. From: lfoard@wpi.wpi.edu (Lawrence C Foard) 16-MAR-1989 0:16:54 To: misc-security@husc6.harvard.edu Subj: [2219] Re: Hard disk protection 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. From: ishikawa%ultra.DEC@decwrl.dec.com (Jim Ishikawa, DTN_293_5054) 16-MAR-1989 3:28:11 To: security@pyrite.rutgers.edu Subj: [383] RE: Login Insurance, CDC style 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 From: PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet 16-MAR-1989 3:32:26 To: security%ubvm.bitnet@Hamlet.Bitnet Subj: [653] Re: Zero knowledge passwords? >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) From: ddp@topaz.rutgers.edu (BiG WavE DavE) 16-MAR-1989 4:11:02 To: misc-security@rutgers.edu Subj: [984] On virus source codes and accessibility... 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*] From: 16-MAR-1989 6:54:29 To: security@pyrite.rutgers.edu Subj: [156] Unix & DES Can someone tell me what the encryption algorithm is for: 1. UNIX crypt (the password encryption) 2. DES Phil Goetz PGOETZ@LOYVAX.bitnet From: rogers@marlin.nosc.mil (Rollo D. Rogers) 16-MAR-1989 6:57:29 To: BORYNEC@bnr.ca Subj: [149] Re: Shrink wrap not safe- yet another virus story 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~~ From: Don Chiasson 16-MAR-1989 7:13:25 To: security@pyrite.rutgers.edu, jimkirk@outlaw.uwyo.edu Subj: [598] DES Breakability 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 From: Don Chiasson 16-MAR-1989 7:15:47 To: security@pyrite.rutgers.edu, tihor@acf6.nyu.edu Subj: [1176] Password length 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 From: Root Boy Jim 17-MAR-1989 1:57:10 To: gwyn@smoke.brl.mil Subj: [402] Friction is your friend 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 Author of "The Daemonic Versions" From: deh@eng.umd.edu 17-MAR-1989 2:05:05 To: nichols@cbnewsc.att.com Subj: [910] Re: Simplex locks 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 From: (Tom, Tech. Support) 17-MAR-1989 5:08:29 To: security@pyrite.rutgers.edu Subj: [855] Appearances vs. Actualities 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 * ********************************* From: att!ulysses!smb@research.att.com 17-MAR-1989 5:28:29 To: att!misc-security Subj: [879] Re: Question on block ciphers 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''. From: deh@eng.umd.edu 17-MAR-1989 17:48:31 To: jimkirk@outlaw.uwyo.edu Subj: [501] RE: Burglar Invitations 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 From: "MARTIN J MOORE" 17-MAR-1989 17:52:33 To: "security" Subj: [611] To mark or not to mark (keys, that is) 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.) From: paul@csc_lons.arpa (paul@tb) 17-MAR-1989 18:07:19 To: security@pyrite.rutgers.edu Subj: [742] Forwarded: RE: Burglar Invitations 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. From: gwyn@brl.mil 22-MAR-1989 12:37:26 To: security@pyrite.rutgers.edu Subj: [459] Re: On DES' "breakability" >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. From: Steve Lesh (ISC | howard) 23-MAR-1989 0:32:00 To: unix-wizards@brl.mil, info-unix@brl.mil Subj: [607] security validation programs 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. From: gwyn@brl.mil 23-MAR-1989 1:43:30 To: security@pyrite.rutgers.edu Subj: [1429] Re: "Viri Logicum" >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. From: scarter@caip.rutgers.edu (Stephen M. Carter) 23-MAR-1989 5:36:12 To: misc-security@rutgers.edu Subj: [581] 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. From: GREENY 23-MAR-1989 7:06:46 To: Subj: [579] re: Callback program wanted > 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 From: Housley.XOSMAR@xerox.com 23-MAR-1989 20:36:26 To: security-request@pyrite.rutgers.edu, jimkirk@outlaw.uwyo.edu Subj: [783] Re: Question on block ciphers 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 From: WHMurray@dockmaster.arpa 23-MAR-1989 22:25:22 To: security@rutgers.edu Subj: [1176] DES and Long Messages >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 From: WHMurray@dockmaster.arpa 24-MAR-1989 0:06:03 To: security@rutgers.edu Subj: [1256] DES Key Length >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 From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 24-MAR-1989 1:07:21 To: misc-security@att.att.com Subj: [1620] Re: On DES' "breakability" 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. From: att!iexist!nichols@research.att.com 27-MAR-1989 22:49:35 To: deh@eng.umd.edu Subj: [736] Re: Simplex locks 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 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 From: "Katherine J. Dante" 28-MAR-1989 0:32:14 To: James (J.G.)Borynec Subj: [505] Re: Shrink wrap not safe- yet another virus story Cc: security@rutgers.edu Since 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. From: WHMurray@dockmaster.arpa 28-MAR-1989 0:38:36 To: security@rutgers.edu Subj: [580] [578] Return-path: Date: Sat, 11 Mar 89 00:19 EST From: WHMurray@dockmaster.arpa To: security@rutgers.edu >I heard once that the research behind parts of the algorithm were >still classified. IBM's discussion of how and why the S-boxes were selected was classified. However, all of the algorithm, including the S-boxes, is public. RSA's MailSafe, recently approved for use by the Internet Activities Board, implements a DES/RSA hybrid with the speed of the DES and all of the properties of the RSA. 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 From: rjg@sialis.mn.org (Robert J. Granvin) 29-MAR-1989 7:05:51 To: misc-security@uunet.uu.net Subj: [460] 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' From: pj@hrc63.co.uk (Mr P Johnson "Baddow") 29-MAR-1989 9:00:34 To: misc-security@ukc.ac.uk Subj: [1078] Unchanged combos (was Re: Friction is your friend) Yeah: a couple of things come to mind wrt unchanged combinations. My parents once stayed in a London hotel with punched cards for room keys. If you lost your card (or when you left) they just changed the combo and issued a new pair of "keys". At one point they had difficulty, so the maid came and unlocked their room with the master key. You could tell it was the master key because it had ALL its holes punched. In a similar vein, in "Surely your joking Mr Feynmann", Richard Feynmann describes how he cracked safes at Los Alamos. One of the safes was a super-strong secure safe installed by a Brass-Hat. When the safe was removed they had to open it. The local locksmith found that the Brass-Hat had never bothered to change the factory combo. Paul. [Moderator add-on: The punched cards were probably Yaletronics locks. If you want, I can dig up a generalized writeup on these hotel systems I did a while back. However, the master key would be something other than all-holes-punched. Unless this was something a good deal more stupid than a Yaletronics... _H*] From: utoday!greenber@uunet.uu.net 30-MAR-1989 22:17:22 To: security@pyrite.rutgers.edu Subj: [971] 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 From: rja 30-MAR-1989 23:01:11 To: misc-security@edison.cho.ge.com Subj: [1152] Secure Sun Workstations (summary) I got several good reponses to my request for information on secure Sun workstations. In particular, Daniel Faigin wrote and said that he checked on dockmaster.NCSC.MIL and found that the Sun products are not yet on the NCSC's Evaluated Products List and do not have an official rating yet. Jeff Edelheit wrote and offered good information and then was able to get me a copy of Sun's Product Announcement which I summarise from below. He also reports that a "compartmented mode" workstation is under development with a target of B1 security rating, but is farther out in development than the ordinary B1-rated SunOS. Thanks to everyone for quick and helpful responses. (The below is summarised from Sun's Announcement.) Sun is developing a version of SunOS called "SunOS MLS" (Multi-level Security) for the Sun-3, Sun-4, and TEMPEST Suns. The goal is to make B1 level security with the product. They plan for first customer shipments in June 1989. Cost will be $3000 for a 2-user license. NFS has been enhanced to be more secure and fibre-optic network cabling is also supported. From: Hoffman.ElSegundo@xerox.com 30-MAR-1989 23:01:49 To: SECURITY@pyrite.rutgers.edu Subj: [1503] Theft-proof car lock? Cc: Hoffman.ElSegundo@xerox.com From: Rodney Hoffman 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. From: KARYN@nssdca.GSFC.NASA.GOV 30-MAR-1989 23:14:59 To: security@rutgers.edu, eugene@eos.arc.nasa.gov Subj: [2280] Re: Info on CVIA I was curious about the Computer Virus Industry Association, too, and eventually got an address and phone number and got the following info. They charged me 3 or 5 bucks for this info, and they also told me to send a stamped, self addressed envelope with $1.70 in stamps on it. Basically its an 'association' in the loosest sense of the word, they are a bunch of consultants who will tell you what you always wanted to know about viruses. To join the association, your company sends them a yearly check for $200 and you will be informed about viruses. Seems to me you pay $200 for their consulting services about viruses, and since they call you a 'member' they encourage you to tell them all you know about viruses, so they can then sell that information to the next person. This association is probably good for people in companies where there is no other way of getting the info, but for anyone with access to this or any other security list the association is probably a waste of money. (author's note: I just read over what I wrote, and it sounds like I am putting this association down, I don't mean it to come out like that) Included in the packet are: 1. Cover letter describing company history, etc 2. list of "Companies Providing Anti-Viral Products and Services" 3. what looks like a copy of a presentation titled, "Computer Viruses: Background, Detection and Recovery" 4. Another presentation titled, "Anti-Viral Product Classifications" 5. A short document titled "Anti-Virus Measures" containing common sense information on how to keep your computer secure (e.g. never boot from a floppy drive) 6. Another presentation titled, "The Six Most Common Computer Viruses". Contains info on Pakistani brain, scores, israeli, nvir, alameda, and lehigh. 7. CVIA membership application For more info about what you get for your five bucks, contact KARYN@nssdca.gsfc.nasa.gov And here's the address of the CVIA: John D. McAfee, Chairman CVIA 4423 Cheeney Street Santa Clara, CA 95054 tele (408) 988-3832 note: If you call the above number they will answer the phone with 'Interpath Corporation'..the address and phone for the CVIA is the same as one in the list of companies providing anti-viral products and services. From: stev@vax.ftp.com 3-APR-1989 3:09:40 To: security@pyrite.rutgers.edu Subj: [288] 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?:) From: greg@uts.amdahl.com (Greg Bullough) 3-APR-1989 3:55:02 To: misc-security@ames.arc.nasa.gov Subj: [919] Re: Unix passwords > Regarding root/etc/passwd: Is there a known algorithm of >reasonable running time that can decrypt passwords from passwd? No. You expect someone running on a UNIX system to say "yes," even assuming (hypothetically) that the answer is "yes?" One wonders how questions like this leak through in a "moderated" group. Greg [Moderator tack-on, as you might expect: There's obviously a lot of disagreement and/or obfuscation surrounding this topic, as shown by the recent lot of messages. Let's try to keep things factual here, okay? Now, ignoring this for the moment, I should point out that sometimes everyone learns something when a "naive" question and several answers float by. Experienced people may occasionally forget the innocent or obvious, which may contain something important. Answering with misinformation is worse than useless, for the original asker and everyone else who's reading. _H*] From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 3-APR-1989 3:56:46 To: misc-security@att.att.com Subj: [1651] 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. From: Bruce Crabill 6-APR-1989 0:19:38 To: security@pyrite.rutgers.edu Subj: [297] 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 From: zhu@paul.rutgers.edu (Yi Zhu) 6-APR-1989 0:35:29 To: misc-security@rutgers.edu Subj: [409] Re: Unix & DES Phil Goetz asks for the encryption algorithms for the UNIX crypt and DES, I am not too familiar with the UNIX crypt(I read a paper by Ken Thompson and Robert Morris a while ago, they seemed to talk about it, but not in any details), but you can find all the gory details about DES from Federal Information Processing Standads Publication 46, which is Specifications for the Data Encryption Standard. Yi From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 6-APR-1989 1:05:57 To: misc-security@att.att.com Subj: [358] 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. From: "Craig Finseth" 6-APR-1989 1:15:55 To: security@pyrite.rutgers.edu Subj: [1149] SecurID > >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. The cards that I have seen are called the SecurID card (probably TM) and are available from: Security Dynamnics 2067 Massachusetts Avenue Cambridge, MA 02140 (617) 547-7820 >How many seconds? I believe that update intervals are selectable (at ordering time) from 30 seconds, 1 minute, and 2 minutes. > Does this rely upon a chip in the card keeping time accurate to > within a number of seconds over an operating lifetime of years? Yes. Lifetime is also specified at ordering time. I think that 2 years is the limit. As many hosts are set to "watch time," the validation software incorporates the obvious slew tracking features that would be necessary. Thus, the internal clock must be good, but not incredibly so. I am just relaying this information. The usual disclaimers apply: I'm not affiliated with the vendor, nor am I a customer of theirs. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 From: lg@computer_lab.cambridge.ac.uk 6-APR-1989 1:51:51 To: security@rutgers.edu Subj: [1228] 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 | ---------------------------------------------------------------------------- From: "Craig Finseth" 6-APR-1989 2:02:01 To: security@pyrite.rutgers.edu Subj: [1078] Hard disk protection Cc: lfoard@wpi.wpi.edu > ...but I have seen programs that will let you crack DES encryption > in about 30 minutes. This is a strong statement. If true, it has enormous ramifications for cryptography as many encryption systems are built around DES. I have some questions: 1) Do you have direct (first hand knowledge through actual use) or indirect (a friend that...) knowledge of this program? 2) Is the program attacking true DES or some PC software companies "proprietary 'uncrackable'" scheme? 3) Does the attack work through chosen plaintext, plaintext, or ciphertext only? 4) What are the hardware/time requirements? (I.e., is the 30 minutes on an IBM P.C. or a bank of 100 CRAY-2s...) 5) When was the program written? By whom? At where? 6) Was the program based on published research? If so, I would like a citation. 7) How does the attack work? (Just a general idea, I'm not asking for code.) Thank you for your time. I'm sure that many other people are interested in this matter. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 From: 7-APR-1989 5:45:37 To: security@pyrite.rutgers.edu Subj: [407] 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 From: heilpern@brl.mil 7-APR-1989 5:56:59 To: security@pyrite.rutgers.edu Subj: [639] 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 From: TomZ@ddn1.arpa 7-APR-1989 5:58:41 To: security-request@rutgers.edu, pjs@nasa.gov Subj: [860] In Reply to: Zero knowledge passwords? There are several companies that market the SmartCard ID technology. I'm reasonably familiar with SecureID from Security Dynamics, Inc. The change rate is selectable (by the vendor). This technology does *NOT* depend on the card keeping super-accurate time over an extended span. The HOST keeps a range of access keys (nominally the current key (based on the system clock), the last ten keys, and the next ten keys) and resync's itself (via a drift fudge- factor) every time that user ID's him/herself. Drift becomes a problem only when a user vanishes for an extended period. NOTE: While one might be concerned about allowing the key to vary over a "spread", there are checks to notify "responsible persons" if the drift starts wandering too much. /s/: Tom Zmudzinski (TomZ @ ddn1.arpa) Defense Communications Agency (703) 285-5333 (DSN) 356-5333 From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 7-APR-1989 6:28:34 To: SECURITY@pyrite.rutgers.edu Subj: [842] Re: On DES' "breakability" Gwynn@brl.mil says that if NSA can break DES it's because they know more about cryptanalysis. This seems to contradict the fact (found by congressional investigation) that NSA did indeed influence the decision to use 56 bits instead of 64 or more for the key. If increasing the key size is not necessarily an effective countermeasure, why did they do that? And if they can break DES by cryptanalysis, why do they have God-knows-how-many gigaflops of compute power? I do admit they probably know more about cryptanalysis than the average guy, and they probably have other uses for their computers than brute-forcing DES texts. But in view of their involvement with the key size, there is a strong implication that key size is important. They probably use both their expertise as well as compute power to do their job, whatever that is. From: deh@eng.umd.edu 7-APR-1989 6:32:39 To: G.CHIASSON@xx.drea.dnd.ca Subj: [1459] Re: DES Breakability Cc: security@pyrite.rutgers.edu 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 From: herbison%ultra.DEC@decwrl.dec.com (B.J.) 7-APR-1989 6:33:35 To: security@pyrite.rutgers.edu Subj: [1540] RE: DES Breakability The serial option is a good idea, but the parallel option you mention is not very useful: It would only double the time it would take to break the message because a cracker could crack the even bits separately from the odd bits. This would be the same difficulty as breaking a system with a 57 bit key. Using two DES algorithms in series won't necessarily be the same as a 112 bit algorithm, but breaking it will be much harder than breaking a 56 bit algorithm. Actually, ANSI has already used double length DES keys in some of their financial security standards. By their definition, a double length DES key consists of a left half and a right half, each of which is a DES key, and encryption is defined as: E[key](data) = E[key.left]( D[key.right]( E[key.left( data))) In other words, encrypt with the left half, decrypt with the right half, and encrypt with the left half again. Decryption is performed by decryption, encryption, decryption. The reason for the three steps is not increased security. Notice that if key.left and key.right are the same DES key than the double length encryption function is identical to a standard DES encryption function with one of the halves of the key. This means that hardware designed to implement their double length-key variant of DES can also perform single length DES with no modification. B.J. From: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) 7-APR-1989 18:04:40 To: security@rutgers.edu Subj: [1594] 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*] From: Stephen Crawley 7-APR-1989 18:41:14 To: misc-security@ukc.ac.uk Subj: [1885] 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. From: katz@venera.isi.edu (Alan R. Katz) 13-APR-1989 12:11:40 To: security@pyrite.rutgers.edu Subj: [426] Dusting Simplex locks Cc: nichols@cbnewsc.att.com > 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 The strange organic dyes used in many dye lasers ARE VERY TOXIC!! I wouldn't recommend sprinkling them around, you could kill someone. Alan From: meister@gaak.lcs.mit.edu (phil servita) 13-APR-1989 13:35:29 To: deh@eng.umd.edu Subj: [1281] Re: Simplex locks Cc: nichols@cbnewsc.att.com, security@pyrite.rutgers.edu it gets even better than that. If dealing with a location that is accessed VERY infrequently, (such as some of the vaults at MITRE), do the following: coat each button of a, say, 12 button pad with a different organic dye, each flourescent at a different wavelength spread equally along the visible spectrum. Now, assume the combo has a large (say 8) digits in it. The person types in the combo. Some time later, you come back with a wide-range UV source, and a decent spectroscope. (like the ones that you saw in jr high physics, only with a GOOD grating.) Look at each button. One of them will give you EIGHT spec lines. one of them will give you SEVEN. Etc. Inverting gives you the combination. If two buttons have the same number of lines, it could only happ by having one of them be used more than once in the combo. Using the relative strengths of the spec lines will give you hints as to which one it was. Sometimes it requires a second application designed to figure out a specific question, (eg "is '4' before or after '8'). Have fun. The dyes used for dye lasers are not that expensive, given the minimal amounts you need to use here. The main problem is that most of them are not transparent to visible light. Have fun. -meister From: kus3@tank.uchicago.edu (Bob Kusumoto) 13-APR-1989 15:00:54 To: misc-security@husc6.harvard.edu Subj: [1779] Re: Burglar Invitations CN/A: My personal experience with it here in Chicago is that they will not give you unlisted numbers (the procedure to get to an unlisted number is set so that only certain high level DA operators will get to look at it, it sorta goes like a) there must be an emergency to the family in question you wish to call, b) the high-level /A operator will take down your name and message, c) the person will look up the unlisted number and log the listing in some book, d) call the number herself and relay the message). CN/A works slightly differently elsewhere, like giving some ID number before you can start rattling off numbers to look up, whether they will give you unlisted numbers or not, the number of phone numbers you can get in one call to CN/A, any cost for the call (I believe they charge it at normal DA rates for CN/A calls), etc. Basicly, its become a pain nowadays. lineman's book: I used to have a real worn version of this where it had the name of the major town with a street map, and a listing of the name the phone was registered to, the phone number which was referenced by the street address. The name I heard this book called by Illinois Bell Telephone when this book came out was the "Blue Book" (for the blue cover) and it only covered a certain portion of the area code (this one covered all the North and Northwest suburbs in the 312 calling area, although the first group of towns from A to Evanston was torn out). Pretty interesting nonetheless. Bob -- Bob Kusumoto | Follow me, Internet: kus3@tank.uchicago.edu | I'll play the game you want, BITNET: kus3@tank.uchicago.bitnet | until I find a way back home. UUCP: {gargoyle,oddjob}!tank!kus3 | - Genesis, "One for the Vine" From: Ken De Cruyenaere 204_474_8340 13-APR-1989 21:22:28 To: SECURITY@pyrite.rutgers.edu Subj: [872] Card Access information request Our site has an aging card access system (made by now-defunct CMC). The system controls 16 doors and uses WIEGAND cards. We are in the process of replacing the system. There are some arguments, locally, for switching to MAG STRIPE cards (and readers). I would like to know what experience's there are out there with card access systems using WIEGAND and MAG STRIPE card technologies. Comments, criticism, etc. would be very useful at this point. Please respond to me and I will summarize and post results to the list. Thank you. ---------------------------------------------------------------------- Ken De Cruyenaere 'USER' - The word that Computer Security Coordinator computer professionals use Computer Services when they mean idiot. University of Manitoba Bitnet: KDC@CCM.UManitoba.CA -or- KDC@UOFMCC.BITNET From: iconsys!ron@uunet.uu.net (Ron Holt) 14-APR-1989 1:07:46 To: misc-security@uunet.uu.net Subj: [311] Need info on Orange Book I need to get a copy of the "Orange Book". Could someone send me ordering information? Thanks, -- Ron Holt UUCP: uunet!iconsys!ron Software Development Manager ARPANET: iconsys!ron@uunet.uu.net Icon International, Inc. PHONE: (801) 225-6888 Orem, Utah 84057 FAX: (801) 226-0651 From: (Tom, Tech. Support) 14-APR-1989 1:25:12 To: security@pyrite.rutgers.edu Subj: [1083] Telephone Cross Reference Just to clarify the telephone company cross reference thing: There are, in our area at least, commercially available cross reference publications. They cross from phone number to address and from address to phone number (I believe both crosses include the name, but I don't remember for sure). These are routinely used by credit companies and banks for collection activity, lawyers for several purposes, and as a police officer I used them for several years. Strangely, if you ask the telephone company about them, they will tell you that such a publication could not possibly exist. Those of us who understand data bases probably know better. * 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 * ********************************* From: spot!petersed@boulder.colorado.edu (Dan Petersen) 14-APR-1989 2:01:38 To: misc-security@handies.ucar.edu Subj: [846] MEDCO locks I am currently working for a small business that is trying to beef up their security. I had heard that Medco keys cannot be copied by your local locksmith. Is this true? If not, are there any high security locks that have keys which are difficult to copy? Thanks Dan [Moderator tack-on: That's "Medeco", btw; I believe that the company will sometimes contract with a locksmith in a given area such that that locksmith is the only user of a certain blank. I.e. they manufacture a bunch of custom blanks for just that locksmith, so he's the only one who can [in theory] duplicate the keys he has made. There are also some "standard" Medeco blanks, available more universally. So the answer to your question is "sometimes". Wadlow, you know any more about this? Naturally, some enterprising metalwork can usually get around this... _H*] From: zeleznik@cs.utah.edu (Mike Zeleznik) 14-APR-1989 2:36:01 To: security@rutgers.edu Subj: [1448] Re: Zero knowledge passwords? >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? ... When I last looked at the Security Dynamics one (SecurID), the time per new value was variable. If you want fast changing values, you will need a new card more often (e.g., when I looked at them, they used 6 digit (decimal) numbers, so if the value changed every 30 seconds, your card would use up all values in a year). The SecurID relied on keeping the times in sync, but allowed for a window of error (e.g., will accept either the current value, or the N previous or N next values, where N is small). They seemed to feel it worked fine, as long as your system keeps reasonable time. Now, if you are running Apollos, that could be a real problem ;-). One issue with these is if you are logging in/out of many different network machines in a short period (say, from one session on one machine). If you have to wait for the next number each time, it could be a pain; BUT, if it allows you to use the same number, then, during a small window, it is vulnerable to replay by others. Also, you have to get new cards periodically, so you are kind of married to the company... Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617 From: mtdca!royc@att.att.com 14-APR-1989 6:13:40 To: security@pyrite.rutgers.edu Subj: [385] Re: Hard disk protection > 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? Worse yet: documents do not have to be delivered to YOU, merely to your FAX machine, to bind you to them. A severe weakening of the protection principle. roy a. crabtree att!mtdca!royc 201-957-6033 From: Ralph Hyre 14-APR-1989 6:22:44 To: security@pyrite.rutgers.edu Subj: [343] Lost key security (was Re; burglar invitations) Perhaps your friendly neighborhood locksmith (who is bonded) could provide this service for you. My only worries about the local PBS station are: They may hold your key until you pay your pledge:-) There is less risk to them if they blow it. (Your locksmith would be very careful about security, since he needs a license from the state.) From: zeleznik@cs.utah.edu (Mike Zeleznik) 15-APR-1989 20:21:46 To: security@rutgers.edu Subj: [691] risk analysis/management software I am interested in risk analysis/management software (i.e., tools to aid in the tasks of assessing assets, threats, exposures, risks, and safeguards). I am aware of several commercial packages, but have no experience with any. Am sending for product lit now. Does anyone have experience with this sort of software, or, can anyone recommend a way of seeing this stuff in action, without having to buy it (e.g., maybe you know a vendor that offers a demo package)? Thanks in advance. Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617 From: m_net!glr@cardiology.ummc.umich.edu (Glen L. Roberts) 15-APR-1989 21:29:23 To: misc-security@uunet.uu.net Subj: [646] RE: Burglar Invitations Well, it is even easier than that. In most places, you can call the library and have them look up in the info in the "City Directory." What do you think the nice man from RL Polk co wanted all that information for? Also, you can sign up for the Atlas and Trace service with your local credit burau and do look-ups based on phone number, SSN, and address. They index into a compilation of junk mail lists (and probably credit applications). This service is only about $100/yr plus a dollar or so per look up. Since they are not releasing ``credit'' information the Fair Credit Reporting Act doesn't apply, so anyone who pays the fee has access. From: Dean Roy 15-APR-1989 22:23:25 To: SECURITY@pyrite.rutgers.edu Subj: [798] Security Policies Hi there! Here at the University of Windsor we are currently involved in implementing a new security system on our administrative MVS system. We have chosen CA-TOP SECRET as our new security system. As our first step towards implementation we are writing a new security policy. I would be very interested in hearing from anyone who has any ideas of what should go into our security policy. As well I would be grateful if anyone who has a security policy they have developed would send me a copy of it. Thanks in advance, Dean Roy Systems Programmer University of Windsor Windsor, Ontario, Canada From: hesh@lll_crg.llnl.gov (Chris Steinbroner) 16-APR-1989 19:28:19 To: misc-security@ames.arc.nasa.gov Subj: [323] Re: Secure Sun Workstations (summary) > The goal is > to make B1 level security with the product. > NFS has been enhanced to be more secure could somebody clarify please: does this mean that NFS is going to be part of the evaluated configuration? thanks, -- hesh (a.k.a. Chris E. Steinbroner) -- hesh@crg.llnl.gov -- {ames,hoptoad,pyramid,sun}!lll-crg!hesh From: barrys@apple.com (Barry Semo) 16-APR-1989 20:11:18 To: misc-security@ucbvax.berkeley.edu Subj: [653] Re: Theft-proof car lock? > 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. Maybe I'm missing something, but how does this stop some thug from tossing a rock into the vehicle and stealing the radio or whatever else looks good? And how does it prevent a thief from cracking the ignition switch and hotwiring it? This sounds like a high-tech key that is expensive to duplicate and won't stop anyone. Barry From: hobbit@rutgers.edu (*Hobbit*) 19-APR-1989 16:49:47 To: hobbit Subj: [23007] DES discussion from misc.security Here are the remaining in-depth technical messages about DES, which have a more appropriate home here rather than the SECURITY list. Enjoy... _H* -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: 22 Mar 89 15:17 EST From: EVERHART%ARISIA.decnet@ge-crd.arpa Subject: DES breakability...something concrete To: Security <@relay.cs.net:Security@pyrite.rutgers.edu> Here's a message that came in awhile back regarding the breakability of DES. Perhaps someone really interested might try to dig up the refs... ------------ Date: Fri, 30 Oct 87 19:32:32 MST From: evi@boulder.Colorado.EDU (Evi Nemeth) To: Eric.Cooper@SPICE.CS.CMU.EDU Subject: Re: DES breakthroughs? the break is in the diffie hellman key exchange for des based on 127 bits. it was done quite a while ago, solving the discrete log problem for the field 2 ** 127 -1. the work was with ron mullin at the university of waterloo. the actual implementation of the algorithms was done on the denelcor hep supercomputer (since defunct) in 1984. there were several technical papers by mullin and by coppersmith at ibm yorktown on the method of attack. our paper on the implementation which includes a description of the algorithm but not the gory details, was in the proceedings of the international conference on parallel processing in the summer of 1984. i can send you a copy if you dont have access to the proceedings. the paper actually won the best paper award at that conference, no $$, but i got a plaque for my wall and denelcor sold a machine to nsa. the reason i mentioned it to van was that sun has now done two talks at meetings about their security on the network that is based on des using the diffie hellman key exchange in exactly the field that we broke. both times the talk was given by the programmer who is implementing it not the mathematician who decided what to be implemented. i pointed them again to the papers on it; hope a number theorist there actually reads them. evi -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Thu, 23 Mar 89 11:21:21 EET From: Frank Simon <151133@DOLUNI1> Subject: Re: On DES' "breakability" To: SECURITY@pyrite.rutgers.edu 'gwyn@BRL.MIL writes:' >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. At last SecuriCom in Paris was show a Algorithmen to break DES Text in few seconds. I heared Shamir (the S of RSA) have programmed this Algorithmen. Know some1 more aboout this ? greets Terra PS. horrible english ... i know ... ----------------------------------------------------------------- ! Name: Frank Simon Bitnet: 151133@DOLUNI1 ! ! Nickname: Terra UUCP: Doluni1.bitnet!151133 ! ! Position: Oldenburg,Westgermany Voice: 0441/592607 ! ! WYGWYH - What you get , is what you hack ! ----------------------------------------------------------------- -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Mon, 27 Mar 89 11:18:43 EST From: hal@gateway.mitre.org (Hal Feinstein) Subject: DES export To: security@rutgers.edu Can someone give me a good two paragraph explaination of how the US export laws affect export of UNIX with DES? My understanding is that it's been removed before export, even in binary form. Someone rumored to me that the laws have recently changed. What kind of privacy algorithm would be acceptable in its place? (I mean what level of [un]-sophistication is exportable?) Does it affect the password cipher and why? -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Thu, 30 Mar 89 09:48 EST From: WHMurray@dockmaster.ncsc.mil Subject: DES Disputes To: security@rutgers.edu Cc: WHMurray@dockmaster.ncsc.mil >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. (a) is most certainly not "undisputed." Indeed, it is quite widlely disputed. It is disputed by those that were there. Walter Tuchman disputes it. He disputed it under oath before the Senate Intelligence Committee. While IBM's discussion of the S-boxes is classified, IBM takes full responsibility for their selection. It is less clear that they take full responsibility for the selection of the key length. However, it is simply not material. The DES can be, and is widely, implemented in such a way a as to provide an arbitrary key length. Would God that it was as widely used. Given the history of cryptography [KAHN], it should not come as much of a surprise, but it is nonetheless something of a national disgrace that the DES is so badly tainted by its association with the National Security Agency. It should be noted that the DES has already lasted far beyond its required design life. Testimony in regard to its recent extension suggested that it is still good for that life again. It is time that we stopped carping and began using. >> 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, for one, am satisfied that it is. First, the reports that I have seen on the progress in factoring do not suggest that we are approaching the size numbers used in RSA. Second, the key length in RSA is arbitrary. There seems to be no reason to believe that the key length cannot stay ahead of the factorers. Third, the work factor cost for numbers that we can factor is measured in tens of thousands of dollars. We do not need crypto that will resist that kind of attack. What we need is something that is one or two orders of magnitude stronger than the white envelope. Finally, one of the reports on "progress in factoring" was not that at all; it was rather a report on the use of computers to cooperate on a grand scale. While it may have reduced the elapsed time, it added (overhead for the cooperation) to the total work factor. _________________________________________________________________ William Hugh Murray 216-861-5000 Fellow, 203-966-4769 Information System Security 203-964-7348 (CELLULAR) Ernst & Whinney ARPA: WHMurray @ 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 New Canaan, Connecticut 06840 TELEMAIL: WH.MURRAY/EWINET.USA -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Wed, 05 Apr 89 14:12:18 BST From: Jim Gillogly Subject: Re: DES Breakability To: Bruce Crabill Cc: security@pyrite.rutgers.edu, jim%blaise@rand.org > 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. I'd like to see your logic on this. I assume we're both talking about encrypting with two different 56-bit keys for the double encryption. If so, it seems to me that each bit of the output *does* depend on all 112 bits, and without some known regularity in DES (your "or anything else" implies that you aren't talking about cryptanalyzing DES) I don't see how this collapses to 57 effective bits. (I assume your last sentence means that it's 2 times as much work (since you're adding only one bit), not 2**n.) Note that for DES in particular, there is no known way (outside NSA, of course) to find a single key that would create in one encryption the effect of two concatenated keys. -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Thu, 6 Apr 1989 09:04:10 EST From: Jon Loux Subject: Re: DES Breakability To: security@pyrite.rutgers.edu I'm probably horrendously naive (nothing new there), but I was just wondering, If you double encrypt something, using any encryption algorithm, wouldn't that effectively double the encryption key? The key word here is effectively, since you wouldn't have any way of knowing that you had successfully unencrypted the text once until you successfully unencrypted that text into something resembling intelligent text. In other words, if I successfully unencrypt something, I won't know it until I successfully unencrypt it again. This would provide an effective (if not strictly speaking from a mathematical point of view) difficulty level of n**n and not n**2. Comments? Peel off your favorite disclaimer and attach here. Jon Loux The University of Connecticut -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Thu, 6 Apr 89 09:20 EST From: Subject: Bust DES in 30 minutes? To: security@pyrite.rutgers.edu >> ...but I have seen programs that will let you crack DES encryption >> in about 30 minutes. >This is a strong statement. If true, it has enormous ramifications >for cryptography as many encryption systems are built around DES. The following information appeared on the INFO-VAX@KL.SRI-COM SIG around 3 March of this year. Poster is one Tarjei Jensen . My apologies if this has already been around, but I've been out of the SECURITY loop for a while ... >This is what I found on the spring 87 vax tape. I believe that it also appears >on the recent Languages and Tools SIG tape. >====================================================================== > > Data Encryption Standard > > The NSA has announced that the Data Encryption Standard, or >DES for short, would not be supported when it expired. Various banks >have pushed for its retention on the grounds that it's secure enough >for the time being. > This is to advise all and sundry that in the 1979 to 1980 period >there appeared an article in the Proceedings of the Soviet Academy of >Science giving a simple way of pruning decision trees for DES ciphers >which describes equivalence classes of keys and allows greatly reduced >processing to break a DES cipher. The reduction in processing is such >that breaking a DES cipher would amount to on order 1.5 hours on a >standard IBM PC. There have been rumors that such a program is in >circulation and that a copy of it at NSA led to its withdrawal of >support for DES. > Be advised that DES is EXTREMELY likely to be vulnerable and >that other crypto methods are probably needed to secure data. > The Soviet article goes on to give some conditions on the >factors used for public key encryption which prevent or allow easy >breaking of those ciphers, so it is probably required reading for anyone >serious about protecting information. I can't vouch for this information, but if it is substantiated, it has RATHER CLEAR implications for DES security. (I've been meaning to track down the reference for some time, but ...) Brian McMahon Administrative Computing University of Maryland University College (Default disclaimer) -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: 6 Apr 89 19:45:59 GMT From: Maarten Litmaath Subject: Re: DES Breakability To: misc-security@cwi.nl \Double encryption using DES (or anything else for that matter) gives you \an effective 57 bit key, not 112. Aha! And how are you going to decide you finally found the first key? (Actually it's the second!) By seeing if the decrypted text makes any sense? \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. ^^^^ n to the n-th! n**2 AS MUCH work? No, Bruce, what you meant to say is: "2 times as much work, not n times." However, it IS n times. -- "If it isn't aesthetically pleasing, |Maarten Litmaath @ VU Amsterdam: it's probably wrong." (jim@bilpin). |maart@cs.vu.nl, mcvax!botter!maart -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: 7 Apr 89 14:33:51 GMT From: mchamp@wpi.wpi.edu (Marc J. Champagne) Subject: Re: Unix passwords To: misc-security@husc6.harvard.edu >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. Not exactly...... This is what goes into the algorithm 1) KEY - the 8 char password you give ; of the 6 bits given, only 56 (7per char) are used 2) SALT - a 2 char sequence chosen from a..z, A..Z, 0..9, "." and "/" to give the algorithm about 4096 permutations from the unmodified DES algorithm What is modified -a 64 bit piece of constant text (never changed) is encrypted by the modified DES routine using your key (password) and the salt What comes out (in the /etc/passwd file) 1) the first 2 chars are the salt 2) the next 11 chars are the encrypted constant text ; only 66 bits of the 88 bits are actually significant How secure is it? 1) The salt routine is relatively unsophisticated. It gives some measure of protection against a hypothetical machine hardwired to decrypt the original DES algorithm. But it does not increase the complexity of the DES algorithm itself in any way. You're only getting 4096 permutations of the DES algorithm, and anyone can see the SALT value that was paired with your password. 2) How secure is the DES algorithm itself. I refuse to answer that question, since I would have to defend my answer against either a very angry group of pro-DES people, or a very angry group of anti-DES people. I've seen it happen too often on misc.security and sci.crypt. Note: -DES can be used in several different "modes", many of which involve making a given encryption of any 64 bits dependant upon a previous series of encryptions. -this is not the case with passwords encrypted with the SALTed DES program... it is 1 straight run through the modified DES algorithm Want to try an interesting experiment? -the algorithm which takes the salt found in your /etc/passwd entry and the password you type in at the login prompt, encrypts them, and spits out the encrypted constant text for the login program to compare against the full entry in the /etc/passwd file is publicly executable (of course); it is often called "makekey", and its path is usually /usr/lib/makekey -input to this algorithm is from standard input, and output is from standard output look at your entry in the /etc/passwd file. let's say it is: //--salt mchamp:ImhkyZkGBZJQE:1056:1056....... \\\\\\\\\\\--encrypted constant text try piping your password and salt into the program by hand and watch it spit out the entire entry /etc/passwd entry..ex echo "passwordIm" | /usr/lib/makekey for some key other than "password", this WILL REALLY spit out my "encrypted password" (actually, the encrypted constant text) ImhkyZkGBZJQE Hints.... -I'm running on an Encore Mutimax, and the constant text has not been changed If anyone out there can tell me what my password was (I will change it after posting this), then we'll exchange private mail using a more secure crypto-system. I'm eagerly looking forward to a successful reply..... -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: 9 Apr 89 01:36:32 GMT From: rjg@sialis.mn.org (Robert J. Granvin) Subject: Re: Unix passwords To: misc-security@uunet.uu.net On a related note (and possibly one of security interest) is a set of books published by AT&T, called "Unix System: Reading and Applications". Volume II (of apparently II) has a paper written by J. A. Reeds and P.J. Weinberger (both of AT&T Bell Labs). The paper, "File Security and the Unix System Crypt Command", discusses the processes that crypt uses for encoding data. It then proceeds to present the algebraic formulae and procedures to determine the keyword used for encryption, thereby allow decryption. It's noted that the procedure takes about two hours. It follows by presenting a simple enhancement to crypt that will make it much more secure, and then proves to you that even this improvement in encryption technique (or more generally, any reversible encryption technique) is never secure. It demonstrates this by presenting the procedures to break the new encryption. Since these are commercially available publications that I've seen on many a B. Dalton shelf, it follows that anyone who wanted the information to decrypt crypted files, technically has that information at hand. -- Robert J. Granvin National Computer Systems "Looks like the poor devil died in his sleep." rjg@sialis.mn.org "What a terrible way to die." {amdahl,hpda}!bungia!sialis!rjg -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Tue, 11 Apr 89 16:35 EST From: (Mark H. Wood) Subject: Re: on DES' "breakability" To: security@pyrite.rutgers.edu I will now prove that I don't know anything about cryptanalysis: has anybody considered that DES with a 64-bit key might be *weaker* than DES with a 56-bit key? 64 has a property that 56 does not share: it is an integer power of an integer. This additional property might introduce additional properties into the ciphertext, which could be exploited by the cryptanalyst. Maybe NSA did us a favor, instead of what is usually assumed.... -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: 12 Apr 89 14:13:25 GMT From: mark@jhereg.jhereg.mn.org (Mark H. Colburn) Subject: Re: On DES' "breakability" To: misc-security@uunet.uu.net Cryptoanalysis is not a particularly exact science. Some would still call it an art. The amount of computing power required to mechanically dissect an unknown code can be staggering. I am not sure if DES knows how to break DES or not. I do know that DES requires that any codes that are shipped out of the country are breakable, and that the "recipie" for decryption be given to the NSA. >I do admit they probably know more about cryptanalysis than the average guy, >and they probably have other uses for their computers than brute-forcing DES >texts. But in view of their involvement with the key size, there is a strong >implication that key size is important. They probably use both their > expertise as well as compute power to do their job, whatever that is. Considering what they do, a reasonable assumption. They do more than JUST break codes. They intercept messages from an amazaing array of sources, both computer and radio, and probably other that we don't know about. It is possible that DES is reversable through some arcane mathematical manipulation, or that there is some way to break it down to something easier to handle. I am sure that those parts of the VULCAN report would have been classified if they did, indeed, exist. This is merely speculation on my part. -- Mark H. Colburn "Look into a child's eye; Minnetech Consulting, Inc. there's no hate and there's no lie; mark@jhereg.mn.org there's no black and there's no white." -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Wed, 12 Apr 89 20:14:17 EDT From: gwyn@brl.arpa (Doug Gwyn) Subject: Re: On DES' "breakability" To: security@rutgers.edu >And if they >can break DES by cryptanalysis, why do they have God-knows-how-many gigaflops >of compute power? No congressional investigation was necessary to find that out; the design of Lucifer was published publicly in an IBM research journal, NSA participated in the design of DES (they suggested changes in the S-boxes as well, for example), and the resulting DES design is also public knowledge. Anybody could tell what changes were made from Lucifer to DES. Most of the reasons for the changes have not been disclosed, but there is no particular reason to think they were intended to weaken DES to the point that NSA would be able to crack it. I would be quite surprised to find out that NSA would have been incapable of routinely cracking even a 64-bit keyed DES. It is quite possible that NSA was able to determine that a 56-bit key was practically as secure (or as insecure) as a 64-bit one, given foreseeable improvements in technology through the useful life of DES. NSA has lots of computing power because it helps them accomplish their mission. I suspect that very little of it is applied to cracking DES. Note that NSA was the world's largest computer user well before DES or even Lucifer had been invented. Just because an agency is "spooky" doesn't mean you have to be paranoid about them. -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: 13 Apr 89 19:10:26 GMT From: Andrew Klossner Subject: Re: On DES' "breakability" To: misc-security@tektronix.tek.com "Gwynn@brl.mil says that if NSA can break DES it's because they know more about cryptanalysis. This seems to contradict the fact (found by congressional investigation) that NSA did indeed influence the decision to use 56 bits instead of 64 or more for the key. If increasing the key size is not necessarily an effective countermeasure, why did they do that?" Perhaps to lead you to believe that they need brute force number crunching in order to crack DES. The first thing you learn when dealing with spooks is that their motives are never transparent. Even if they needed brute force then, it doesn't follow that they need brute force now, half a decade later. -=- Andrew Klossner (uunet!tektronix!orca!frip!andrew) [UUCP] (andrew%frip.wv.tek.com@relay.cs.net) [ARPA] -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Date: Thu, 13 Apr 89 13:21:23 PDT From: merkle.pa@xerox.com Subject: The security of multiple encryption To: hobbit@pyrite.rutgers.edu The paper "On the Security of Multiple Encryption" by Merkle and Hellman was published in the July, 1981 CACM (Vol. 24, No. 7) (pages 465-467). The conclusion, in essence, was that triple encryption with two keys is still vulnerable to attacks that are similar in flavor to the attacks on double encryption with two keys. Double encryption with two keys does not improve security as much as one might hope -- it seems to force the use of more memory during cryptanalysis, but can still be broken in about 2**57 "operations". To significantly increase the security of DES would seem to require triple encryption with three separate keys. Of course, there is no guarantee that triple encryption provides substantially more security -- but triple encryption with two keys has known weaknesses. Ralph C. Merkle Xerox PARC merkle@xerox.com From: Steve Goldstein 19-APR-1989 21:00:23 To: TomZ@ddn1.dca.mil Subj: [1252] Re: In Reply to: Zero knowledge passwords? Cc: security-request@rutgers.edu, pjs@nasa.gov I have a SedureID to use the MITRE LAN via the MICOM switch. You know how many times I used it with telnet-ing or rlogin to the host from elsewhere in the Internet as an option? Wanna guess? {A: close to zero, once the curiosity wore off wrt the new toy in my briefcase.} So, then they secure all outside net access and I have to use the SecureID via telnet, rlogin, ftp, etc. Wanna know hos many times I use the MITRE host now? (I do still maintain a .forward mail deflector on it, though). Could you imagine a person with a bujch of accounts in different institutions running around with a pocketful of SecureID cards, trying to remember which is which and what his/her Personal ID Number is (one needs to key in PIN before keying in the seed that shows up on the card)? I work on security for the NASA Science Internet. Security is a BIG concern of mine. I do not take it lightly. I am more motivated than the average Joe to do the right thing. BUT, things like the SecureID are a fantastic pain in the gluteus maximus, and I use a host so guarded only as a last resort. I see the need, but I shudder to think what a pain it would be if all my host machines were so guarded. Steve Goldstein Program Coordinator NASA Science Internet From: jwright@atanasoff.cs.iastate.edu (Jim Wright) 19-APR-1989 22:06:35 To: misc-security@ames.arc.nasa.gov Subj: [1535] REMINDER - call for votes, comp.virus Today, Monday 10 Apr 1989, marks the mid-point in the voting for the new newsgroup comp.virus. This is a reminder, and will hopefully clarify a few points. To vote, send mail to me marked either "YES" for creation or "NO" against creation. If you want to check if your vote reached me, wait until the voting has finished, at which time I will post a list of all votes received. The group will be moderated. The moderator will be Ken van Wyk, who is currently the moderator of the virus-l mailing list. Also, Dave Ferbrache will be the European coordinator of the group. This will not be a "private" group. You may subscribe and read it as easily as you do any other group. You can submit material as easily as you can for any other moderated group (e.g. comp.risks, comp.unix, misc.security, etc.). If your site has up-to-date news software, submitting material to moderated groups should appear identical to submitting material to non-moderated groups. This will not be a micro-only group. There currently is a discussion in virus-l of "exec"-type viruses in IBM mainframe computers. This is only an example; other systems are equally welcome. In conjunction with comp.virus, we have been trying to establish a number of anti-viral archive sites. These sites will maintain any combination of archives of the virus-l/comp.virus group, papers dealing with computer security, anti-viral software for specific computers, etc. We currently have sites in the US and Europe. -- Jim Wright jwright@atanasoff.cs.iastate.edu From: TomZ@ddn1.dca.mil 19-APR-1989 23:34:49 To: goldstei@nsipo.nasa.gov Subj: [1545] Re: Re: In Reply to: Zero knowledge passwords? Cc: TomZ@ddn1.dca.mil, security-request@rutgers.edu, pjs@nasa.gov Comment: I probably should have put in the standard disclaimers -- (1) I agree that carrying multiple SmartCards would be a == pain, but for small numbers of centrally managed accounts (a SecureID card can keep up to four (4) different ID's with the same PIN right now), a SmartCard is much more user friendly than most of the authentication devices I've seen. == (2) You have a badge for most of those sites, I'll bet. What's wrong with the badge-replacement style of SmartCard? The ones I've been shown are not noticeably heavier than my MITRE badge -- lighter than the [insert expletive here] badge I have to use at DCA-HQS. And yes, they can be magstriped. (3) Now for my knock against ALL the SmartCard vendors: There needs to be one central authority to handle the problem of merging multiple cards into one. It is silly to have to carry more than one of these critters! Standard Disclaimer: I am not a shill for Security Dynamics. I do not own stock, get any commission, or otherwise receive remuneration from them or any of their ilk. On a personal level, it wouldn't matter to me if they fell into a hole tomorrow. * H * O * W * E * V * E * R * I == think an unforgeable identity token is the only way to secure a dial-in. A SmartCard may not be truely unforgeable -- there is nothing man or woman can fabricate that another cannot duplicate -- but it does qualify as an inexpensive alternative. /s/: Tom Zmudzinski Defense Communications Agency (703) 285-5333 From: Robert Nelson Gasch 21-APR-1989 6:35:33 To: security@pyrite.rutgers.edu Subj: [329] Password Grabbers >Now the method of attack has shifted to modern high-performance password >guessing programs. Could anybody please describe the differences between those two approaches in some detail. I'm not sure what sort of an algorithm either has. Thanx alot ---> Rob [To him, please. It's been gone over before on the list... _H*] From: William James 21-APR-1989 7:19:55 To: SECURITY@UBVM Subj: [400] GPSS on VM Hi! I am cross posting this note in order to reach a wider audience to obtain information on the possibility of installing the ancient application GPSS (General Purpose Simulation System) on a VM/HPO 4.2 - 3090 150E system. If anyone has knowledge of this package (GPSS) running under VM please get in touch with me William James at DUVM (james@duvm) or give me a call at (215)895-1433. Thank You. From: *Hobbit* 21-APR-1989 7:56:52 To: security Subj: [141] comp.virus votes Those of you who sent your votes to security, or misc.security, aren't getting anywhere. Try re-reading the "call for votes" message. _H* From: "W. K. (Bill) Gorman" <34AEJ7D@CMUVM.BITNET> 21-APR-1989 8:40:20 To: Security Digest Subj: [317] Re: Dusting Simplex locks >The strange organic dyes used in many dye lasers ARE VERY TOXIC!! I >wouldn't recommend sprinkling them around, you could kill someone. Very dramatic! However, the same effect can be obtained by using the UV fluorescent liquids/powders available through suppliers of stuff used for kiddies science fair projects. From: deh@eng.umd.edu 21-APR-1989 9:00:43 To: jimkirk@outlaw.uwyo.edu Subj: [1112] Re: On DES' "breakability" Cc: security@pyrite.rutgers.edu The only problem with this line of reasoning is that anyone at NSA could have predicted that this line of thinking would be followed, and that the natural conclusion is that "since they shortened the keys, and use all that compute power, they must not know a back-door" Paranoia! In any case, they do things at NSA that use more compute than anyone knows...... Crays and such are, from what I am told, th least of the power these days. My employer has sold a lot of systems to them, or should I say to "Maryland Procurement", but not for the crunch factor. 'nuff said. By the way, on a different wavelength, the Secret Service here in DC has gone to scrambled communications. This has screwed up a bunch of my friends in the media, since this was one of the ways that they tended to keep track of what was happening. Not that anyone would try to actually use the information, but can anyone discuss the state- of-the-art on this stuff? Thanks, Doug [yow! this DOES seem like a pretty underground message for an above ground guy like myself. Don't take this wrong! Inquiring Minds want to KNOW ] From: hal@gateway.mitre.org (Hal Feinstein) 21-APR-1989 21:17:38 To: -v@gateway.mitre.org, security@pyrite.rutgers.edu Subj: [1131] DES export laws I'm trying to find out what's going on with US DES export laws: (1) Folks at MIT are trying to get DES exported for their a authentication server (project Athena). (2) Products built on flavors of UNIX (Xenix, Sys V, BSD...) You get UNIX and the product as a binary. Is this exportable? (3) Rumor is UNIX had to have DES software (two different modules one waz password crypt.) removed before it could be exported. Did they get a ruling or were the corporate lawyers working overtime that night? (4) I understand the law applies to *all* cryptography and not any specific algorithm,device, rotor machine or what have you. How un-sophisticated must the algorithm, device, rotor machine or what have you be before you've got a better than 50% chance of getting approval? (5) Suppose you take DES binary out and some smart European puts it back in, over there? (6) About two years back I saw a algorithm built of DES like boxes from an author at a Polish university. Think its secure..eh? (It was published in a British journal) Any information would be greatly appreciated. From: Robert Cole 21-APR-1989 22:25:30 To: tcp-ip@sri-nic.arpa, security@pyrite.rutgers.edu Subj: [1291] Draft Standard for Security A new draft ECMA standard for Security in Open and Distributed systems is available for FTP. This draft standard addresses the problems of security standardisation in applications intended for OSI or ODP environments. Comments are requested on this draft for inclusion in the final version. Please forward this message to any other groups or individuals who may be interested in this work. The text may be obtained by anonymous FTP from rcole.hpl.hp.com (15.255.61.89) which is in the UK, or from allspice.lcs.mit.edu in the directory ~/pub/ecma-desd, as a tar file containing print files for the individual chapters. Two print file formats are offered: desdps - contains the PostScript version desdlj - contains print files for the HP-Laserjet+ (or better). Compressed versions are also available to ease the transfer problem. So the file choices (and sizes) are: 5253120 Apr 5 13:50 desdlj.tar 1816056 Apr 5 15:34 desdlj.tar.Z 1505280 Apr 5 11:00 desdps.tar 569425 Apr 5 11:12 desdps.tar.Z Note that the document contains pictures as well as text so it is not possible to send the text directly by e-mail. Please note that the document was designed for, and will evenatually be published on, A4 paper. If you must print it on AQ size then you may lose the page numbers. Robert From: ok@quintus.com (Richard A. O'Keefe) 21-APR-1989 23:12:04 To: ???Subj: [2278] E-mail secutiry question A University has loaned me a PC for a couple of months. After some initial confusion about what I would do for them in return, this is what they decided they wanted most. There is a central site with a bunch of machines: VAX/VMS, IBM 4341/VM/CMS, all LANned together and exchanging mail using CMDF (a C version of PMDF). There is a marine research station miles and miles away with several PCs, none of them particularly big, not (if I've understood correctly) LANned together, and not currently using E-mail. They do have a line to the main site. What they want is a scheme (which must use the phonenet protocol) whereby the marine biologists at the remote site can receive and send mail through the main site. The irony of this is that I know only as much about mailers as I couldn't avoid knowing. It did strike me that these people, who never have to "log in" to use their PCs, probably aren't going to like having to give passwords and the like just to use E-mail, which they've not had before so aren't missing. It also struck me that in the absence of shared file-servers, the mail will only be as secure as the floppy discs it is physically stored on. The scheme I came up with for authentication is this: each person at the remote site who is authorised to use the E-mail system would be given a floppy disc containing a version of the mail transfer program customised for him. This would contain all the necessary information to identify that user to the mail system. The user would be able to make copies of the disc. Retaining control over who can read your mail and who can send mail as you would then reduce to retaining physical control over the copies of the disc. The degree of security required here isn't very great. What's worrying me is the thought that I might be missing some obvious Risk. (Either the phonenet protocol is flawed, or I have misunderstood it: there doesn't seem to be any way of preventing someone using this method to find out which other people at his site have mail waiting at the main site and who that mail is from, but that's true no matter what the authentication method is.) If this isn't the right newsgroup, I apologise for wasting your time. comp.risks didn't seem quite right. From: 22-APR-1989 5:05:09 To: security@pyrite.rutgers.edu Subj: [221] MVS security We are also a fairly new MVS site running RACF. I would also appreciate any security policy documents anyone may have for MVS. Thank you. Bob Peraino, George Mason University peraino@gmuvax.gmu.edu peraino@gmuvax From: Christopher Chung 22-APR-1989 6:05:10 To: SECURITY@pyrite.rutgers.edu Subj: [645] password security Cc: Christopher Chung How do you deal with passwords in terms of how to make sure that 1) everyone who needs to know them is informed when one changes. 2) if everyone happens to be away and a server or account needs to be accessed, how does a non-administrator get the password in an emergency? Are the passwords written down someplace that can be accessed by someone who has the need to in an emergency. If so how do you prevent someone from stealing a look at this "book" ie the janitors who have keys to everything? I am dealing with these issues and was wondering what people would recommend. Thanks, Chris CHRIS%BROWNVM.BITNET@MITVMA.MIT.EDU From: deh@eng.umd.edu 23-APR-1989 16:05:13 To: KDC@ccm.umanitoba.ca Subj: [3474] Re: Card Access information request Cc: security@pyrite.rutgers.edu WIEGAND is by far the best card technology that is available today (I exclude smart cards, since they are a new technology and have their own special problems). Mag cards will get erased by things, and will wear physically, and will go bad, and will be an administrative nightmare about a year (maybe a lot less) after they are installed. WIEGAND cards work by having a thin bi-metal wire embedded in the card. The wire is subjected to heating, magnetic fields, and mechanical twisting at the factory in order to encode the proper data into it. It is NOT a magnetic system, and is not subject to being screwed up by magnetic fields that you are likely to encounter in reality (I ruined a WIEGAND card on a Cyclotron Analyser magnet once, but that was an exceptional case, since it was bending a 200 Mev beam at the time, and thus was generating a BIT of a field). The wire is swept through a magnetic field set up by the reader, and the field itself is monitored. As the various parts of the wire pass through the field, they will cause fluctuations in it which are read and used as data. Very slick. These readers are epoxy encapsulated, so they never fail because of stuff getting into them and need no maintenance, something that can not be said for mag cards. Wiegand readers work underwater for example, which may sound useless, but there is a US Navy location that has them installed on under water weapons storage (mines or something I would guess....) vaults in Maryland. It means that if your card gets soaked in the rain, the card and the reader don't care. It really is a great technology. I have seen cards for Kastle Systems (here in the DC area, they do access control for more than 350 buildings) that people have been sitting on (in their back pockets I assume) for years and have shattered them, barely held together by scotch tape, and they still work fine. Try that with any other technology. The RF based cards, refered to as Sludge Cards since the company that makes them is Sladge (spelling?) are not really all that winning, though they do have their good points. They can be read through your clothes, so you can leave your wallet in your pocket and just get your rump up against the reader (if they are nice enough to put it that low!) and zap! you are in, unless you have something else metal in your wallet that can screw up the RF reading of the card. The cards are somewhat sensitive to physical damage, not that they are delicate per se, but if they DO get hurt they stop working at once since it changes the RF emmission characteristics of the card. The other drawback is security; there exists in the DC area somewhere (I don't know who ended up with it) and 'Boom Box' (radio, cassette, etc) that only plays cassettes, since its innards have been replaced with a modified version of the Sludge Card reader. You sit down next to the reader (as close as you can get the box to it, in any case) and when the person with the card get near, it will read the card while it is still in their purse, wallet, etc. Walking through a downtown (K street) McDonalds with this device several years ago (when we built it) yielded a slew of card data. If you are near their entrance and watch them walk in, and get their card data as they pass by, I assume that it would not be too hard to build cards to match the data that you recorded, and then waltz (or bop, or shuffle) right on in..... I consider this a security risk. Doug From: Stephen.Wadlow@cad.cs.cmu.edu 25-APR-1989 19:19:48 To: security@rutgers.edu Subj: [2467] Re: MEDCO locks The way I have understood medeco to work, is that they will license a locksmith for the use of one specific and unique blank. Medeco will only sell this unique blank to that locksmith, thereby, the only people who will be able to "officially" copy a medeco key would be the locksmith, and medeco. This is all in keeping with the "high security" aspect of medeco locks. Since they restrict the blanks on a per locksmith basis, only the locksmith who installed your cylinder will be able to duplicate the key, and thereby, he should know who has keys, and can only make keys for only people with legitimate needs. To the best of my knowledge, there are two universal medeco blanks. They are available to any schmuck who can figure out how to get them. I'm not certain, but I believe one of the two is for a 5 pin cylinder and the other is an identical blank only made for 6 pin. There is a third party vender that is making clones of these keys (It may be Ilco, but I'm not positive) which seem to work well, and are cheaper than buying them from medeco. > Naturally, some enterprising metalwork can usually get around this... The beauty of medecos is that they have a very large keyway, and it usually isn't terribly difficult to do some creative milling on other blanks to get one that will fit. I know of people that have made duplicates of medeco keys using brickstrap, but the resultant keys aren't always reliable as the surface area of the key on which the beveled cut is made to rotate the pin isn't very large, and the pins may not always rotate properly. In terms of other locks which are difficult to get copied, I'd probably recommend abloy. Not only are they difficult to pick, but you have an example of security through obscurity. There aren't many people who have the facilities to copy abloy keys. I don't know if they have a similar licensing procedure in terms of blanks. From what I have seen, I tend to believe that they don't. I have never seen any third party abloy clone keys, thereby making abloy your only source for key blanks. Has anyone ever had any experience in picking abloys? I've heard of it being done, but not by using standard methods. steve ====================================================================== Stephen G. Wadlow Internet: sgw@cad.cs.cmu.edu Dept of Architecture, CMU stephen.wadlow@andrew.cmu.edu "Hey Man, A ship in harbor is safe, but that ain't what ships are for" From: shz@io.att.com (s.h.zirin) 26-APR-1989 2:18:44 To: misc-security@att.att.com Subj: [420] Re: MEDECO locks >If not, are there any high security locks that have keys which are >difficult to copy? MEDECO Biaxial ABLOY DiskLock ASSA SECURITY 777 All of the above locks use restricted key blanks that are not available to hardware stores or to most locksmiths. The last three also require special machines which are only available to contractually obligated dealers at a cost of 2K to 3K. Seth Zirin, CPL att!packard!shz From: GREENY 26-APR-1989 2:54:26 To: Subj: [1245] re: Medeco Keys I had heard that Medco keys cannot be copied by your local locksmith... Yeah, this is usually true, depending upon who your local locksmith is. Most smaller locksmiths just dont have the money to purchase the special machine which cuts Medeco keys. Each key cut is cut at a specific angle and the machine is *VERY* accurate. Consequently, many locksmiths will send your request for a key either to the factory, or to a larger outfit which does have a Medeco key cutting machine. Each Medeco key/cylinder comes with a "credit card" that has a specific factory-assigned number on it. When you ask for a duplicate key, the locksmith takes the card, runs it thru a credit card like machine onto a special form from Medeco, and sends the form, and whatever he/she/it charges ya for the key (the place I work for charges $5.00/key + certified mailing costs). Also the locks are pretty hard to pick, but not impossible. One thing to consider tho, is that the security provided by the lock is only as great as the surrounding door frame/door. I.e.: If the door/door frame are pretty cheesy, then having an $80 lock isnt worth it... Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU From: rjg@sialis.mn.org (Robert J. Granvin) 26-APR-1989 3:08:09 To: misc-security@uunet.uu.net Subj: [2824] Re: MEDCO locks Medeco has a range of varying security key blanks. All differing in their difficulty to copy. They replaced a key system about two years ago. Those keys can be duplicated through contracted locksmiths. It is assumed that they will follow the Medeco guidelines for duplication (which is require ID against a "Valids" list, make the copies, then have you return to pick them up). The keys they replaced this system with are only available through Medeco directly. To duplicate the key, you must go to a contracted locksmith who has your account on file. You must request a key by _number_, and sign a form. You must be on a list of authorized parties... Once verified by the locksmith as to your identity, the request is delivered to Medeco who also does their own verification against an authorization file, and then make the copies. The copies are shipped to the locksmith, where you can pick them up, showing proper ID. This is the plan, at least... :-) But, keep in mind that a lock is only as good as the door and frame around it. if your hinges are exposed to the outside, pin the hinges. Also pay attention to the strike plate area. A steel door and steel frame can be pried far enough apart with a crowbar to let you get in. The lock does nothing for you here. Cover the strike plate zone with a door-strike guard, at least. Next, can the entire lock mechanism be cut out? I've seen gadgets that attach to the door handle, and a little battery operated cutting blade will cut the whole lock mechanism out of the door. Works on wood and steel. You'll never beat them, but you can discourage them... -- Robert J. Granvin National Computer Systems "Looks like the poor devil died in his sleep." rjg@sialis.mn.org "What a terrible way to die." {amdahl,hpda}!bungia!sialis!rjg 14-Apr-89 22:37:35-GMT,942;000000000401 Date: 14 Apr 89 21:47:26 GMT From: rjg@sialis.mn.org (Robert J. Granvin) Subject: Re: Need info on Orange Book To: misc-security@uunet.uu.net In article <8904140138.AA17801@ucbarpa.Berkeley.EDU> ron@iconsys.UUCP (Ron Holt) writes: >I need to get a copy of the "Orange Book". Could someone send me ordering >information?\ Contact the National Computer Security Center. Ask for the publications office. The number can be obtained by calling your local number for the Government Information Center (You can tell I don't have it handy :-). The Orange Book is one book out of several known as "The Rainbow Set". They can also be ordered through the Government Printing Office, but they don't know what "The Orange Book" means. Robert J. Granvin National Computer Systems "Looks like the poor devil died in his sleep." rjg@sialis.mn.org "What a terrible way to die." {amdahl,hpda}!bungia!sialis!rjg From: gwyn@brl.mil 30-APR-1989 14:47:29 To: security@rutgers.edu Subj: [954] Re: MEDCO locks As the moderator said, that's probably Medeco. Machines for duplicating Medeco keys are available to locksmiths. The blanks are probably harder to obtain, but anyone with access to a good milling machine could in principle manufacture his own. The main protection is that your corner drugstore is probably incapable of correctly duplicating Medeco keys, and most locksmiths realize that they are "high-security" items and should verify that you're entitled to make copies before doing so. Sargent's KESO series, since emulated with slight variations by other manufacturers, uses dimples drilled into the sides of the blank rather than notches cut out of the edge. Not many key duplicators are set up to duplicate/manufacture KESO keys. I think forced entry is more likely for most businesses than unauthorized key duplication; you can always rekey when an employee leaves (and it's pretty easy to do so if you use interchangeable-core cylinders). From: "Craig Finseth" 30-APR-1989 15:23:24 To: haynes@ucscc.ucsc.edu Subj: [1469] Password guessing technology Cc: security@pyrite.rutgers.edu We have added the following rules to our passwd program: All candidate passwords must pass these tests: - It must be at least 6 characters long. - It must contain at least 1 non-alphanumeric character. - If there is only 1 non-alphanumeric character, it must not be the last character. - It must contain at least 4 distinct characters. Six variations of the candidate password are also checked further. The variations are: - The candidate password, - All but the first character of the candidate password, - All but the last character of the candidate password, and - The reversed versions of the first three. The further checks are: - Against the system dictionary, - Against an auxilliary "hit list" file, which includes the Internet virus list, all examples, and other special cases. - Appearance in /etc/passwd or /etc/group (this check catches the user name, first name, last name, and group name), - Against the form: , and - Against the form: . All checks are made ignoring upper/lower case. Of the approximately 1.9 billion passwords that consist of 6 characters, 5 of which are lower-case alphabetic and digit characters and 1 of which is a special character, these restrictions eliminate (very roughly) 10 million. In addition, we have a shadow password file and other changes. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 30-APR-1989 22:18:48 To: security@pyrite.rutgers.edu Subj: [405] Social Security Numbers Well, folks, I'm really doing it this time --- an article for the Whole Earth Review about everything you can do with somebody's number. If you have any info on: 1. destroying people (or their credit rating) 2. finding out personal information. 3. Using SSN's as gateways, or impersonation. 4. Other stuff Please call me at 617-876-6111 or send email to simsong@athena.mit.edu. Thanks. -simson From: (Marshall D. Abrams) 30-APR-1989 23:02:17 To: security@pyrite.rutgers.edu Subj: [821] Access control research We have also been working on access control models and are interested in sharing information with you. Our work is a "white paper" on access control concepts for the National Computer Security Center. What is the purpose, focus, and audience for your work? Here is the to-date bibliography for our access control paper. The numbers are out of order (we've just been adding as we go along and will redo at the end.) This is a derect extract from our source file, including troff marco commands. [Moderator insertion: Said bibliography approaches 10K and is probably of interest to only a few readers. Please contact Marshall directly if you want a copy... _H*] Sincerely, - - Marshall D. Abrams, phone: (703) 883-6938 The MITRE Corporation, 7525 Colshire Drive Mail Stop Z506, Mc Lean, VA 22102 From: /* Purple Haze */ 1-MAY-1989 18:21:55 To: security@pyrite.rutgers.edu Subj: [323] car locks There's been a lot of talk about these high-security car locks. I'm curious to know why they are being called 'car locks' at all. Couldn't they be used (with a small power source of course) as a regular door lock? Wouldn't it be a bummer if you had to get into a car locked with one of these and your battery was dead? From: david paul hoyt 2-MAY-1989 18:08:19 To: security@pyrite.rutgers.edu Subj: [781] smart card timebases >How many seconds? Does this rely upon a chip in the card keeping time >accurate to within a number of seconds over an operating lifetime of >possibly years? ... This isn't a problem really. There are phone numbers you can dial to get the correct time (international standards, inference clocks) accurate to some fraction of a millisecond. The macintosh pd program "setclock" uses this mechanism to get the 'correct' time. The card only needs to be able to resync before connecting to the remote system (assuming the remote uses an accurate clock as well). Alternatively, the card can sync with the remote as part of the handshake. After all trading times in clear text can hardly pose any kind of security breach. david | dhoyt@vx.acss.umn.edu | dhoyt@umnacvx.bitnet From: _David C. Kovar 2-MAY-1989 19:35:29 To: security@rutgers.edu Subj: [961] Telephone line security I was tracing the phone wires in my house yesterday afternoon trying to find out why my phone was "off-hook" when all of the phones were actually hung up. Just before the lines enter my house I found a gray box labelled "Telephone Network Interface". Curious, I opened the box to find two RJ-11 modular phone jacks with black connectors in them that were held in by clips. I popped the clip, unplugged the plugs and plugged in a normal phone. Lo and behold, a dial tone! I wandered around the neighborhood a bit and found a few more of these boxes. Looks like you can wander around Boston with a phone, plug into someone's circuit, and make as many phone calls as you like. Who needs lineman's equipment? -David C. Kovar Technical Consultant ARPA: kovar@husc4.harvard.edu Office of Information Technology BITNET: corwin@harvarda.bitnet Harvard University MacNET: DKovar Ma Bell: 617-495-5947 "It is easier to get forgiveness than permission." From: "Michael J. Chinni, SMCAR_CCS_E" 3-MAY-1989 7:22:13 To: security@pyrite.rutgers.edu Subj: [1136] Re: password security What we do: Our site is a government installation (DoD - Army). (1) dealt with verbally (i.e. those that need to know are told verbally). (2) the non-administrator doesn't get the password. The passwords are NEVER to be written down, under any circumstances. Recommendations: What we might do if we did write down the password in a "book" would be to keep this "book" in a combination-type safe. Only those people who were authorized, in advance, as primary or alternate admins. (or bosses) would have the combo. to that safe (that includes lock&key control as not have-ers). /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Michael J. Chinni Chief Scientist, Simulation Techniques and Workplace Automation Team US Army Armament Research, Development, and Engineering Center User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey and dust covered terminal and desk () ARPA: mchinni@pica.army.mil "System been down long?" () UUCP: ...!uunet!pica.army.mil!mchinni /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From: steve@polyslo.calpoly.edu (Steve DeJarnett) 3-MAY-1989 8:10:16 To: CHRIS@BROWNVM.BITNET, SECURITY@pyrite.rutgers.edu Subj: [1952] Re: password security We deal with the need-to-know problem in a fairly simplistic way. We keep our root password inside of a sealed (and taped-shut) envelope that is stored in a lock-box. Those people who might actually need to know it in an emergency have a key to that lock-box. The envelope is checked daily. If someone needs to know the password in an emergency, they must go into the machine room, where the lock-box is -- only about 12 people have keys to this room, and of those 12, only 8 have keys to the lock-box, and of those 8, 5 already know the root password (whew -- what a great sentence :-). From there, they must sign their name and write down the reason they took the root password. As soon as the system staff come in, the password is immediately changed, and a quick audit is done of the file system (all automated in shell scripts, so it's not too difficult). This does rely on the fact that you know everyone who has access to the lock-box, and that they can be trusted to sign for the password when they take it. We've only had one problem with this, and that was when a new admin on one of our smaller machines thought he had a valid reason to access the password, and did so. When we came in, we found the machine in single-user mode with no one in sight. That operator was "re-educated", and we haven't had any problems since then. It is important to make the envelope fairly tamper-resistant (we use a thick manilla (opaque) envelope with a smaller envelope inside of it. Both are sealed, and the outer one is taped shut. We've never had a problem with someone trying to open it without being noticed. Another security feature you could add to make this safer is to have a video camera trained on the lock-box and run it all day long. If you had any doubts about someone breaking in, just check the tape. Well, that's my $0.25 worth. Steve DeJarnett System Manager Cal Poly San Luis Obispo steve@polyslo.CalPoly.EDU From: deh@eng.umd.edu 3-MAY-1989 17:28:37 To: 34AEJ7D@CMUVM.BITNET Subj: [1052] Re: Dusting Simplex locks Cc: security@pyrite.rutgers.edu I agree that you should use whatever you can get your hands on for illumination of code buttons; I mentioned laser dyes because I happened to have a lot of them around at the time that I first tried this, and it worked very well. Most of the dyes that I have used are pretty common, pretty cheap, and to the best of my knowledge none of the ones that I have used have been toxic.... One consideration in choosing the dye to use (for buttons, not for lasers) is what it looks like in regular light, since you don't want people seeing it on the buttons. ANother consideration is the method of application. One reason the laser dyes worked so well was the fact that they were disolved in solvents, usualy alcohol but also ether some times. In a spritzer bottle, these can be sprayed on the target area where they will dry quickly, leaving a very fine and uniform distribution of the dye material which is very likely to escape detection. DO make sure that the solvent doesn't melt the materials that the buttons, etc. are made of though..... Doug From: "David F. Lambert" 3-MAY-1989 18:13:42 To: security@pyrite.rutgers.edu Subj: [1097] Re: password security You'll be better off *not* sharing passwords due to the problems you've raised here as well as other problems that shared passwords can cause. It is more desirable and auditable for you to be able to logon to the "commonly shared" userid with other "authorized" passwords. This method has several advantages: -provides auditability by requiring the "real" logon persons to identify themselves (via their password) -allows you to change passwords of shared userids without contacting all users who logon to those userids (if you still need the "normal" logon password) -makes encrypting passwords more feasible -no need to memorize multiple passwords for various userids Of course, this scheme does imply that more than the single standard password can be used to logon. If you're running VM, which your node name suggests, VMSECURE implemented this scheme nicely in Release 3.2 I believe. VMSECURE calls it the LOGONBY access rule. I'm not sure if RACF or other VM security package equivalents have this feature. -Dave From: John Kinne 4-MAY-1989 6:07:23 To: security@pyrite.rutgers.edu Subj: [583] Re: password security To be effective, the number of people who know a pw must be kept to a minimum. The small department that I am associated with insures that each member of that small group is told the new pw, verbally, in a low voice. > how does a non-administrator get the password in an emergency? That service is unavailable until a staff member can fix it. We strive not to have all members of the support staff absent on the same day. When it is necessary that the complete support staff be absent, then we leave forwarding numbers. If that doesn't work, then the service is unavailable. From: Lynn R Grant 4-MAY-1989 8:18:09 To: SECURITY@pyrite.rutgers.edu Subj: [1678] Password Security The way to know make sure that everyone who needs to know knows when a password changes is to have only one person per userid. This also gets you accountability. As for data set passwords, if you have a good access control system (like the ones my employer makes) you don't need them; since the one userid/password scheme can assure that the person is who he claims to be, you merely need to tell the access control system who can get at what. (Of course, for the accountability to work, you need to do the ordinary stuff about not writing down the passwords, not using your name, or your girlfriends name, or your social security number, or whatever, etc.) One approach to what to do when the security administrator isn't around is to have a special security administrator userid whose password is in a sealed envelope. If your shop is a mainframe shop, you give it to the night shift operations supervisor. Otherwise you put it in a "break glass" sort of box. Every morning, the real security officer checks to see if the envelope has been opened. If so, he immediately changes the password and investigates what was done with it. There is some exposure here, since this is a detective control. If you don't have an access control system with good logging capabilities, you won't know what was done with the special userid. And if the person who uses it is a very sharp crook, he may be able to wipe out the logging anyway, if the userid in the envelope is powerfull enough. But if you can't afford to have full-shift security officer coverage, it works better than giving everyone security privileges. Lynn R Grant Computer Associates International, Inc. From: jwright@atanasoff.cs.iastate.edu (Jim Wright) 4-MAY-1989 9:11:41 To: misc-security@ames.arc.nasa.gov Subj: [1922] END OF VOTE - comp.virus succeeds The voting period for the new newsgroup comp.virus has just ended. The final vote count was 403 YES, 30 NO. I think it's fair to say that significant interest has been shown in this group. The list of voters will be posted in news.groups so you may verify that your vote was recorded. I'll gladly accept any corrections, although it would take a rather colossal error to affect the outcome of the vote. As per the "official guidelines", the group should be formed in approximately five days. (Today being 24-Apr-89.) Look for it soon at a computer near you. There has been some interest in the mailng list virus-l. Comp.virus and virus-l will contain the same information, the only difference being the method of distribution. The following information should assist you in subscribing to the list. Note that it is NOT necessary to subscribe to virus-l if you receive Usenet. Also, if you receive Usenet and subscribe to virus-l, you should unsubscribe once the group comp.virus is formed. There are currently about 1175 direct subscribers to virus-l, so I'm sure Ken would appreciate the reduced load. > ... So, to get onto the VIRUS-L mailing > list, send a mail message to . In the body > of the message, say nothing more than SUB VIRUS-L your name. LISTSERV > is a program which automates mailing lists such as VIRUS-L. > ... > If, in the unlikely event, you should happen to want to be removed > from the VIRUS-L discussion list, just send mail to > saying SIGNOFF VIRUS-L. Finally, we have been hard at work trying to organize a system of anti-viral software archive sites. Through the generous assistance of the individuals at each site, this promises to be a great success. We are still tying up some loose ends. Look for a full announcement of the archive system once comp.virus is in action. -- Jim Wright jwright@atanasoff.cs.iastate.edu From: shipley@tarantula.berkeley.edu (Pete Shipley) 4-MAY-1989 17:36:24 To: misc-security@ucbvax.berkeley.edu Subj: [608] Re: password security Question: What problems will using a modified passwd des crypt function will create. The idea I am tring to present is that if a system was to use a modified version of crypt(3) (and install it in the libaries) and use it for the local password file password enteries wont this prevent the grabing of password files and 'grinding' on a local system. -Pete Pete Shipley: email: shipley@berkeley.edu Flames: cimarron@postgres.berkeley.edu uunet!lurnix!shipley or ucbvax!shipley or pyramid!hippo!{ root peter } Spelling corections: /dev/null Quote: "Anger is an energy" From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 4-MAY-1989 17:55:09 To: security@pyrite.rutgers.edu Subj: [750] Re: Medeco Keys This has gone far enough. When I was in New York, I was living with a cocaine dealer who had a Medeco lock on her front door. I wanted a spare key for my girlfriend, but the landlady wouldn't give one to me. I took the key to a tiny, Israeli locksmith near 98th street and Broadway. He measuered the hights of each using a tool with a triangular hole in it (with calibrations along the side), and wrote down the orientation of each notch. He then took a blank (that did not say "Medeco" on it) put it in a machine and started cutting the key. On each notch, he would change the orientation of the blank in the machine, in accordance with the original. The process took about 4 minutes and cost $5.00. The key worked the first time. -simson From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 9-MAY-1989 21:24:34 To: security@pyrite.rutgers.edu Subj: [269] SSN article Friends, I've received over 20+ messages asking for a copy of the article. I'm happy to post a copy of it if I retain the copyright (I don't know if whole earth review lets me do that or not.) Please don't send me any more requests for copies. Thank you. -simson From: waters@dover.sps.mot.com (Mike Waters) 9-MAY-1989 22:14:08 To: misc-security@uunet.uu.net Subj: [470] Re: MEDCO locks >you can always rekey when an employee leaves (and it's >pretty easy to do so if you use interchangeable-core cylinders). Re-keying is also pretty cheap, it cost me $20 to change all seven locks when I moved into my present house. Don't negelect the obvious and the cheap solutions too! -- *Mike Waters AA4MW/7 waters@dover.sps.mot.com OR waters@cad.Berkley.EDU* Mr and Mrs PED, can I borrow 26.7% of the RAYON TEXTILE production of the INDONESIAN archipelago? From: Victoria Landgraf 9-MAY-1989 23:14:32 To: SECURITY@pyrite.rutgers.edu Subj: [635] Re: Re: MEDECO locks On the subject of hard-to-copy keys, Russwin makes blanks that they don't sell to your corner hardware store; and when you try to get such keys copied at a locksmith's, s/he looks at you funny and says "That's a restricted blank; I don't carry it; you have to get it copied where you got the original." I assume this is a fairly standard tactic among lock companies who want to be able to market a "high-security" line without doing much real work. On the bright side, there's nothing particularly special or complex about a Russwin key, so there's always brickstrap... Victoria From: SUNDSTROM@aboy2.abo.fi 10-MAY-1989 17:34:23 To: security@pyrite.rutgers.edu Subj: [806] Re: MEDCO locks >I have never seen any third party abloy clone >keys, thereby making abloy your only source for key blanks. In Finland we have two different types of Abloy locks (or keys) one 'standard' and one with one or two security slots ("scores"). For the later one, duplicate keys are only obtainable from the factory with an authorized name signature (=signature of the person who bought the lock). The 'standard' key is obtainable from any locksmith. The Abloy locks here are absolutly most common locks a rought approx. is about 95 % of door locks Hans Sundstrom Internet: SUNDSTROM@ABOY2.ABO.FI Heat Eng. Lab. Abo Akademi FINLAND [Moderator toss-in: Abloy originally started in Finland, I believe. I just recently had a longish talk with their Texas office... _H*] From: hollombe@ttidca.tti.com (The Polymath) 10-MAY-1989 18:39:19 To: misc-security@sdcsvax.ucsd.edu Subj: [818] Re: Card Access information request }WIEGAND is by far the best card technology that is available today We here at the CAT factory have a different view. We've always thought our Magic Middle cards were the best technology. (-: }... WIEGAND cards work }by having a thin bi-metal wire embedded in the card. Sorry, I can't talk about how our cards work. I can tell you your Cyclotron Analyser wouldn't affect them. I've also seen one cut in half and taped back together and it still worked. Legend has it one hotshot at Cal Tech was able to crack their encoding. We hired him. (-: -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 11-MAY-1989 3:57:38 To: daedalus!corwin@talcott.harvard.edu Subj: [79] Re: Telephone line security Cc: security@rutgers.edu Indeed, this is why I keep a lock on my Network Interface. Simson Garfinkel From: haynes@ucbarpa.berkeley.edu (Jim Haynes) 11-MAY-1989 4:36:30 To: misc-security@ucbvax.berkeley.edu Subj: [884] Re: Telephone line security These boxes replace the former lightning protectors. Now that you own, and are responsible for maintaining, the wiring inside your house, the box provides a way for you to disconnect all your house wiring and test the circuit at the phone company's demarcation point. Otherwise if you report trouble and they come out and find it's in your house wiring they will charge you a lot for their time and trouble. Just consider it one of the benefits of deregulation... While it does make it a little easier for someone outside to make calls on your phone line, the possibility was always there. With the older units the bad guy had to have alligator clips instead of a modular plug on his phone, that's all. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ...ucbvax!ucscc!haynes "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle From: nichols@cbnewsc.att.com (robert.k.nichols) 11-MAY-1989 5:23:25 To: mmm@cup.portal.com Subj: [1332] Re: High-Tech Knife Cc: security@rutgers.edu I have one of these "CIA letter openers" made by A. G. Russell, Springdale, Ark. I got it as a freebee with an order. I consider it just a novelty. It's pretty ineffective as a knife and too bulky for opening letters. The info sheet that came with it suggested that it could also be used as a tent peg. That's about the best use I can think of for it. Yes, it undoubtedly would pass through a metal detector (but, I am warned, it is NOT invisible to X-ray). If you wanted to sneak something onto an airliner, though, you'd be better off carrying a sharpening stone and using it to hone the cutlery that comes with the "food." -- .sig included a no extra charge. | Disclaimer: My mind is my own. Cute quotes and batteries sold separately. | >> Bob Nichols nichols@iexist.att.com << | [Moderator tack-on: American Airlines has pretty nasty-looking butter knives, that probably wouldn't require too much additional work to be destructive. On a recent round trip I pocketed mine on the way to, and on the way from took it through security and put it in the little metal-things-you're-carrying bucket. They looked real funny at it and wondered why I was carrying it until I pointed out the little "AA" logo engraved into the blade, and told them I was bringing it back. They then let me through with it. _H*] From: steve@nuchat.uu.net (Steve Nuchia) 11-MAY-1989 5:41:35 To: misc-security@uunet.uu.net Subj: [1679] connecting Suns to the internet: pitfalls? A client has a small network of Suns that they would like to connect to the internet. They would accomplish this by bridging to the ethernet operated by the umbrella organization of which they are loosely a part. They have limited experience with this style of networking, having transitioned from VMS/THEnet only recently. They are very concerned about security. Not spooky, just the normal desire to have the system continue to work most of the time. The system is a 3/280 + 4 diskless Sun3 clients; some 386i stuff will be attached soon. All running SunOS4.0.1. The environment is quasi-academic, with lots of students hanging around. The attack scenarios we are most concerned with are the typical things you see at schools rather than sophisticated industrial espionage attacks. I haven't been through this before. I know a bit about security in general and securing a regular timesharing sort of system, but all the networks (and especially NFS systems) I've been responsible for have been isolated. I would appreciate any advice you might have to offer. Something like a checklist of things to button up or turn off seems a good goal, but priciples, platitutes, and references are also welcome. Ultimately I would like to have enough information to be able to tell my client that his system is safe to connect. Please send me mail -- my system is expiring news more often than I can get home to read it. I will condense the suggestions I receive and post a summary. Thank you. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software. From: silber@tcgould.tn.cornell.edu (Jeffrey Silber) 11-MAY-1989 22:59:15 To: misc-security@rutgers.edu Subj: [464] Access control & accounting I am looking for accounting and access control software to run a production Unix (tm) system (2000-3000 users). If anyone has any suggestions please send e-mail. Thanks. -- "A billion here, a billion there, and pretty soon you're talking real money." --Sen. Everett Dirksen Jeffrey A. Silber/silber@tcgould.tn.cornell.edu Business Manager/Cornell Center for Theory & Simulation in Science & Engineering From: ns@maccs.mcmaster.ca (Nicholas Solntseff) 12-MAY-1989 19:15:22 To: misc-security@gpu.utcs.utoronto.ca Subj: [285] Re: DES export laws I have been told by someone in Export Controls in the Pentagon that letting a non-Canadian student (e.g., from the PRC or Poland) use a DES program is legally the same as exporting! Thus, a copy of Dbase III labelled "Not for export" cannot be used in an open lab here. Nick ..... From: "S.J.Leviseur" 12-MAY-1989 19:42:14 To: misc-security@kestrel.ukc.ac.uk Subj: [348] Re: DES export laws >(5) Suppose you take DES binary out and some smart European puts it > back in, over there? As I understand it the terms of the AT&T licence says that I am entitle to use code from all previous releases of Unix. Since I have (legitimately) the DES code from 32V dose this mean that any SysV source code holder can be given it? sean From: Rich Salz 12-MAY-1989 20:57:36 To: hal@gateway.mitre.org Subj: [5722] Re: DES Export Cc: misc-security@uunet.uu.net Hi. A similar question came up in the Usenet newsgroup comp.unix; this is what I wrote. My interest goes back three years when I posted a DES package to world-wide distribution and got scared. /r$ PS: Any other DES-legal discussion in misc-security I can FTP? --------------------------------- Newsgroups: comp.unix Subject: Re: DES software >I need to find a copy (or, preferably, a summary written in English instead >of legalese) of the American regulations that restrict the export of DES and >other cryptographic software. Does anybody know where I can find this? Let me start with a disclaimer: I'm speaking only for myself here, most definitely not for my employer or anyone else I refer to below, and only as an interested layman. You will not be able to find a non-legalese summary. (Hubris makes me want to add "other than this one." :-) You will only be able to find legalese rules and such. Your best bet is to hunt through a law library and a one that has the US Federal Register. There are two popular researched analyses on DES that were distributed on Usenet. One is by John Gilmore, the other is by DEC's Corporate Law Office. Lots of other opinion and "facts" have been offered, but almost without exception they have been based on ignorance; unless you've done research, or have the two primary sources, it's probably safe to ignore everything you've read other than this. (There's that hubris again.) DES export is a complicated issue, and like all legal issues when you get an opinion you should keep in mind the viewpoing of the person who gives it. John wants to spread open information as widely as possible, DEC doesn't want to get hauled into court. I agree with John. >From his readings of the rules and regulations, John determined that DES is technical information, and software. This means that it is under the control of the Department of Commerce. As such, once it is in the open literature, it can be passed around the world. In terms of Usenet and distributing source, this might mean someone would first have to publish their code in a journal somewhere. The only exception to this is if you're on a small list of banned countries, and even that might not hold. DEC claims that John is wrong, that DES is specifically called out as munitions, and therefore is under the control of the Department of Defense, specifically the Munitions Control Act. The upshot is that you can't give it outside of the USA. I'm not a lawyer, but the took John's analysis apart sentence by sentence, ending with "It is imperative that no Digital employee act in reliance on Gilmore's analysis or his conclusions." They even used SCREAMING all-caps. Since neither Department is an expert, the NSA acts as the technical advisory expert. Based on a couple of phone calls, chats with some former employees, and a DES-related meeting, the NSA's position is that DES should not leave the country. Because of this, many Unix vendors have two versions of their software, and it depends on whether they ship the DES cryptographic stuff or not. I remember reading a note from one of the Unix originators, that the only reason there were two versions of Version 7 was more administrative than legal. Perhaps if someone back then was able to fight the red tape we'd be spared all this mess today, perhaps not. I've heard Amdahl got the right permissions to export DES, but I don't know for sure; it was only "planned" at the time I read that note, they may have backed down. DES export has been discussed, at times, in sci.crypt, and in the Kerberos and Internet Engineering Task Force mailing lists. Switching from reporter to interpreter, let me say that I think the situation is changing, and that the stupid US rules may -- applicable or not -- may be lifted soon. Note that soon is measured on a beaurocratic time scale, which is similar to geologic time. The technical community, in particular the Internet, has a good channel into the Department of Defense, and the right word seems to be reaching the right people. There is a need for DES to be used globally, and there has been world-wide publication (in comp.sources.unix/unix-sources) of a package written in Finland, posted from Australia. I no longer have John's analysis at all (it was mostly private email, that he later posted), and I do have the DEC analysis. I don't like to distribute it since it has the look of a DEC internal thing (even though it was forwarded, second-hand, to sci.crypt), and especially since I don't have John's work. It is, however, interesting reading, and if someone is going to take up the fight (as opposed to just idle curiousity), let me know. If you want to play lawyer, here are some places to start: Department of State You want sections 120-126, at least, of the International Traffic in Arms Regulation 22C.F.R Subch. M (I don't know what that last part means.) Office of Munitions Control, Department of State They're responsible for saying if something is "munitions." The National Security Agency I've heard their DES tech expert left, and they're in the lurch. It's funny the way the answer their phones. Department of Defense You want Section 38 of the Arms Export Control Act. Department of Commerce You want the Commodity Control List, and Export Administration Regulations, Section 370.10 and 379.3 (General License GTDA). I like to know what's going on, and I seem to be in touch with the several areas where this is discussed, so if you start digging around, I'd like to know. Yes, that means I'm offering to be a "point man" on this. /rich $alz PS: if ANYONE has a copy of John's research, please let me know; I'll pay you for a copy. From: Sean Casey 13-MAY-1989 5:31:15 To: security@rutgers.edu Subj: [560] Re: DES export laws >I'm trying to find out what's going on with US DES export laws: No problem. A guy in Finland or somewhere wrote a version of DES, which was posted to comp.sources.unix with worldwide distribution. Since it originated outside the US, it does not fall under the export restriction laws. It is a verified version of DES. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** Quid, me vexari? {backbone|rutgers|uunet}!ukma!sean *** ``A computer network should be considerably faster than a calendar.'' -me From: kerchen@iris.ucdavis.edu (Paul Kerchen) 13-MAY-1989 6:15:17 To: security@pyrite.rutgers.edu Subj: [766] Re: password security >password. As soon as the system staff come in, the password is immediately >changed, and a quick audit is done of the file system (all automated in shell >scripts, so it's not too difficult). Hmm, what's the use in using shell scripts if they can be changed by whoever last used the root password? Or, do you keep these scripts off line and just put them on the system when you need to make these checks? If I were a nasty employee (not to imply that you have such people where you are), I would get the password, do my damage, and then change the script to something like: echo "Everything's okee dokee! No reason to be suspicious!" (or whatever the appropriate message is) What's to stop this kind of nonsense? Paul Kerchen | kerchen@iris.ucdavis.edu From: *Hobbit* 13-MAY-1989 6:22:38 To: security Subj: [1898] passwords I've often advocated the following around our shop, but nobody else wanted to bother with it: Administrators would normally be non-privileged, just like any other user, but they'd be able to run a magic program that accepts a *different* password that is unique to the person [taken from /etc/magicpasswd or some such], and if correct drops a root shell [privileged job for non-unix folks] on their terminal. We currently have such a magic program, but it doesn't ask for a password. Okay, so you have to remember an extra password, but BFD. Unfortunately this still doesn't prevent someone from trojan-horsing your .cshrc or other init files, but it does prevent someone random from finding a terminal you left logged in by mistake and whomping all over the system right then. Now, the remaining question is, whether it asks for a password or not: how do you tell before invoking such a thing if you've been trojan-horsed for the next time 'round after something like that happens? You certainly aren't going to want to sit there and read over your own login init every time you want to do something privileged. Answer a is, of course, don't leave yourself logged in on a public terminal; answers b, c, d.. are left to the reader. On a vax I ran a while back I had a fairly elaborate mechanism which would checksum as many of the various init files that the privileged job would invoke that I could find; and if any of them failed it would yell loudly. Said mechanism was protected from prying eyes; it had a separate built-in password, etc, etc. and was probably far more than anyone would normally want to deal with. Naturally, I'd have to go update the mechanism whenever I updated my init files. But by throwing up enough firewalls, even for myself [and typing the appropriate things needed quickly became microcoded into my fingers] made the machine quite a bit more secure. _H* From: Clive Dawson 16-MAY-1989 13:04:22 To: steve@polyslo.calpoly.edu Subj: [384] Re: password security Cc: CHRIS@BROWNVM.BITNET, SECURITY@pyrite.rutgers.edu I'm always amused by the notion of "tamper-resistant" envelopes. I would hope that your scheme includes some means of authenticating the original envelope. What would prevent somebody from tearing open the envelope(s) and placing the contents into identical envelopes sealed in the same careful manner, etc. Are you using sealing wax and a secret signet ring? :-) Clive ------- From: Mr. Stanley Cup 16-MAY-1989 13:43:00 To: @uxv.larc.nasa.gov:security@pyrite.rutgers.edu Subj: [1150] System Security Greetings to all you *net-landers*! I have been recently assigned a task to investigate methods for enhancing security on our "Super Computer Network" (1 Cray 3 Convex). In addition to this, I am supposed to "search and destroy" any security holes. For instance: Our convexes, being 4.2 based, had some *nasty* 4.2 bugs with the set process group, writing to ttys, and chfn. I am trying to compile a set of "test" programs that will check for these and other security holes. Could anyone give me a list of well known and not so well known security holes for 4.2 and 4.3 BSD and System V (UNICOS). Lists, explanations, code to exploit these holes will all be welcome and very much appreciated. Please *do not* post any code, but mail it directly to me at one of the below addresses. Any suggestions for security enhancement (not recently posted) would also be appreciated. Thanks Alot! -=>gretzky<=- .mitch ================================= | gretzky@unison.larc.nasa.gov | root@unison.larc.nasa.gov | gretzky@eagle.larc.nasa.gov | gretzky@uxv.larc.nasa.gov | mitch@teb.larc.nasa.gov | | ================================= From: ron@ron.rutgers.edu (Ron Natalie) 17-MAY-1989 0:35:09 To: misc-security@rutgers.edu Subj: [138] Re: MEDCO locks Not ANY duplicators are set up to do them. To get additional keys, we used to have to order them by number from the manufacturer. -Ron From: rogers@marlin.nosc.mil (Rollo D. Rogers) 17-MAY-1989 1:06:35 To: NCASTELLANO@eagle.wesleyan.edu Subj: [238] Re: car locks Cc: security@pyrite.rutgers.edu hi, have you heard of the latest lock for vehicles here in S. Calif. which is called the "Club". If yes, what is your opinion as to how secure from theft a car with this club locked onto the steering wheel would be? REgards, RollO~~ From: Mr. Stanley Cup 17-MAY-1989 12:31:41 To: @uxv.larc.nasa.gov:security@pyrite.rutgers.edu Subj: [1414] Password Security Subject: Password Security and multiple users per account (password) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DON'T (it's that simple) Two comments: 1) On the system that I am running, I have a program called "do" which will allow users to execute commands as root. The user must be in a "doers" file and a member of the "cando" group. The "doers" file can also restrict members of "cando" to a limited set of commands. All commands executed using do are logged (including failed command attempts), of course one can get around the logging by "doing" a command which allowed shell escapes (but I am working on that). 2) Have overhead accounts, 1 for each person that needs the password, and give them all the same user-id. (ie). root:/\/\/\/\/\/\:0:1:Root of All Evil:/:/bin/tcsh nobody:*:-2:-2::/: daemon:*:1:1::/: ... audit:*:9:9::/etc/security/audit:/bin/tcsh ... need1:abcdefghij:9:9:Mr. John Doe:/etc/security:/bin/csh need2:klmnopqrst:9:9:Ms. Jane Doe:/etc/security:/bin/csh ... Now if "need1" logs in with his password, then he becomes "audit". The same goes for "need2", but with her password. You can check wtmp for the last time that they logged in, and use lastcomm to see what they did (under "audit"). Of course this is *NOT* a good idea for root access. -- For root acess, use something like "do" -- >>> Just my 6 pence worth <<< -=>gretzky<=- .mitch From: AIDE Hugh Hazelrigg 18-MAY-1989 9:32:38 To: hobbit@pyrite.rutgers.edu Subj: [555] orange book About a week ago someone posted an article to misc.security which had some info on where to find the "Orange Book." Well, someone named Danny at the Federal Information Center had never heard of the "National Computer Security Center [publications office]" (which was the name of the source in the posting), nor the Orange Book nor Rainbow Set. He sounded like he really wanted to help, but needed more information. Can you or anyone in m.s provide it? Thanks in advance. Hugh [Moderator note: "Dunno" -- can anyone else clarify for him? _H*] From: nugent@anubis.uchicago.edu 18-MAY-1989 10:07:49 To: security@pyrite.rutgers.edu Subj: [722] Re: Medeco Keys Cc: simsong@idr.cambridge.ma.us Medeco patents each of their key blanks. The patents on the older keyways ran out a couple of years ago and blanks started showing up, which is one of the reasons that Medeco has moved into the Biaxial locks. I would be interested to know if the key you had copied had a round or a square shoulder end(the part you hold onto). I think all the older keyways had round keys. It is certainly interesting news if the Biaxial Medeco key blanks are available in spite of the patent infringement. Of course as people have pointed out, if you are good with a machinest's file or a milling machine, not having the key blank is not a problem. But that kind of person is difficult to keep out of a bank vault as well. Todd From: rjg@sialis.mn.org (Robert J. Granvin) 18-MAY-1989 10:30:45 To: misc-security@uunet.uu.net Subj: [1160] Re: Medeco Keys Please realize the whole point is that Medeco locks and keys aren't that they can't be duplicated, but that they are normally very difficult to do so. The vast majority of people wanting to make a copy won't go through the effort to find someone as you described, and if they did, they probably wouldn't have the same first time success rate. Doing so, depending on the environment where the key is intended for, may show criminal intent. You can't really say that about your normal household locks you get from the hardware store. On the other hand, picking a Medeco lock is again, significantly more difficult than other locks. Nothing is 100% guaranteed secure, but you can make the "average" criminal go somewhere else and leave you alone. This is generally the goal. The only way that you can prevent keys from being duplicated is don't put a keyed lock on a door, and don't distibute keys for that lock that doesn't exist. -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg From: Clive Carmock 19-MAY-1989 0:42:24 To: misc-security@ukc.ac.uk Subj: [727] Medeco Keys For some time I have tried to have a duplicate Medeco key cut, which operates a key switch. The kwy switch is effectively useless to me until I get spare keys. It was part of a disused lift (elevator) car panel and was the SERVICE keyswitch. The panel was imported from the US from a company called GAL Elevators of (I think New York). The key bears the number R63 LF. I was told by a UK locksmith that the number meant nothing to him, but he did know that the final two letters were connected with the company/locksmith who issued the keyswitch. I wonder if anyone could throw some light onto this and tell me where I may be able to get spare keys cut. Thanks CLive Carmock (cca@expya.uucp OR cca@cs.exeter.ac.uk) From: biocca@bevb.bev.lbl.gov (Alan Biocca) 19-MAY-1989 1:18:46 To: misc-security@ucbvax.berkeley.edu Subj: [922] Re: MEDCO locks Rekeying isn't difficult or expensive to do yourself, either. I recently bought a $20 kit for schlage rekeying at the local Home club. It comes complete with instructions and some tools, all you need is screwdriver and pliers. Re-keying requires that you have both new and old keys, so it works best if you have a collection of keys to pick from when rekeying. You could file a key and make a new one, too. There is a gauge included that could be used to determine when the filing had reached a new 'standard' depth. The kit also includes a large quantity of each standard pin size as well as replacement springs in case they get lost or lose their force. I've done fifteen or twenty locks now and since you exchange pins rather than lose them you can almost handle an indefinite number of locks. Eventually you'll run out of a particular size and have to buy more of them or a new kit. Comments by Alan K Biocca From: *Hobbit* 19-MAY-1989 4:34:26 To: ??? Subj: [3618] Orange book responses An amazing number of replies came in. I have included a couple of the most informative for the benefit of anyone else who was curious. Hugh's question has been answered, in serious overkill fashion -- y'all can stop sending them in now, I'm drowning over here! Thanks to everyone else who passed on information... _H* **************** Date: Thu, 18 May 89 09:04:34 -0400 From: (Jeffrey A. Edelheit) Subject: Re: orange book To: AIDE Hugh Hazelrigg The "orange book" is actually titled "Department of Defense Trusted Computer System Evaluation Criteria." It is a DoD standard (DOD 5200.28-STD) and is dated December 1985. The orange book (sometimes also called the TCSEC), is one of a number of publications put out by the NCSC in the so-called Rainbow Series. Each publication has a different color cover and all deal with some aspect of computer security. The "red book", also called the TNI, is the Trusted Network Interpretation of the TCSEC. There are also books on passwork guidelines, guide to audit, guide to discretionary access controls, etc. The best source is the US Government Printing Office. There may be one near you; otherwise, you can reach them at (202) 783-3238. "All prices include postage and handling" and "Use your MasterCard or VISA" (These quotes come from a GPO Catalog.) The telephone number I gave is for Washington, DC and is open from 7:30 am to 4:00 pm Eastern time. The GPO order # for the TCSEC is 008-000-00461-7 and costs $6.00. The GPO should also have other titles within the rainbow series for sale. Jeff Edelheit (edelheit@gateway.mitre.org) The MITRE Corporation 7525 Colshire Drive McLean, VA 22102 (703) 883-7586 **************** Date: Thu, 18 May 89 07:29:39 PDT From: faigin@aerospace.aero.org Subject: Re: orange book To: security@rutgers.edu The "Orange Book", also known as the Department of Defense Trusted Computer System Evaluation Criteria, is DoD Standard DOD 5200.28-STD. You should be able to get it via this number through the US Goverment Printing Office. As for the other "rainbow" books... the ones I have sitting on my desk are: Colour Number Title Lt. Green CSC-STD-002-85 Department of Defense Password Management Guideline Yellow CSC-STD-003-85 Computer Security Requirements Yellow CSC-STD-004-85 Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements Tan NCSC-TG-001 v.2 A Guide to Understanding AUDIT in Trusted Systems Red-Orange NCSC-TG-003 v.1 A Guide to Understanding DISCRETIONARY ACCESS CONTROL in Trusted Systems Red NCSC-TG-005 v.1 Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria Peach NCSC-TG-006 v.1 A Guide to Understanding CONFIGURATION MANAGEMENT in Trusted Systems Dark Red NCSC-TG-007 v.1 A Guide to Understanding DESIGN DOCUMENTATION in Trusted Systems Grey NCSC-TG-009 v.1 Computer Security Subsystem Interpretation of the Trusted Computer System Evaluation Criteria (if there are ones I am missing, I would like to know) In terms of ordering, I would check with the US Govt Printing Office, or directly with the NCSC. Their address is NCSC, 9800 Savage Road, Fort George G. Meade, MD 20755-6000. Daniel -- Work :The Aerospace Corp M8/055 * POB 92957 * LA, CA 90009-2957 * 213/336-3149 Home :8333 Columbus Avenue #17 * Sepulveda CA 91343 * 818/892-8555 Email:faigin@aerospace.aero.org (or) Faigin@dockmaster.ncsc.mil Voicemail: 213/336-5454 Box#3149 * "Take what you like, and leave the rest" From: goldstein%star.DEC@decwrl.dec.com (Andy Goldstein) 21-MAY-1989 0:17:31 To: misc-security@ucbvax.berkeley.edu Subj: [536] Re: password security > The idea I am tring to present is that if a system was to use a modified > version of crypt(3) (and install it in the libaries) Well, the problem is that by virtue of this mail you've now announced to the world that you're running a modified crypt(3) (or might be). So all the crackers have to do is take your version of crypt along with your password file. Your best bet is to convince your users (by moral suasion or, preferrably, software) to not use dictionary words as passwords. - Andy Goldstein VMS Development From: "Craig Finseth" 21-MAY-1989 0:50:59 To: shipley@tarantula.berkeley.edu Subj: [570] password security Cc: security@pyrite.rutgers.edu What problems will using a modified passwd des crypt function will create. I assume that you mean "modifed from UNIX" and not "modified from DES". wont this prevent the grabing of password files and 'grinding' on a local system. This wouldn't stop someone from compiling the grind program on your system and running it from afar. I suggest putting your effort into (1) creating a shadow password file and (2) making /bin/passwd reject "too-obvious" passwords. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 From: Joe Wieclawek 22-MAY-1989 1:33:00 To: security@pyrite.rutgers.edu Subj: [463] Computer hacker working on another plea bargain An article in the 6 May 1989 'Los Angeles Herald Examiner' reports: Attorneys said yesterday they are negotiating a second plea bargain for computer hacker Kevin Mitnick, whose first offer to plead guilty was scuttled by a judge because it called for too little time in prison. Mitnick, 25, of Panorama City (CA) offered in March to serve one year in prison and to plead guilty to computer fraud and possessing unauthorized long-distance telephone codes. From: heilpern@brl.mil 22-MAY-1989 2:00:37 To: security@pyrite.rutgers.edu Subj: [746] Re: password security In theory, you can use any encryption you would like in place of the crypt command (or, for that matter, no excryption whatsoever.) The problem presented is this: All old excryptions will obviously be incompatable with the new encryption routine, so for every user on your system, you will have to erase their password and create another, using the new encryption method. (This can probably be accomplished by creating a program that is similar to 'passwd', but operates on a copy of the /etc/passwd file, give users, say, 2 days to 'install their future password', and after that two days, replace the login command and the /etc/passwd file.) However, if this is a new system you are setting up, things will be extremely easy for you!! --M. From: Dr. T. Andrews 22-MAY-1989 2:23:49 To: shipley@tarantula.berkeley.edu (Pete Shipley) Subj: [1357] Re: password security Cc: security@pyrite.rutgers.edu I suspect that you would be OK if you made the change to crypt(3), and assured that the few minor items mentioned below have been seen to. (a) Only the password encryption routine is affected. anyone using the standard setkey/encrypt package in the same module must be left unaffected! (b) You get ALL of the programs re-built and installed at the same time. That includes passwd(1), login(1), newgrp(1), su(1) wheel(1), wheelg(1), &c. (c) You have some magical way to get your users to (1) all be logged in when you make the change, and (2) get them to all change their passwords NOW. (d) You ferret out the local stuff which also depends on crypt(3) and re-build it. Someone has something which needs a password to run, and he didn't tell you about it. (e) Something at boot-up may want a password, too. Don't forget to fix it! (f) You replace your old back-ups with the old encryption in /etc/passwd and /etc/group and /etc/d_passwd and any other files with passwords. Summary (too late to do you much good:-) Considering the effort, and the danger, and the certainty that you will miss something important, I would advise that you give up the idea. Otherwise, you will likely be unhappy. Even if you think you are happy, what happens when you get the next version of the OS? Dr. T. Andrews, Systems CompuData, Inc. DeLand From: Michael Stack 23-MAY-1989 5:25:27 To: "David F. Lambert" Subj: [312] Re: password security Cc: Security Topics Discussion List > ... I'm not sure > if RACF or other VM security package equivalents have this feature. "group logonids" are a standard feature of ACF2/VM and are intended to provide accountability for the use of VMs like MAINT. Michael Stack Northern Illinois University From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 23-MAY-1989 5:52:25 To: RS@ai.ai.mit.edu Subj: [521] Re: Telephone line security Cc: security@rutgers.edu Why use a 7/16" socket wrench and a butt set when you can just walk to the next network interface? That's the whole point of security; make it more difficult to break into you than to break into somebody else, and more difficult than its worth. ---simson From: "Robert E. Seastrom" Subject: Re: Telephone line security To: idr!simsong@garp.mit.edu Yep. A lot of good it will do you if someone should come along with a 7/16" socket wrench and a butt set. Try it. ---Rob From: WHMurray@dockmaster.ncsc.mil 23-MAY-1989 6:18:04 To: security@rutgers.edu Subj: [1488] Sharing of Passwords >To be effective, the number of people who know a pw must be kept to a >minimum. The small department that I am associated with insures that >each member of that small group is told the new pw, verbally, in a low >voice. (I am unable to tell whether this posting is "tongue-in-cheek." I will assume that it is intended to be sincere.) In order to be effective a password must be known by no more than one person. In the kind of open systems in which we deal (i.e., with many privileged users), the only way to be sure that it is known to only one person is to use it only once. The solution to this dilemma, dealt with many times in this forum in One-time password generators. This mechanism also provides for the passing and withdrawing of high privilege, since, unlike a password, the generator can be returned. (The discussion by the "secure" installation where five people know the root password and another copy is kept in a lock box is too absurd to deal with. If a system is so unstable that it takes five people with privilege to keep it up, it cannot be said to be secure in any meaningful sense anyway, but if five people share the password any way, then how you protect and account for the use of any copy is not material.) William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 23-MAY-1989 23:48:45 To: security@rutgers.edu Subj: [498] paper reference Date: Fri, 5 May 89 16:02:57 EDT From: vicka@vax.ftp.com (Vicka Corey) To: simsong@idr.cambridge.ma.us Subject: security Oops, that's a paper, not an RFC. Reference follows: ps. For the rest of the tcp-ip community... it's an excellent paper, and it isn't very long. As the add says, "if you only read one paper this year, make it _Security_Problems_in_the_TCP/IP_Protocol_Suite_, by S.M. Bellovin in the ACM Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April 1989." From: cme@cloud9.stratus.com (Carl Ellison) 24-MAY-1989 19:43:36 To: linus!misc-security@ursa-major.spdcc.com Subj: [484] Re: password security You don't have to erase old encrypted passwords when you change algorithms -- just be prepared to accept either, for a while -- ie., use both algorithms to create two strings to match against the password file -- and if either works, the user is logged in. If it's the wrong one which worked, you can nag or threaten.... --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course) From: nevin1@cbnewsc.att.com (nevin.j.liber) 24-MAY-1989 20:17:42 To: misc-security@att.att.com Subj: [703] Re: password security |So all the crackers have to do is take your version of crypt along with |your password file. But what if the new version of crypt is not public (the source code does not exist on a publicly accessible machine, and the appropriate permission bits are set so that the executables are not readable, etc.)? Unless one is willing to apply cryptographic techniques to determine the algorithm (in which case you probably need more security than just password protection, anyway), this still seems like an improvement over using the standard crypt for passwords (assuming the new algorithm is sufficiently good, of course). -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751 From: steve@polyslo.calpoly.edu (Steve DeJarnett) 24-MAY-1989 20:24:25 To: kerchen@iris.ucdavis.edu, security@pyrite.rutgers.edu Subj: [977] Re: password security >Hmm, what's the use in using shell scripts if they can be changed by >whoever last used the root password? Or, do you keep these scripts off >line and just put them on the system when you need to make these checks? The version I use to check things lives in my bedroom at home. If these people can break into my house and modify the tape, then I guess I have larger problems than system security :-|. The fact that few people (until I sent this note out :-) knew that such scripts even existed makes it a little less likely that they'd be found (they also live so far down in the filesystem that I occasionally have trouble remembering where they are). When we do check the system, though, we either make a visual check of the scripts before running them, or bring my tape in from home. Of course, University security requirements aren't QUITE as stringent as those required by, say, the DoD. Steve DeJarnett Cal Poly San Luis Obispo steve@polyslo.CalPoly.EDU From: gwyn@brl.mil 31-MAY-1989 3:36:38 To: security@rutgers.edu Subj: [290] Re: DES Export Not long ago I got inside word that AT&T had asked for a determination of the export status of their UNIX crypt routines, the outcome of which was essentially that individual approval would have been readily obtained, but not blanket "warehouse" approval. This seems pretty silly to me.. From: ron@ron.rutgers.edu (Ron Natalie) 2-JUN-1989 22:15:23 To: misc-security@rutgers.edu Subj: [375] Re: System Security UNICOS, at least as I saw it two years ago, had no pretense at security. It was quite easy to do things that would crash the machine, and only moderately more difficult to get unauthorized access to root. You might ring up your colleagues at NASA-AMES, who certainly have much more experience with UNICOS that I do. They're also pretty sharp on the security scene. -Ron From: zeleznik@cs.utah.edu (Mike Zeleznik) 2-JUN-1989 22:39:25 To: security@rutgers.edu Subj: [537] Re: System Security > Could anyone give me a list of well known and > not so well known security holes for 4.2 and 4.3 BSD and System V (UNICOS). You might check out Bob Baldwin's stuff (MIT) for rule-based analysis of UNIX system security. He had a paper in CompCon Spring 87. Also, "UNIX System Security" by Wood and Kochan, Hayden Books. Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617 From: andrews@apple.com (Richard Andrews) 6-JUN-1989 7:00:54 To: misc-security@ucbvax.berkeley.edu Subj: [379] Re: DES Export From my own experience, it seems to me that DES per se is not excluded from export. It just depends on how you use it. I worked on a product, the AppleShare File Server, that uses DES to encrypt passwords, and that was granted a Commerce Jurisdiction (meaning Apple is free to export it). Clearly, we would not have been able to export it if we used DES for file encryption. From: cme@cloud9.stratus.com (Carl Ellison) 6-JUN-1989 7:34:57 To: linus!misc-security@ursa-major.spdcc.com Subj: [456] Re: DES export laws This is getting out of hand.... If it weren't so silly, I'd rant and rave for pages about it. What makes DES written here so secret when the one written in Finland (acc. a recent posting) isn't?????? We're locking the barn door -- with the horse inside -- but after the back wall fell down. --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course) From: alo@kampi.hut.fi (Antti Louko) 6-JUN-1989 7:53:02 To: misc-security@cwi.nl Subj: [1468] Re: DES export laws > Thus, a copy of Dbase III labelled > "Not for export" cannot be used in an open lab here. Software vendors could do the following: Take their software product without any non-export stuff to some of their labs outside US. At that site, include some outside-US DES-package into their product, or even better, ship their product in relocatable form, so customer can link any encryption package with it. My DES-package can be used freely for non-commercial purposes. If a vendor ships my DES-package in source code (and optionally in relocatable code) with their product so that customer can link it together himself, I consider this as non-commercial use. The idea is that the customer could do the same even if the vendor wouldn'n provide the DES-package. If the vendor packages their product and DES together (eg. linking them into an executable) I consider this as a commercial use. In my opinion: Software vendors should ship all their software also in reloacatable form!! My DES-package is available by ftp at kampi.hut.fi (128.214.3.9) at directory /alo/ ------------------ alo@santra.UUCP (mcvax!santra!alo) Antti Louko alo@hut.fi Helsinki University of Technology alo@fingate.bitnet Computing Centre alo%fingate.bitnet@cunyvm.cuny.edu SF-02150, Espoo FINLAND tel. +358 0 4514314 ------------------ From: Doug Claar 6-JUN-1989 23:14:43 To: security@pyrite.rutgers.edu Subj: [542] Re: Security Digest > I'm always amused by the notion of "tamper-resistant" envelopes. I Yes, what about the 'see-thru' spray being sold by Sharper Image, or some such company. "Makes envelopes transparent without leaving a trace!" The post office is not amused, but I don't think they can do much about it, since there is (in tiny type, at least in the ad), a warning that using the spray on U.S. Mail is against the law. Doug Claar HP Computer Systems Division UUCP: mcvax!decvax!hplabs!hpda!dclaar -or- ucbvax!hpda!dclaar ARPA: dclaar%hpda@hplabs.HP.COM From: "MOG::REX"@isdmnl.menlo.usgs.gov (Rex Sanders) 6-JUN-1989 23:54:59 To: security@pyrite.rutgers.edu Subj: [675] RE: passwords On our 4.3 BSD Unix system, we have three people that need root permissions. We used to all know the root password. Then, a security directive came around: one account, only one person knows the password. We set up three accounts, with names other than "root", and uid 0, gid 1. Each account has it's own password, and I changed the "root" password to something I've already forgotten. We put hooks in /.login and /.cshrc to source files of our own. This scheme has worked fine for several years now. To help other users identify "root" users when logged in, we named the other accounts with root vegetable names - mine is "radish". -- Rex rex@isdmnl.menlo.usgs.gov From: deh@eng.umd.edu 7-JUN-1989 0:31:42 To: AI.CLIVE@mcc.com Subj: [599] Re: password security Cc: security@pyrite.rutgers.edu there are envelopes that close with a holographic foil that is then embossed. The image is somewhat unique in that it has a serial number on(in?) it, visible. Since they are serial numbered, you can't just replace it, and they seem to be very fragile in that you can not peal them off without a lot of visible and obvious damage. Of course, they are most likely VERY expansive, (yow! I think I meant expensive!) since I only know of one place that uses them at all, and only then for very sensitive things, and they DON'T like it when people take them home for their kids to play with ! Doug From: "John Schlosser" 7-JUN-1989 22:32:29 To: "Security List" Subj: [666] Car locks From what I've seen, the "club" only blocks the steering wheel from turning more than a few degrees any way because of the way the club is attached. This works great if a would-be thief has the intention of driving away with your car, but what if he/she/it just wants to strip it bare of anything that's in it? A large metal pole that's attached to the steering wheel isn't going to do much good then, will it? John P. Schlosser (URSJ@MARISTC) Student Staff Programmer Marist College Computer Center .Nothing I say in any way reflects anyone's opinion other than my own. .I am not affiliated with THE CLUB's makers, distributors, advertisers or anyone else. From: barnett@unclejack.crd.ge.com (Bruce Barnett) 7-JUN-1989 23:03:16 To: security@pyrite.rutgers.edu Subj: [930] Re: Medeco Keys >On the other hand, picking a Medeco lock is again, significantly more >difficult than other locks. I was talking to someone selling home security units. He laughed at a Medeco lock, saying someone invented a device that lets you pick/defeat it in minutes. Of course he wanted to sell me HIS security system. -- Bruce G. Barnett a.k.a. uunet!crdgw1.ge.com!barnett [Moderator tack-on: He was probably talking about the various Medeco "mapping" devices, that were actually patented at one point. I doubt if these tools were ever marketed to locksmiths; they utilized some weaknesses of the cylinder in really bizarre twisted ways, such as shoving a small wire up the twist-limiting guide slot to feel where the top of the pin was.You would still have to cut a key based on what the tool told you. You might ask this fellow if he ever *saw* these tools being used... _H*] From: hollombe@ttidca.tti.com (The Polymath) 8-JUN-1989 2:49:37 To: misc-security@sdcsvax.ucsd.edu Subj: [749] Re: car locks } hi, have you heard of the latest lock for vehicles ... called the "Club". Probably a little less secure than with the type of lock that runs from the steering wheel to the brake or clutch pedal. (The "Club" just locks on the steering wheel, making it difficult or impossible to turn completely around). I'd guess a large pair of bolt-cutters would get either one off in a few seconds. (If they won't cut the lock, cut the steering wheel. Car thieves aren't known for finesse). -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe From: Jeff Makey 8-JUN-1989 3:22:18 To: security@rutgers.edu Subj: [1224] Re: High-Tech Knife I carry an ordinary Boy Scout knife in my pocket the same as I carry my wallet and keys. When I fly, I usually just put the knife and other metal objects I have into my briefcase to be x-rayed and I have never had any problems. About a month ago I went through airport security (in San Diego) without anything to be put on the x-ray belt, so I just pulled the knife out of my pocket and placed it on one of those little trays they have for change and stuff. As I walked through the metal detector the guard picked up my knife and looked at it. He opened the blade part-way (perhaps to see if it was a switch-blade? or to check the size of the blade?), closed it, and gave it back to me without comment. A similar thing happened about 9 years ago in Chicago, except the guard told me, "just don't kill anybody." Seriously! It sounds as if the airline security folks are fairly sensible about the types of things you can and can't take on an airline with you. I would be shocked if they tried to prevent me from taking on board my mechanical pencil, which is a pointed metal object about the same length as my open Boy Scout knife. :: Jeff Makey Makey@LOGICON.ARPA From: lamaster@ames.arc.nasa.gov (Hugh LaMaster) 8-JUN-1989 3:35:18 To: misc-security@ames.arc.nasa.gov Subj: [1927] Re: Consensus on locks? I have seen many postings on a variety of problems with so-called high security standard-cylinder-type locks. While no such lock is perfect, it would seem that there might be a consensus that some particular product line is the least likely to be easily picked or forced by garden- variety burglars, and may even slow down an expert. If there is such a consensus on a company/product line, I would appreciate knowing what it is. A sort of related question is: I have seen locks with automatic "dead bolts" - meaning, locks in which opening the door with a key from the outside (not in the handle) pulls back a full-sized spring loaded bolt, which closes when the door is closed. The obvious idea is to prevent "loiding" (I think this is the term...), and also to provide more resistance to forcing than the relatively narrow bars which are used on some locks for the same purpose. Does anyone know the availability of these locks and whether they have any advantage over the standard narrow bar type? (I am no lock expert, in case it isn't obvious :-) ). I assume that such a lock would have to be well lubricated to allow the torque of a key to open a large bolt, but what other disadvantages are there? Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117 [Moderator toss-in: The usual way manufacturers of spring-loaded latches prevent carding, loiding, sliding, whatever you want to call it, is to provide an extra latch piece that is pushed into the mortise edge when the door is closed, and engages a catch that prevents the main latch from being pushed in. These are well-known to, um, not work in many installations. The sure- fire way to lock the door is a dead bolt or better, but you can't just slam the door closed. If you're a chronic loser of keys, this could be good! _H*] From: Stephen Wadlow 8-JUN-1989 10:24:41 To: biocca@bevb.bev.lbl.gov (Alan Biocca), misc-security@ucbvax.berkeley.edu Subj: [791] Re-keying [Was: Re: MEDCO locks] Rekeying is feasible depending on the availability of pins. Many cylinders use a fairly standard pin (.115 in diameter, frequently in .003 or .005 increments). Medeco and a few other companies (Best comes to mind) use different size pins that aren't as easily available. Medeco also requires very specific types of pins if they are addressing the sidebar, otherwise, other pins are useless. What I would really like to see is more venders going to the hex-nut caps that medeco uses. It would make re-keying much easier and quicker. steve ====================================================================== Stephen G. Wadlow Internet: stephen.wadlow@andrew.cmu.edu Bitnet: wadlow@drycas "Hey Man, A ship in harbor is safe, but that ain't what ships are for" From: hal@gateway.mitre.org (Hal Feinstein) 8-JUN-1989 17:10:38 To: -v@gateway.mitre.org, security@pyrite.rutgers.edu Subj: [633] very fast DES is near Cc: infsecur@smiley.mitre.org I've just gotten the word that a substantially reworked version of DES will soon become public. The version eliminates the piple-line structure of FIPS 46 and replaces many of the bit picking that slows most computer implementations. I havn't been told how much of a speed up this will have over the FIPS 46 version of the algorithm. The new version has eliminated some of the "rounds" structure of the current algorithm and still computes the same DES process. Speculation is that it will make file and bulk based DES faster and less expensive and will provide a base for faster IC implementations. More as I find it out. From: "David D. Grisham" 8-JUN-1989 17:20:53 To: security@ubvm Subj: [994] PC Network Security Has anyone had experience with fileserver security? I am reviewing our new fileserver proposed setups. Novel SFT 2.15 and Appleshare 2.0 in a 50 station pod. What safeguards are you all using? Any hacker or virus problems? General and specific information would be appreciated. Also, we are going to keep stats on use (Saber on Novel). What menu/usage tracking software are you using and is it safe and effective? In return I can help with Mac specific viruses with policies and tools. On the DOS side we have been using notchless disks in our remote pods- Novel looks like a potential problem- yes or no? We have been running an Appleshare for a year and have it up, running, and safe 99% of the time in a small lab. Dave Grisham, Senior Consultant/Virus Security Phone (505) 277-8148 Computer & Information Resources & Technology University of New Mexico USENET DAVE@UNMA.UNM.EDU Albuquerque, New Mexico 87131 BITNET DAVE@UNMB From: viusys!rwb@daitc.mil (Rick Butland) 8-JUN-1989 22:11:48 To: security@rutgers.edu Subj: [382] Encryption Software For PC's As the subject says, is anyone aware of a software package that will encrypt files on DOS? Actually, what's desired is the ability to compose a msg on a PC, encrypt it, and mail it to another PC user, where both PC's are attached to a Unix host. Most likely, though, rather than mail, the messages will just be uploaded/downloaded. Thanks in advance, Rick Butland (rwb@viusys) From: SIANI@nssdca.gsfc.nasa.gov 8-JUN-1989 22:28:01 To: security@rutgers.edu Subj: [3542] RE: Kevin Mitnick >Attorneys said yesterday they are negotiating a second plea >bargain for computer hacker Kevin Mitnick Kevin Mitnick, the hacker "so dangerous that he can't even be allowed to use a phone". "He could ruin your life with his keyboard". "Armed with a keyboard and considered dangerous." These are some of the things that have been said about this person. All of this media hype would be fine if it just sold news papers. But it has done much more then just sell a few papers. It has influenced those that will ultimately decide his fate. I myself don't know the man, but I have talked to others that do. Including one of the persons that investigated Mitnick. From all I have heard about him, I think he is a slime ball! But even a slime ball should not be railroaded into a prison sentence that others of equal or greater guilt have avoided. I personally feel the man is just a criminal, like the guy that robs a 7/11, no better but certainly not any worse. Unfortunately he is thought of as some kind of a "SUPER HACKER". The head of LA Police Dept's Computer Crime Unit is quoted as saying "Mitnick is several levels above what you would characterize as a computer hacker". No disrespect intended, but a statement like this from the head of a computer crime unit indicates his ignorance on the ability of hackers and phone phreaks. Sure he did things like access and perhaps even altered Police Dept. criminal records, credit records at TRW Corp, and Pacific Telephone, disconnecting phones of people he didn't like etc. But what is not understood by most people outside of the hack/phreak world is that these things are VERY EASY TO DO AND ARE DONE ALL THE TIME. In the hack/phreak community such manipulation of computer and phone systems is all to easy. I see nothing special about his ability to do this. The only thing special about Kevin Mitnick is that he is not a "novice" hacker like most of the thirteen year old kids that get busted for hacking/phreaking. It has been a number of years since an "advanced" hacker has been arrested. Not since the days of the Inner Circle gang have law enforcement authorities had to deal with a hacker working at this level of ability. As a general rule, advanced hackers do not get caught because of there activity but rather it is almost always others that turn them in. It is therefore easy to understand why his abilities are perceived as being extraordinary when in fact they are not. Because of all the media hype this case has received I'm afraid that: 1.) He will not be treated fairly. He will be judged as a much greater threat to society then others that have committed simular crimes. 2.) He will become some kind of folk hero. A Jesse James with a keyboard. This will only cause other to follow in his footsteps. I'm not defending him or the things he has done in any sense. All I'm saying is lets be fair. Judge the man by the facts, not the headlines. Disclaimer: The views expressed here are my own. Kenneth Siani Sr. Security Specialist Information Systems Div. NYMA Inc. Internet Mail: siani@nssdca.gsfc.nasa.gov From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 10-JUN-1989 22:29:59 To: elbows@bloom-beacon.mit.edu, security@rutgers.edu Subj: [435] ISDN I am doing an article on ISDN for The Boston Globe. The artice would like to write about all of the problems with ISDN, all of the advantages, what people's experience have been (both positive and negative), and where things are going. If anybody would like to give me a call or email, and flame, this is your chance!!! Simson L. Garfinkel 409 Washington Street Cambridge, MA 02139 617-876-6111 simsong@idr.cambridge.ma From: leichter@cs.yale.edu (Jerry Leichter (LEICHTER_JERRY@CS.YALE.EDU)) 10-JUN-1989 22:55:17 To: misc-security@uunet.uu.net Subj: [1293] Re: DES export laws Try substituting "tanks" for "DES implementations". There are many manufac- turers of tanks in the world; their products are not subject to US control. Should the US therefore be willing to export tanks to anyone who wants them? One can certainly criticise the export controls that now exist for being poorly stated, or ineffective, or any of a variety of other things. Certainly the way they ARE stated can make them look very silly. But it bothers me to see a complete unwillingness to understand that there is a real, underlying issue here. Suppose the US manufactured military radios containing very strong encryption technology. Should we be willing to sell those to anyone who wanted them? Suppose the basic technology for the radios was readily available, but the encryption chips that made the radios used secret technology. Should we sell the encryption chips to anyone who asks? If your answer to this question is different from the previous one, can you explain why? Now suppose the algorithms of the encryption chips were public knowledge, but actually implementating them as chips with sufficient speed, reliability, low power consumption, whatever, was very hard. Does your answer change? Lines are hard to draw. But laws require them to be drawn. -- Jerry From: WMURRAY@dcm1wm.das.net 10-JUN-1989 23:08:04 To: security@rutgers.edu Subj: [3350] Export of the DES >Not long ago I got inside word that AT&T had asked for a determination >of the export status of their UNIX crypt routines, the outcome of which >was essentially that individual approval would have been readily obtained, >but not blanket "warehouse" approval. This seems pretty silly to me.. It is not silly if you believe your self to be required by law to keep track of every instance. >From my own experience, it seems to me that DES per se is not excluded from >export. It just depends on how you use it. DES is not excluded from export. However, it must be licensed. It is easy to get a license for DES in hardware. It is easy to get a license for a one-way implementation of DES in software. It may be possible to get a license to export a reversible version of the DES in software provided that it is so embedded in an application that it cannot be used to encrypt an arbitrary file or msessage. It is practically impossible to get a license to export a software implementation of a general purpose and revesible verion of DES (or indeed any other algorithm for that matter.) Such implementations have the potential for turning any mini or micro into a crypto engine. This might fill the ether with traffic that cannot be readily recognized, raising the cost of signals intelligence gathering. >What makes DES written here so secret when the one written in Finland >(acc. a recent posting) isn't?????? The issue is not secrecy; it is replicability. Note that hardware implementations cannot be easily copied or modified. If you can keep track of the incidents of hardware, but would have more difficulty in keeping track of copies of software, then you might be interested in discouraging software. If the work factor for reading the DES was N, but that of reading a variant is >N then one might be motivated to discourage variants. >We're locking the barn door -- with the horse inside -- but after the >back wall fell down. One does what one can do. This is particularly true if one believes oneself to be mandated by law to do so. These observations are based upon many years of observing this issue. While I have often discussed them in front of officers of the NSA, they have never commented on them. Neither have they ever attempted in any way to influence me. I suspect that the area is classified and that they are unable to confirm or deny. I am not now, have never been, and do not ever expect to be an agent of the NSA. While I am a guest on DOCKMASTER, this message originates on MCI Mail. ____________________________________________________________________ William Hugh Murray 216-861-5000 Fellow, 203-966-4769 Information System Security 203-964-7348 (CELLULAR) ARPA: WHMurray@DOCKMASTER Ernst & Whinney MCI-Mail: 315-8580 2000 National City Center TELEX: 6503158580 Cleveland, Ohio 44114 FAX: 203-966-8612 Compu-Serve: 75126,1722 INET: WH.MURRAY/EWINET.USA 21 Locust Avenue, Suite 2D DASnet: [DCM1WM]WMURRAY New Canaan, Connecticut 06840 PRODIGY: DXBM57A -------------------------------------------------------------------- From: gwyn@brl.mil 12-JUN-1989 1:59:37 To: security@rutgers.edu Subj: [298] Re: password security >But what if the new version of crypt is not public ... ? One of the first rules of cryptography is to assume that the "opposition" knows all about the general system and is deprived only of the specific keys used for encryption. Experience has shown this to be a good approximation to reality. From: Fred Blonder 12-JUN-1989 2:24:12 To: cme@cloud9.stratus.com (Carl Ellison) Subj: [488] Re: password security Cc: linus!misc-security@ursa-major.spdcc.com You don't have to erase old encrypted passwords when you change algorithms -- just be prepared to accept either, for a while -- Or just silently store the new encryption. In fact, changing the encryption algorithm on a regular basis, combined with accepting either the current or previous encryptions, would be one way of implementing password aging, assuming you really want to do that. ---- Fred Blonder David Taylor Research Center (202) 227-1428 From: gregm@csd4.milw.wisc.edu (Greg Mumm) 12-JUN-1989 2:35:07 To: misc-security@uunet.uu.net Subj: [597] Tracing license numbers I have noticed that reporters and local security officials have the ability to trace auto license plates. Does anyone know how this is done? Seems unlikely that they call up the local police department and ask because anyone could do that! What is the probability that a common citizen could find out the address of the person who cuts us off on the freeway via his license number and then proceed to visit him (or her) in person? :-) Any suggestions? Internet: gregm@csd4.milw.wisc.edu / arpa!gregm@csd4.milw.wisc.edu Uucp: uwvax!uwmcsd1!uwmcsd4!gregm Csnet: gregm%uwmcsd4@uwm Greg Mumm From: Mr. Stanley Cup 12-JUN-1989 22:03:04 To: @uxv.larc.nasa.gov:security@pyrite.rutgers.edu Subj: [798] password security > You don't have to erase old encrypted passwords when you change > algorithms -- just be prepared to accept either, for a while -- How about having both algorithms available for a "real short" time and do this with them: if (strcmp(new_crypt(reply ,salt),pass) == 0) { /* all is ok, let 'em in */ } else if (strcmp(crypt(reply, salt), pass) == 0) { new_version_pass = new_crypt(reply,salt); /* update the passwd file */ /* let 'em in */ } else { /* password was no good, do whatever */ } After all of your users have logged in at least once, you then have all of their passwords converted to the new algorithm without ever knowing what their password is/was and the user will not know that anything was done to the encryption algorithm for logging in. -=>gretzky<=- .mitch From: zeleznik@cs.utah.edu (Mike Zeleznik) 12-JUN-1989 22:17:54 To: security@pyrite.rutgers.edu Subj: [1198] Re: password security Assuming you could keep the binary secure, isn't there always the old argument that you should not base the security of a crypto system on the secrecy of the algorithm, in general? "GOOD" ciphers are hard to design; the average person doesn't just come up with a new one overnight. Once you figure yours has sufficiently leaked out, you'll have to design another one; EACH time. The NSA seems willing to do this (with the new crypto systems), but I would think the algorithm secrecy exists more as an added nuisance than a requirement. They must figure it can't stay secret for very long. What about sticking with the current crypt, but just change the constant. Now you only have to keep a single number secret, and you can afford to change it very often. Further, using the scheme mentioned earlier, the login could recognize both the old and new crypt constant. Couldn't it then simply generate the new crypt'd password when it needs to (or is this too dangerous?)? Mike Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617 From: John Lekashman 14-JUN-1989 0:06:44 To: ron@ron.rutgers.edu Subj: [453] System Security Cc: misc-security@rutgers.edu UNICOS, at least as I saw it two years ago, had no pretense at security. Things are getting better. They now very quickly get bug repairs in, at least in the networking area. In fact, CRI is the fastest vendor we have at applying and releasing discovered security bug repairs. (Except vaxes running BSD, but thats a special case.) So, if you find something, tell them. If its real, and gets back to Minnesota, it gets fixed. john From: _David C. Kovar 14-JUN-1989 0:34:23 To: security@rutgers.edu Subj: [619] Kuang >You might check out Bob Baldwin's stuff (MIT) for rule-based analysis of >UNIX system security. He had a paper in CompCon Spring 87. This sounds like a program called 'kuang' that I've been looking for, on and off, since a network security conference in Boston a few months back. If anyone knows where one can aquire a copy of it I would be most appreciative. -David C. Kovar Technical Consultant ARPA: kovar@husc4.harvard.edu Office of Information Technology BITNET: corwin@harvarda.bitnet Harvard University MacNET: DKovar Ma Bell: 617-495-5947 "It is easier to get forgiveness than permission." From: svh@xait.xerox.com (Susan Hammond) 14-JUN-1989 0:44:18 To: misc-security@linus.mitre.org Subj: [929] Re: Security Digest There are cheap low-tech ways to make an envelope really tamper-resistant-- or to make tampering obvious. Easiest is to enclose the item in question in aluminum foil before you put it into the envelope. Also, you can enclose the whole envelope in two clear sheets of contact paper. For a #10 envelope, cut two sheets about 4" by 10", peel the backing off, place the envelope on one, cover with the other, and leaving about 1/2 to 1" of contact paper around the edges of the envelope, trim the contact paper edges to be even to make it difficult to get a grip on a single sheet. If someone tries to remove it it is pretty obvious. Putting a signature on the envelope (as suggested in an earlier posting?) helps you detect an attempt to substitue a new envelope for the damaged one. -- ------------------------------------------------------------------ Susan Hammond/CCA svh@XAIT.Xerox.COM {decvax,linus,mirror}!xait!svh From: mrc@tomobiki_cho.cac.washington.edu (Mark Crispin) 14-JUN-1989 7:14:31 To: misc-security@ames.arc.nasa.gov Subj: [727] Re: Tracing license numbers Auto registration and driver's license information is public information, available to anyone. All you have to do is go to the local licensing agency for your state, plunk down a few dollars, and you'll receive a printout. A few states, such as California, will make you give some reason for asking for the information, and will notify that person that so-and-so looked up your record. However, they don't verify the reason or so-and-so's address, etc. Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2020 mrc@CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil / (206) 842-2385 [Moderator tack-on: Thanks also to the *numerous* others who have so far responded with nearly identical information... _H*] From: cep@apple.com (Christopher Pettus) 14-JUN-1989 7:21:41 To: misc-security@goofy.apple.com Subj: [916] Re: Tracing license numbers In California, at least, automobile registration records are public information. You just go down to the local DMV, fill out a form (stating why you want the information), pay an exceptionally nominal fee that depends on how much information you gave them to do the search, and they send you the registration information. They also let the registered owner know that you did the request, however; I suppose one could use an assumed name (which, I'm quite sure, would be illegal). -- Christopher Pettus | "Ganesha Said: 'Done! The very Network Systems Development | day I was born I made my first Apple Computer, Inc. | mistake, and by that path have cep@apple.com {nsc, sun}!apple!cep | I sought wisdom ever since.'" AppleLink: PETTUS.C | - The Mahabharata (408) 974-0004 | I: A Mine of Jewels and Gems From: ddefend@mcdurb.Urbana.Gould.COM 20-JUN-1989 9:38:44 To: misc-security@uxc.cso.uiuc.edu Subj: [305] auto-call-back modems I'm looking for a modem which is capable of dial-back and is advertised as being somewhat secure. I would appreciate hearing from anyone who has experience with any modem of this type. ----- Dan Defend Motorola Microcomputer Division ARPA: ddefend@urbana.mcd.mot.com UUCP: uunet!uiucdcs!mcdurb!ddefend From: spaf@cs.purdue.edu (Gene Spafford) 20-JUN-1989 10:04:24 To: misc-security@gatech.edu Subj: [487] Need list of names For purposes of checking for weak passwords, I'de like to obtain a list of common names (Al, Fred, George... Alice, Kathy, Susan...) Does anybody have such a list online they'd be willing to share with me? Please e-mail -- don't post. Thanks in advance! -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf From: faigin@aerospace.aero.org 20-JUN-1989 10:13:58 To: security@rutgers.edu Subj: [748] Looking for Conferences or Seminars on Security Someone in our company asked me for information on conferences or seminars that might provide somebody with background on DoD regulations and requirements for computer security, including regulations about TEMPEST. As I am more involved with multi-level computer security (as opposed to the DoD side of things), I though I might toss out the request. Does anyone know of conferences or seminars which might fit the bill? Daniel Work :The Aerospace Corp M8/055 * POB 92957 * LA, CA 90009-2957 * 213/336-3149 Home :8333 Columbus Avenue #17 * Sepulveda CA 91343 * 818/892-8555 Email:faigin@aerospace.aero.org (or) Faigin@dockmaster.ncsc.mil Voicemail: 213/336-5454 Box#3149 * "Take what you like, and leave the rest" From: Reality is not an Industry Standard 20-JUN-1989 20:36:03 To: security@marist Subj: [506] Envelopes A site I worked at used tyvek (tm?) envelopes and sealed them with a few drops of an epoxy. It was very difficult to spray them with "see- through" stuff (I prefer DEC tape unit cleaning fluid) and the epoxy drops ripped off fibers of they were forced. I prefer to leave the pager or phone number of two people who know system access passwords since a problem and security breach are known in real-time. Unfortunately this is not always possible. J. Peterson/Sys Eng LIU/South PETERSON@LIUVAX.BITNET From: peter%ficc@uunet.uu.net (Peter da Silva) 20-JUN-1989 20:49:25 To: misc-security@uunet.uu.net Subj: [1009] Re: GNU, security, and RMS > No security on the computer is similar to allowing anyone to come into > your office and look at anything they please, and also to allow them to > change anything they please. I doubt if many people would like this. I think you have this backwards. In no place I have worked has there been any security protecting the contents of people's offices from such intrusion, at least below management levels. In school, however, personal security is taken much more seriously. Every TA and advisor has a lock on their door, lockers for students are available in most buildings, etc... Security in computer systems at the typical commercial/industry site is mainly to (1) keep intruders out, and (2) keep people from accidentally damaging each others files. And both of these are useful features. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. From: guy@ksr.com 21-JUN-1989 0:06:29 To: security@rutgers.edu Subj: [311] Re: High-Tech Knife Well, I once had a pair of scissors confiscated by airline security before they would let me board a low-risk, Memphis-to-Boston flight. It sounds like you just happened to encounter a fairly sensible airline security character; they're not all like that. -- Guy Hillyer ksr!guy@harvard.harvard.edu From: rjg@sialis.mn.org (Robert J. Granvin) 21-JUN-1989 0:34:47 To: misc-security@uunet.uu.net Subj: [1354] Re: passwords >We set up three accounts, with names other than "root", and >uid 0, gid 1. Each account has it's own password, and I >changed the "root" password to something I've already forgotten. However, you have effectively quadrupled your chances for an unauthorized entry, assuming that someone out there knows the other names of the "root users". > mine is "radish". At this point, you've already given one away. Now the world knows that the account "radish" is a root account. One can also assume that "root" still exists. Knowing that "root vegetables" were used to name the other accounts, guesses can be made as to the other account names. Even if they weren't root accounts, it's still a basis to start from... While it may have improved internal security a bit (though I can't actually see how), you've statistically increased your opportunities for a damaging forced entry. Four accounts with four passwords doesn't really do anything to improve your security. Without knowing anything about your internal specifics, I'd personally say you've damaged it... -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ CONFUSED: rjg%sialis.mn.org@shamash.cdc.com __National Information Services__ UUCP: ...uunet!rosevax!sialis!rjg "Exxon: Our gasoline contains no sea water" From: strauss@aerospace.aero.org (Daryll Strauss) 22-JUN-1989 1:39:24 To: misc-security@rutgers.edu Subj: [1038] Re: High-Tech Knife I carry my Swiss Army knife with me all the time, and my usual routine is to hand it to the security gaurd on my way through the metal detector. They usually don't bother to open it, but when they do, they are checking that the blade is less than 3 and 1/2 inches long. I believe that is the current FAA limit. The security people are reasonable, and some of them even have a sense of humour! I got quite a chuckle when I was returning from a trip to Mexico. I was 18 (and looked younger), and I was carrying 2 liters of Tequila. The security gaurd X-ray'd my bag and just laughed. It wasn't his job to stop minors from drinking! The thing that is much more scarey is when I was leaving Pittsburgh on one trip and forgot to remove my knife and the metal detector did NOT go off! That really made me worry. ------------------------------------------------------------------------------- Daryll Strauss f The Aerospace Corp. strauss@aerospace.aero.org n Mail Stop: M1-102 ..!uunet!aero.org!strauss o P.O. Box 92957 From: deh@eng.umd.edu 22-JUN-1989 2:14:47 To: Makey@logicon.arpa Subj: [1325] Re: High-Tech Knife Cc: security@pyrite.rutgers.edu The airline security people are in general pretty reasonable, once they understand what something is, and can make a jungement on letting it through or not. A lot of people flame them for asking a lot of questions about things that are strange to them, but they are just trying to understand what the item is and how it fits into their mission. I used to lug a TI Silent 725 around airports a lot, in the US and internationally, and most of them needed to see the insides of it, since the X-rays did nothing to help my case (the damned things look so much like a bomb when you X-ray them it is not funny). From the viewpoint of the security people this thing was: 1. a large container with lights and switches that could hold enough explosives to blow the whole airport up. [after x-ray] 2. a large container with lights and switches that contains battery looking things, wires, explosive looking things, more wires, etc. [after I take off the inner cover] 3. a large frame with lights, switches, capacitors, wires, a roll of paper, circut cards, more waires, but no sign of anything that might be a problem for their security rules... Of course, technology has progressed, but a Compaq 386 portable does not look a lot better under x-ray, and is a whole lot harder to open... Doug From: GREENY 22-JUN-1989 2:50:54 To: Subj: [1774] re: chronic losing of keys... > this could be good if you are a chronic loser of keys... Well if that is the case, then investigate the Schlage Key-n-Keyless entry deadbolt/doorknob combination. Basically this is a set up that uses an electronic circuit to all you to unlock the deadbolt AND the doorknob locks without a key, or with the key if you have it. When you leave the room/apt/whatever, you press a button, open the door and after closing the door, you turn what is normally the security sheath (rim) around the deadbolt cylinder to the right....this locks the deadbolt, and away you walk. upon returning, you turn the door knob until the led display (just one 1/4" number only) lights up. Then via a combination of left and right turns of the door knob you enter the combination. If you do it right, a "U" shows up in the display, the thing beeps, and you can turn the security sheath of the deadbolt to the left, thereby unlocking the deadbolt. Then you use the door knob normally and enter in. Several problems with this lock are: 1) the whole thing is made of that crappy cheapo metalic ABS plastic and one good whack with a sledgehammer would take it right off the door. (although the deadbolt cylinder, door knob appear to be normal metal) 2) If the batteries die, and you dont have the key, then you have to either call a locksmith to pick it open for you or you have to do it... 3) I dont like the idea of having to push a button when I leave a room this should be automatic... Basically this lock would be good for closets, storerooms, etc,, where what's wants something flashier than a sentex pushbutton lock... Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU GEnie: Greeny From: ijk@cbnewsh.att.com (ihor.j.kinal) 23-JUN-1989 18:15:21 To: misc-security@att.att.com Subj: [450] Re: car locks Wondering thru the local car parts store, I came across a device to make your steering wheel DETACHABLE!!! REMOVE THE WHEEL WHEN YOU LEAVE - That should deter most thieves. Cost - around $80. If I owned a Ferrari, I might get one - but I'd check first that it did not release TOO easily - might be a bit disconcerting if you reach out to adjust the tilt, and instead wind up disconnecting!!! Ihor Kinal cbnewsh!ijk [standard disclaimer applies] From: nanovx!msa3b!kevin@gatech.edu (Kevin P. Kleinfelter) 23-JUN-1989 18:28:44 To: nanovx!misc-security@gatech.edu Subj: [598] Re: Consensus on locks? I don't know about a consensus on pick-proof, but I've been burglarized 3 times in 3 different locations. In 2 cases the door was jimmied; in the 3rd, the door and the jamb were found in toto on my living room rug. I strongly believe in a "jimmy-proof" lock, which usually has several pins on one side, which slide into holes on the other. I've NEVER had a lock picked or credit-carded, but at least 2 were simply crow-barred. (I don't have a jimmy-proof lock now; I've decided "what's the use") -- Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347 gatech!nanovx!msa3b!kevin From: pyron@lvvax1.csc.ti.com (Who remembers 8USER.PAR?) 28-JUN-1989 21:02:03 To: security@pyrite.rutgers.edu, pyron@tilde.csc.ti.com Subj: [637] DECUS Security SIG Is there anyone on this list who took part in any of the sessions at the Spring DECUS (Atlanta) on forming a Security SIG? I haven't heard from anyone since then, and my management wants to know where it is going. Please reply directly to me. Dillon Pyron | The opinions are mine, the facts TI/DSEG Lewisville Computer Services | probably belong to the company. pyron@lvvax1.csc.ti.com | (214)462-5449 | We try, we learn, sometimes we die. | We sit on our butts, learn nothing, | and we still die. From: gwyn@brl.arpa (Doug Gwyn) 29-JUN-1989 1:19:22 To: security@rutgers.edu Subj: [691] Re: DES export laws >Try substituting "tanks" for "DES implementations". There is a fundamental difference. Tanks can obviously be used to assault you, to violate rights of individuals on a large scale. Effective encryption technology could be used to prevent your eavesdropping, to protect the rights of persons communicating. I see no way to claim that NSA or anyone else has a "right" to be able to snoop on other people's conversations. I don't dispute that such snooping can produce useful information, but it is not information to which we are in principle entitled. As much as I love cryptanalysis, I would welcome a world in which people can be sure their communications are secure against snoops. From: cme@cloud9.stratus.com (Carl Ellison) 29-JUN-1989 2:54:52 To: linus!misc-security@ursa-major.spdcc.com Subj: [1738] Re: DES export laws > Should the US therefore be willing to export tanks to anyone who wants them? > Suppose the US manufactured military radios containing very strong encryption > technology. Should we be willing to sell those to anyone who wanted them? Sorry -- this argument doesn't wash. Weapons and weapons systems, like tanks, derive military value from things like the materials with which they're made, the workmanship used, .... Sometimes there's value added in the add-on electronic packages. In all of these cases, posession of the physical object implies military value. Therefore, sale and delivery of the object constitutes increasing the military strength of the recipient. An encryption device has only a trivial value by way of its parts. (eg., there was a sliding alphabet device during WW-II which had particular value because it was made of materials which didn't warp aboard ship in the South Pacific.) The real military value of an encryption device -- that which kills people or saves them from being killed -- is the algorithm itself and devices or algorithms for breaking it. In the case of DES, the algorithm is already known. No one is trying to sell machinery for breaking it. It's possible to buy implementations from overseas so there's no secrecy to protect, either with the algorithm or with how to implement it. So, what does the Government gain by interfering with its export? All I can see being accomplished is the inhibition of a small piece of potential export trade which could have been working against the trade deficit. --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (this is STRICTLY my own opinion) From: G.D.Shaw@DURHAM.AC.UK 29-JUN-1989 3:34:26 To: SECURITY@pyrite.rutgers.edu Subj: [2238] Re: DES Export Laws > Try substituting "tanks" for "DES implementations". This is not a valid analogy. Once you have one copy of a DES algorithm, then it is easy to create as many as you like; the same is not true of military hardware. Therefore, even if your enemy has a given number of tanks, or of guns or whatever, it is still in your interest not to give him any more. With software, he only needs to buy or steal one, so if you are going to try to prevent the DES falling into the 'wrong hands', that security must be complete: 1. If the software is on open sale in the US, then you may as well sell it in Moscow too - at least that way, they might pay for it instead of buying one copy in the US and pirating the rest. There is certainly no point in banning it from NATO or neutral countries. 2. If you really want to stop the Russians getting hold of it, then you need strict regulations in the US as well - but if this was effective you would probably have had to prevent any commercial use of the product and restrict it to government agencies only. 3. Even if you did this, it would only be a matter of time before any hostile government was able to steal a copy; indeed, I would be surprised if the Russians are not capable of writing their own DES code. Fast DES chips are a very different matter: though it can undoubtedly be done, copying chips is not a trivial undertaking. The issues at stake are therefore essentially identical to those governing the sale of CPUs or complete computers. Software and hardware pose very different problems, and just because they both relate to the DES they should not be confused. +----------------------------------------------------------------+ | Graham Shaw, Collingwood College, South Road, Durham, ENGLAND | | JANET : G.D.Shaw @ UK.AC.DUR.MTS | | Internet : G.D.Shaw%MTS.DUR.AC.UK@cunyvm.cuny.edu | | EARN/BITNET : G.D.Shaw%MTS.DUR.AC.UK@UKACRL | +----------------------------------------------------------------+ | "I always said there was something fundamentally wrong with | | the Universe" - Arthur Dent | +----------------------------------------------------------------+ From: cme@cloud9.stratus.com (Carl Ellison) 29-JUN-1989 3:58:45 To: linus!misc-security@ursa-major.spdcc.com Subj: [2367] Re: DES export laws > Now suppose the algorithms of the encryption chips were public knowledge, but > actually implementating them as chips with sufficient speed, reliability, low > power consumption, whatever, was very hard. Does your answer change? I say that in that case, if the implementation was done at the Government's request (eg., as part of a defense contract), then they can legitimately lay claim to rights over that implementation. However, if the implementation was done by a private firm strictly on its own money and for the intention of shipping product overseas, then it's none of the Government's business! This is a free market economy we keep bragging about, right? Let's make it stickier. Suppose the algorithm is not in a chip. It's software on a plain vanilla computer. Let's pretend that it's MY software -- and let's also pretend that I'm the best programmer in the world. Therefore, even though this is just software and anyone could have written it, I happen to be the person who wrote it the best. I want to profit from my ability. I want to sell copies of this superior software. I'm not picky. If the U.S.Government wants to buy some copies, I'll sell them some copies. However, I won't sell them exclusive rights to ths software unless they're willing to pay a VERY high price -- to compensate me for the profit I won't be able to make from other customers. Will they sign an exclusive contract and pay that very high price? (I'll wait while you stop laughing.) Well, no, not exactly. What they'll do is make it illegal for me to sell this software outside the U.S. and although they'll allow me to sell and ship it within the U.S., they won't buy any copies from me for themselves. --- and I repeat -- with encryption algorithms, the quality of the implementation doesn't add to the quality of the secrecy (and therefore the military value), but it might add to the satisfaction of the user and therefore to the financial incentive for me to do a good job in the implementation. Killing that financial incentive has only one logical justification -- to keep me out of the business and therefore keep a near monopoly in the hands of the NSA and select defense contractors. --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course) From: /* Purple Haze */ 29-JUN-1989 22:47:41 To: security@pyrite.rutgers.edu Subj: [274] "not for export" There's been some discussion of software packages labelled "not for export" because they contain DES. Are there any other widely used programs that have this same "not for export" status? I have seen a "not for export" sticker on a box for Turbo Pascal, anyone know why? From: MJB8949@RITVAX.BITNET 29-JUN-1989 23:22:32 To: SECURITY@pyrite.rutgers.edu Subj: [879] SESCOA software request I'm presently researching the market for software designed to interface a personal computer with a SESCOA 3000 alarm receiver. This is for a 'medium-to-large' size college campus which has been using the SESCOA for several years. If anyone could pass on information about companies with such products, or personal experience with various programs 'in the field', your help would be greatly appreciated. Please note that I'd need to receive any info before July 6 (I know it's not that far away), since I will be on the other side of the country after that. E-Mail would probably be the best, then I can try to summarize for everyone else if it seems others are interested. Thanks. Mike Bunnell 716-475-4263 30 Lowenthal Dr., Box 2767 ('till July 6) Rochester, NY 14623 MJB8949@RITVAX From: Mr. James Crooks 29-JUN-1989 23:56:41 To: security@pyrite.rutgers.edu Subj: [2259] re: EXPORT OF THE DES >Such implementations have the potential for turning any mini or micro >into a crypto engine. This might fill the ether with traffic that >cannot be readily recognized, raising the cost of signals >intelligence gathering. Don't lose sight of the fact that DES represents ONLY commercial level crypto. Anybody sending something REALLY important wouldn't use DES anyway (gov't/mil). The fact that it is illegal, won't stop the bad guys from smuggling out almost anything they want. In fact is mostly stops the law abiding citizens of the world from getting the protection they need to run their businesses (or at least getting it from the USA - but then NSA doesn't care about the balance of payments gap). >The issue is not secrecy; it is replicability. ... >If the work factor for reading the DES was N, but that of reading a >variant is >N then one might be motivated to discourage variants. But given the fact that in an open marketplace with published alorithms, one finds that other solutions will be provided sooner or later. If NSA was really smart, they might have written public domain standard code then freely distributed it in object form to cut down on the variants - by all means protect the source code with export controls. >>We're locking the barn door -- with the horse inside -- but after the >>back wall fell down. >One does what one can do. This is particularly true if one believes >oneself to be mandated by law to do so. I agree that the law is there, but SHOULD it be there? I really think it boils down to pig-headedness in the security services. At least the US delegation to the ISO Crypto standards stuff abstained rather than vetoing DES (as NSA and the White House wanted them to, or at least that is what I heard...). At least NSA got smarter with the newer algorithms - and kept them classified. Then they were looking for something a bit better than commercial level protection. James W. Crooks Member, Advanced Technology Application Staff BITNET: JIM@ISS.NUS.AC.SG BIX: jw.crooks DASnet: DW1JW|JCROOKS Compuserve: 72611,162 Envoy 100: jw.crooks Institute of Systems Science, National University of Singapore Heng Mui Keng Terrace, Kent Ridge, Singapore 0511 From: hwchoy@zpovc.enet.dec.com (Life, The Universe and Everything.) 30-JUN-1989 12:08:58 To: DECWRL"".."security@pyrite.rutgers.edu"@zpovc.enet.dec.com Subj: [143] Ethernet Encryption device Can anyone give me information regarding Ethernet Encryption devices, prices, features and contact address/tel/fax would be welcomed. Thanx. From: gwyn@brl.mil 30-JUN-1989 13:11:42 To: security@rutgers.edu Subj: [472] Re: Envelopes >A site I worked at used tyvek (tm?) envelopes and sealed them with a few >drops of an epoxy. This is probably beyond the bounds of reasonable paranoia, but you should be aware that the standard technique for removing a document from a sealed envelope is to insert a slotted rod at the corner, roll the contents onto the rod, and slip it out as a thin tube. Of course it's reinserted by reversing the process. Thus, the corners of the envelope need special attention. From: monster!paul@csc-lons.af.mil 30-JUN-1989 13:43:00 To: security@csc-lons.uucp Subj: [577] [575] Return-path: Date: Tue Jun 20 08:59:24 1989 From: monster!paul@csc-lons.af.mil To: security@csc-lons.uucp I have had experience with Anderson-Jacobson (sp?) 2400 baud security modems. I did several weeks of testing on them and I believe they will fit what you are looking for. I also had hardware problems with one modem and A-J sent a tech over to my location to help test it, and swap out the bad modem on the spot. It was real nice. The modem offers callback and multilevel security. Take a look, you might like it. Paul Fischer paul%monster@csc-lons.csc.com 1-800-234-6668 Bohdan Associates Inc. "Smile! ... It makes people wonder what you're thinking." From: Michael K. Blackstock 30-JUN-1989 14:39:43 To: Subj: [556] Re: auto-call-back modems Here is an ad taken from "computer shopper" Mar. 89. "FINAL CLOSEOUT/SRICE SLASHED! Lockheed-Getex modems now priced below our cost! ..300/1200-baud ..Choice of security levels including selective and nonselective callback ..Non-hayes compatible and any computer...that has industry standard RS-232C port " can use it "... NOW $29 + $4 S/H Item # H-4206-7344-195 COMB 1-800-328-0609 I have got two of them. I am using one of them right now, with a Lear Siegler Terminal. The other one is for my PC. BITNET: ELTRUT@MSSTATE -Michael From: tsibouris@vms.macc.wisc.edu (GEORGE TSIBOURIS) 30-JUN-1989 15:24:23 To: misc-security@uunet.uu.net Subj: [693] RANDOM vs DETERMINISTIC systems I am not certain that this is the right forum but here it goes anyways. Does anyone know to distinguish a system that spits out a sequence of "truly" random numbers (neutron decay of some radioactive material) from a system that has a complex (non-linear) but deterministic structure? A similar question is: how can you distinguish a good random number generator from a great one? What tests are used? I am rather new to this area but I am familiar with correlation integrals and the correlation dimension. Any references on the above topic would be greatly appreciated. Thank you, George Tsibouris tsibouris@vms.macc.wisc.edu (Internet) tsibouris@wiscmacc (Bitnet) From: hollombe@ttidca.tti.com (The Polymath) 30-JUN-1989 16:08:57 To: misc-security@sdcsvax.ucsd.edu Subj: [2449] Re: Kevin Mitnick }I personally feel the man is just a criminal, like the guy that robs a 7/11, }no better but certainly not any worse. A number of people have been killed in 7/11 robberies. How bad is that? }... Sure he did things like access and perhaps even altered }Police Dept. criminal records, credit records at TRW Corp, and Pacific }Telephone, disconnecting phones of people he didn't like etc. }But what is not understood by most people outside of the hack/phreak world is }that these things are VERY EASY TO DO AND ARE DONE ALL THE TIME. Therefore Mitnick's guilt is less? More appropriately, we should throw the book at him and go after similar criminals/sociopaths just as aggressively. }1.) He will not be treated fairly. He will be judged as a much greater threat }to society then others that have committed simular crimes. That's his lawyer's problem. }2.) He will become some kind of folk hero. A Jesse James with a keyboard. Not if he's found guilty and harshly sentenced. There's little glory in 20 years behind bars with no access to his favorite toys. }I'm not defending him or the things he has done in any sense. All I'm saying }is lets be fair. Judge the man by the facts, not the headlines. Let's trust the jury to do just that. Despite the image of a chaotic court system, created by the same media hype of a few odd cases, juries, by and large, have been shown to be fairly efficient at fact finding and interpretation and ignoring media bull. BTW, my impression from the news media is that Mitnick isn't a super hacker, or even much of a hacker, at all. He's more a classic, textbook sociopath. Most of the times he gained access to systems he did so not with computer expertise, but by conning the owners into giving him the needed passwords. That ability to inspire trust, combined with the conscienceless willingness to abuse it, is a classic symptom of sociopathy. It has nothing to do with computer expertise. If he didn't know anything about computers Mitnick would probably be an embezzler or a used car salescritter. I suspect society will be much better off with him isolated and neutralized (and that should keep me off the jury, at least). -- 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 From: "Daniel L. Laser" 30-JUN-1989 21:26:34 To: security@tcsvm Subj: [597] Requesting Information on Security Policies We are in the process of trying to formulate an INFORMATION SECURITY POLICY for our campus. This policy as we envision it would be campus wide and would serve as the foundation for other more specific information related security policies concerning electonic data systems, reports, departmental p.c. systems, etc. I would appreciate samples of the information security policies that you are using on your campuses. Thanks, ==========================>>> Daniel L. Laser - Associate Director ==========================>>> Trinity University Computing Center Acknowledge-To: From: oster@dewey.soe.berkeley.edu (David Phillip Oster) 30-JUN-1989 22:04:50 To: misc-security@ucbvax.berkeley.edu Subj: [696] IBM Mainframe rs232 call-back software=Defender interface? I'm looking for information about a software package named "Defender" that runs on IBM mainframes. It provides 3270 emulation over rs232 lines connected to inexpensive modems. It uses a hang up and call-back approach. My questions: What kind of terminal does it expect to see at the remote end? Does the 3270 emulation require a terminal that accepts ANSI control commands or something wierder? Does it provide any file transfer protocols, and if so, which ones? --- David Phillip Oster --"Unix Version 7 was an improvement not Arpa: oster@dewey.soe.berkeley.edu --only over its predeccessors, but also its Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --successors." From: nevin1@cbnewsc.att.com (nevin.j.liber) 30-JUN-1989 22:37:36 To: misc-security@att.att.com Subj: [1437] Re: Request: Computer Security [from Doron Zifrony in comp.misc. He does not get misc.security; please respond directly to Doron (and not ME) directly via email.] Hello people! I hope this is the right newsgroup to post it. I am interested in starting a PhD in computer science or a related area. I am interested in the field of "computer security". Unfortunately, I have no knowledge of universities anywhere around the globe, which include people researching in this area, which may advice me in my thesis. I would welcome any information which will allow me to get in touch with souch people for further discussion. I prefer an english-speaking country, or an hebrew-speaking country, as I do not master any other language (I stutter a bit in French, but I do not master it). However, I'll be willing to learn other languages if the need arrises. Please E-mail me responses, as I do not check this newsgroup often. Thanks -- Doron Zifrony E-mail: BITNET: zifrony@taurus.bitnet Msc. Student INTERNET: zifrony@Math.Tau.Ac.IL Dept. of CS ARPA: zifrony%taurus.bitnet@cunyvm.cuny.edu Tel Aviv Univ. UUCP: ...!uunet!mcvax!humus!taurus!zifrony Israel CSNET: zifrony%taurus.bitnet%cunyvm.cuny.edu@ csnet-relay -- Disclaimer: I DON'T represent Tel Aviv University. The opinions hereby expressed are solely my own. From: Pat Ratz 4-JUL-1989 22:55:37 To: security@OHSTVMA Subj: [588] MIS Training Inst. Conference I'm new to this list. Has anyone attended MIS Training Institute's conference on Control, Audit, and Security of IBM Systems? I sent for some info on it and I'd like to know if it would be worth attending. Also any comparison info relative to Computer Security Institute's conference. We are in the midst of installing Top Secret on our MVS system on an IBM 3081D. We have lots of other hardware and software here at OSU including VM, DEC, UNIX. Its all networked together using TCP/IP. I would also be interested in hearing from any other university people who using Top Secret. From: Victoria Landgraf 4-JUL-1989 23:25:15 To: SECURITY@pyrite.rutgers.edu Subj: [849] airport metal detectors Usually, when going through airport security, I toss my metal pocket items (keys, lighter, swiss, often another small knife) into the basket that goes around the metal detector. However, on the occasions I have not done this, the metal detector has still not gone off. Most of them don't seem to be incredibly sensitive, except to uncovered items ("Why don't you try walking through again with your hand over your belt buckle? [No beep] OK, go ahead.") No security guard has ever opened my knife to check the blade length. I think they're a lot more worried about guns and bombs, really -- and even though the stuff in my pockets can feel like a lot, it probably doesn't contain as much metal as even a small pistol would... and none of it looks particularly explosive. Victoria From: kiravuo@kampi.hut.fi (Timo Kiravuo) 6-JUL-1989 3:31:09 To: misc-security@cwi.nl Subj: [1897] Re: Consensus on locks? >A sort of related question is: I have seen locks with automatic "dead bolts" > - meaning, locks in which opening the door with a key from the outside >(not in the handle) pulls back a full-sized spring loaded bolt, which closes >when the door is closed. I'm not sure I understood this right, but in Finland we have ABLOY locks with a keyhole on the outside and a small flat knob (not the round American type) on the outside. Towards the frame there is a small triangular piece that is pressed in by the frame and a larger (1 x 3 x 1,5 cm) rectangular piece that locks the door. You open the door from outside by twisting the key 180 degrees and pulling and lock it by pushing the door close. When the larger piece is out, you can pull it back in by twisting the knob or the key, but not by pushing it. There are some variations of the theme, but basically you can not open a lock of this type in the traditional "movie style", with a credit card or something like that. In Finland ABLOY has a major share of the lock market, and they are considered to be most secure. They are not completely secure, apparently somebody has found a way to open one. There was something about it in the papers some time ago. In the door of my apartment I have two locks. For normal use I have an ABLOY so that I can just push the door shut when I leave. When I am away for a longer time I use a German Zeiss Icon security lock that has to be shut with a key. This is a rather common practice in Finland. One thing that I always have wonderer in the states is the practice of having _round_ knobs on doors. If the lock is tight, they are really awful to turn. In Finlad we have usually decent handles, that you can turn. Much more easier. -- Timo Kiravuo Helsinki University of Technology, Computing Center kiravuo@hut.fi kiravuo@fingate.bitnet sorvi::kiravuo work: 90-451 4328 home: 90-676 076 From: Reality is not an Industry Standard 6-JUL-1989 7:47:43 To: security@marist Subj: [312] airport security In the US I often go through the detectors with my pager and I have never had the units go off. The Guard at O'hare wanted to look at it AFTER I went through once. The units at glascow [Scotland] were set off by dog tags in my pocket. Makes you wonder what you realy could get past with. PETERSON@LIUVAX, NY From: Elie Harel 11-JUL-1989 2:39:34 To: security@pyrite.rutgers.edu Subj: [504] Thumb scanning devices Does anyone have experience with door locking devices that incorporate thumb scanning techniques instead of magnetic cards? It would be nice to eliminate the need for carrying magnetic cards for secure areas but in the same time maintain or improve the security level that these techniques provide. Any information on issues such as vendors, costs, characteristics, technical problems, administrative problems, security levels, and especially your own experience will be greatly appreciated. Thanks. From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 11-JUL-1989 3:45:16 To: security@rutgers.edu Subj: [690] locks The very best kind of lock you can get is a Warehouse lock. I'm sure you've seen these before --- the one example in a movie I can think of was in the movie FX (the stuntman had one on his front door). Basically, it's a cylinder in the middle of the door, which turns a disc, which throws two deadbolts, one on either side of the door. Some variants throw four deadbolts, one up and one down. You can't jimmy this, obviously. On the other hand, I have friends who had very good burglar alarms on their house. Doors, windows. Didn't matter. The theives came in through the walls. Like, with chain saws. (They were after the art and Jewelry; looked like an inside job.) -simson From: janw@janus.UUCP (Jan Wortelboer) 11-JUL-1989 5:04:03 To: misc-security@hp4nl.nluug.nl Subj: [569] Multipurpose Security System (for) Users Is there anybody who knows about a General Purpuse Security System, for a computer system(UNIX) with inventive Users? I am using Convergent's with informix and would like to make the system secure, (as far as it goes). If there is, i would like to know about it. Thanks for any help. Jan -- Usenet: janw@janus.fwi.uva.nl, Uucp: {uunet,...}!hp4nl!janus!janw Jan Wortelboer,Tel.Prive 020-913169,TOPDATA / Compact Informaticadiensten nv Kantoorgebouw "Oosterpoort" Pegasusweg 18 3067 KX Rotterdam Tel: {+31|0}10-4552644 Telefax {+31|0}10-4554682 Telex: 26727 .. NL From: 11-JUL-1989 5:27:04 To: security@pyrite.rutgers.edu Subj: [572] [570] Return-path: Date: Thu, 29 Jun 89 09:28 MDT From: To: security@pyrite.rutgers.edu After several years of stagnation, we have again become interested in hiring a person in charge of security. Since we will only be hiring one person, this person will (gasp) have to handle ALL aspects of security at all levels, from micros to mainframes. My question is not with how to accomplish this, but one of where to place such a person organizationally. I've read the textbooks, but I'd like to hear from any of you who have a person in charge of security - to whom does he/she report and what are the goods and bads of your reporting line of authority? Thanks. From: "MOG::REX"@isdmnl.menlo.usgs.gov (Rex Sanders) 11-JUL-1989 6:36:23 To: security@pyrite.rutgers.edu Subj: [1207] Re: passwords >Knowing that "root vegetables" were used to name >the other accounts, guesses can be made as to the other account names. Note the explanation in the original article for choosing "root vegetable" names - this was done to let insiders know when root users were logged in. >While it may have improved internal security a bit (though I can't >actually see how), you've statistically increased your opportunities >for a damaging forced entry. Four accounts with four passwords >doesn't really do anything to improve your security. I agree that we have increased the chances for outside entry into our system. However, most of the "experts" I've heard from or read about state the biggest danger is from inside jobs. We have improved internal security by providing more accountability for actions taken with root permissions e.g. "Who modified that system file?". Also, as stated in the original article, the "one account, one-person-knows-password" rule was passed down from Higher Authorities. Perhaps this last point illustrates an old idea - set up a rule (law), and someone will comply with the letter of the rule while violating the objective (spirit). -- Rex Sanders, rex@isdmnl.menlo.usgs.gov From: swartz@eniac.seas.upenn.edu (Peter M Swartz) 11-JUL-1989 7:31:41 To: misc-security@rutgers.edu Subj: [402] "copy proof paper" - does such a thing exist? At one time, I recall seeing paper that would not make legible copies. I think the paper was a special shade of red; any writing on this paper would not show up when copied. Essentially the copy would be a sheet of black paper. Does this stuff exist? If so who makes it. Any other suggestions on preventing copies from being made on a copy machine? thanks peter (swartz@eniac.seas.upenn.edu) From: gwyn@brl.mil 11-JUL-1989 8:01:08 To: security@rutgers.edu Subj: [377] Re: RANDOM vs DETERMINISTIC systems >A similar question is: how can you distinguish a good random >number generator from a great one? What tests are used? A good start on this would be to read Donald Knuth's "The Art of Computer Programming -- Volume 2: Seminumerical Algorithms", which explains many of the standard statistical tests for "randomness" as well as the tricky question of how to define "random". From: ghoti 11-JUL-1989 8:32:29 To: security@pyrite.rutgers.edu Subj: [1318] consensus on locks Folks: A consensus on locks? Doubt it. The locksmith I deal with likes Medecos best. He also deals in Abloy, but not Sargeant KESO or any other high security locks. He claimed that for virtually all applications, Medeco was superior to Abloy. Abloy is harder to pick. However, according to this one locksmith, Abloy locks don't wear well. If they are not treated gently, they will begin to jam. Have people discovered this to be true? (Note: Abloy is more expensive than Medeco, but Abloy keys cannot be duplicated at the shop as a standard Medeco can. The "Platinum," or biaxial, Medecos are in the same boat as the Abloy.) As an earlier posting noted, a great cylinder isn't worth much if attached to a bad lock. And a great lock won't help if attached to a cheap frame. Our company is installing a Medeco D10 (7.5 lbs. of nasty looking metal) drop bolt onto a steel door inside a steel frame held up by steel reinforced studs. That should keep all but a few determined hacks out. ghoti ----------------------------------------------------------------------------- Kevin M. Rainier * -- * krainier@eagle.wesleyan.edu Geek | | Pride krainier@eagle.wesleyan.bitnet * -- * From: sequent!edb@cse.ogc.edu (Edward Bunch) 11-JUL-1989 9:01:29 To: security@pyrite.rutgers.edu Subj: [662] Home Security/Control Systems. I am interested in finding out more about Home Security/Control Systems. You know, the ones that not only tell you if someone is breaking in but control lights while your out and make coffee for you in the morning. Please Email me direct. Thanks, ----------- Edward A. Bunch | |/ | UUCP: {sun,fai,uunet}! Sequent Computer Systems, Inc. | /|/ | sequent!edb Network Manager | /| | DOMAIN: not yet ;-) | | ----------- From: Where Y'at??? <8840488@wwu.edu> 11-JUL-1989 9:47:05 To: security@pyrite.rutgers.edu Subj: [2167] [2165] Return-path: Date: Mon, 26 Jun 89 10:44 PST From: Where Y'at??? <8840488@wwu.edu> To: security@pyrite.rutgers.edu *I don't know about a consensus on pick-proof, but I've been burglarized *3 times in 3 different locations. In 2 cases the door was jimmied; in the *3rd, the door and the jamb were found in toto on my living room rug. Kevin - Speaking as one who has been in the fields of both security and law enforcement, I would say that you are one individual in sore need of a strange electrical device called a burglar alarm. Most models work with *any* type of lock on the door. I'm not trying to be sarcastic, but I used to live in the "big city" (New Orleans, to be exact), and I know what it's like to be a crime victim. The only advice I have for you is to "up the ante" - try new security methods out, like an alarm. Here are some other things that may work. If you don't have any small children around, get a dog. Pit bulls are still the rage, but I prefer rottweilers myself. Also, check your local laws to see if there are any homemade "passive" booby traps you can lay out to surprise the unexpected visitor. Many of these will deter them from returning. Of course, no method of security will work unless you use it properly. The last time my house in N.O. was burglarized was in broad daylight, while I was in court. I came home to find that the alarm had not been set, and that the kitchen window had been left open. My ex-wife left it that way because she "thought that no one could get through that 'tiny' opening". They got away with a TV, stereo, and my service revolver. If the city still gets to be too much for you, look around for a small town nearby where you feel comfortable and from which you can commute, and by all means, move! I now live in a small town in the northwest. My door is unlocked at night, and I usually leave my keys in the car when I get home. I've been there three years, and have yet to be mugged, burglarized, or threatened in any manner. Above all, DON'T GIVE UP! As they say, no one can walk over you without your permission. In the meantime, pray for peace of mind - you need some. Paul Simmons 8840488%wwu.edu@RELAY.CS.NET "These are my own opinions. I am not affiliated with anyone who would have me." From: Frank Simon <151133@DOLUNI1.BITNET> 11-JUL-1989 10:17:58 To: security@pyrite.rutgers.edu Subj: [2879] Re: ISDN Hello Simson ! >I am doing an article on ISDN for The Boston Globe. The artice would like >to write about all of the problems with ISDN, all of the advantages, what >people's experience have been (both positive and negative), and where things >are going. Ok. First: Excuse mz bad english, but i have problems with natural languages like English and Spanish. Could we speak in Assembler or C ? :-) Let's start: My name is Frank Simon (called Terra), student of computer science in Oldenburg(West Germany), i am running a BBS (Chaos Mailbox System) on Bitnet (107633@DOLUNI1), and i am one of the seven ppl who build the leading/council/presidium (oh i don't know the word ...) of the Chaos Computer Club in Hamburg (West-Germany). The german PPT (Deutsche Bundespost (short: DBP)) start experimence with ISDN for several years. Now it will install in germany in the next years. We have thought about the possibilites and the danger of ISDN. Our opinion is: We are against ISDN in this form in westgermany, because 1) the DBP will save all communication datas (who called whom, on which service (phone,etc), how long , how much cost it,etc) for 80 days in 12 central computer centers in germany. We and the german Data Security People (i don't know the right word ... in germany we have for every country and for the state Data Security People. They are called by state to work.) are against the Saving of these (most don't need the DBP for there work) because it's against the Data Security Law. 2) The DBP will integrate all Services until 1992 in one Network - IBFN - that means ... TV, Radio , Phoning, Computernetworks,a.s.o. are on ONE Network. Much Security Problem must be solut by the DBP for this, in exampe the Central Computer System who will manage all this functions. We don't ave a good opinion of the DBP. They don't have the Data Security and System Security at first place in there concepts. 3) The function of ISDN give an goverment now and in future the possiblity the control there citizens. The government (or the secret services) can check every citizen, who contact he, what does he read in information retrieval systems, which channel he look in TV,and so on. The Solution is a complete Communication Picture on group of citizens or especialy one citizen. *horrible_english_i_know* :-) Feel free to ask for details of our opinio or what does words of my mail means. greets Terra ----------------------------------------------------------------- | Name: Frank Simon Bitnet: 151133@DOLUNI1 | | Nickname: Terra UUCP: simon@uniol%unido | | Position: Oldenburg,Westgermany Voice: 0441/592607 | | WYGWYH - What you get , is what you hack | ----------------------------------------------------------------- From: "Jerry Leichter _ LEICHTER_JERRY@CS.YALE.EDU" 11-JUL-1989 10:54:49 To: security@rutgers.edu Subj: [7840] DES export laws (The long turn-around for messages on the security list make this response a pain to write. I got several personal messages from people shortly after my message appeared, and got involved in a couple of conversations. Coming back to all this two weeks later, repeating many of the same things, is a bit of a bother. Oh, well.) [Moderator injection: Sorry, Jerry. I do my best with the backlog *and* all the other real-life things I keep track of too. But have you considered that you're feeling the need to repeat yourself because some readers didn't bother to absorb your original points in the first place? Does that necessarily imply that restatement will change that? Further, I believe you're giving the readership less credit than they deserve for being able to restore the context of a discussion in their own minds. If, of course, they were interested in the first place. If they couldn't care less, they've probably already skipped this entire msg. There's a large, diverse audience out there... _H*] In the interests of keeping things to a reasonable length, I'm going to summarize the comments I'm responding to. If my summaries lose what the writers were trying to get across, my apologies. I'm sure they will speak for themselves again.... Carl Ellison raises two distinct points: a) The value of something like a tank is in the material, workman- ship, and so on. Preventing physical export of such objects "keeps the value at home." The value of an encryption algo- rithm is in the algorithm itself, and possibly in means of breaking it; an implementation is a minor gloss. b) If he invents the algorithm, he claims that he has the right to sell it as he wishes - the government doesn't own it, and should have no say in what he chooses to do with it. While he discusses the invention of an algorithm, presumably he intends the same argument to apply to a privately-developed implementation of a public algorithm. I contest both points. Point (a), a point several of my correspondents raised as well, reveals a certain naivete concerning the ease or difficulty of implementing software, and about what constitutes value in software. The fact of the matter is, people are willing to pay many thousands of dollars for well-written, efficient software. They are willing to do this because it is NOT easy to produce such software. Yes, it is quite true that having an efficient algorithm provides no addi- tional security, in the sense that the output of the encryption is as secure if it was done in a millisecond as if it was done in 10 seconds. But that's not the point: Military (or commercial) usefulness of an encryption algo- rithm requires a fairly high level of performance. To pick current "bad boys", how many people in all of Libya or Iran do you think there are who can implement a useful version of DES? Remember, too, that I'm NOT arguing that the particular restrictions the US has chosen to impose are "right". All I'm arguing is that the PRINCIPLE that it may be reasonable to restrict distribution of software makes perfect sense, even software for algorithms that are public. The fact that one can get DES implementations from elsewhere is exactly equivalent to the fact that one can get tanks from elsewhere: It means that our restrictions may not end up being very effective, but it doesn't mean that we should necessarily eliminate them. There has been much written about how we are entering the "information age", where value inheres in information, rather than in goods alone. Here we have a prime example! At one time, it was easy to distinguish "military" from "civilian" items. In today's world, things are not so simple. High-technology "goods" (which in- cludes information and software) are usually capable of "dual use". Is it a pharmaceutical plant or a poison gas plant? The machinery is identical in both cases.... BTW, tanks these days contain a LOT of software in things like targetting systems. The underlying algorithms are pretty "public" - basic physics - but the software itself is neither straightforward nor public. You can't buy that software on the open market either - even in the US.... As for (b): Under US law, there are exactly two classes of things which are "born classified": Information about nuclear weapons, and information about cryptography. The US legal system has chosen to say that you do NOT have a property right for this kind of information - it is considered too important to national security. You are, of course, free to disagree. So far, the courts have backed the government position, though the issue is pretty messy. In any case, on this issue you don't even need to go nearly that far. If I independently develop the necessary technology for making nerve gas, without any reference to government work on the matter, I STILL can't sell the stuff. I can't sell drugs I invent without a license. I can't sell guns. I can't even sell cars without meeting all sorts of government regulations first. If you want to argue that the government should stay entirely out of trade, you can certainly find some respectable economists and philosophers on your side. But the fact of the matter is that the US does not today have, and never has had, complete "freedom of trade", whether national or internation- ally. Trying to use this non-existent freedom to justify a particular posi- tion is is pointless. Graham Shaw argues that there is no point restricting export of DES implemen- tations because the Russians will have little trouble getting hold of an implementation in the domestic market if they really want it. Again, this argument simply proves that it's difficult to enforce the restrictions; it doesn't say that attempting to maintain them is wrong in principle. Again, it's quite clear that the NSA understands this: First off, DES was deliber- ately made hard to implement efficiently in software (that's the only con- ceivable purpose for the initial and final permutations - they add no strength to the algorithm); second, they saw to it that only a hardware implementation could be certified; and finally for the "next generation" of encryption algorithms they intend to provide ONLY tamper-proof hardware, with secret algorithms. Doug Gwyn distinguishes tanks from DES implementations by pointing out - with images of Tienamen square clearly in front of him - that tanks, unlike cryp- tographic technology, can be used to violate individual rights on a large scale. This is an interesting distinction, but let's see where it goes. If the Chinese democracy demonstrators had also had tanks, they might have been able to defend themselves. Absurd position? A similar position is taken by the NRA concerning gun regulation: They love to point out that the first thing a dictatorship does is seize all the weapons in the people's hands. If people are armed, it's not so easy to violate their rights. Still find the argument silly? Do you think an Afghan would agree with you on that point? Looking at the other side: It's clear from information that makes it into the public eye that much data about future terrorist plans is derived from inter- cepted communication. Does Abu Nidal have a right to secure communications channels? Gwyn's argument that information gained by "snooping", while valu- able, "is not information to which we are in principle entitled", is remini- scent of the line attributed to Stimson that "Gentleman don't read other gen- tlemen's mail". Gentlemen also don't hijack airliners or blow up civilians. I, too, would prefer to live in a world of "gentlemen", but this world isn't like that. The rabbis had a saying: Those who start out by being kind to the cruel, end up being cruel to the kind. -- Jerry From: Susan Bramhall 18-JUL-1989 13:35:59 To: Multiple recipients of list IBM-NETS Subj: [1532] Encryption hardware/software available? Please excuse me if you receive multiple copies of this note. I am sending it to several lists which may have a subscriber who has relevant information. We are interested in providing an encrypting gateway for our campus network. The idea is that users on certain LANs considered secure wish to send data across an unsecured ethernet spine and eventually into another secure LAN or host. We have several ideas for the gateway (based on previous software developed at Yale) but would like to acquire a software or, preferably hardware, encryptor. Ideally, it would be a card with the ability to encrypt/decrypt on its own chip rather than taking up workstation CPU cycles. We would pass it data and a key and it would return encrypted data. The gateway is being built on an IBM PS/2. Any leads would be very much appreciated. I also wonder if other sites are thinking about this problem and, if so, what sort of solution are you looking at? All of the security discussions which I have seen are concerned with authorization and access control (such as dial back) rather than encryption of data. Does anyone know of a forum where this has been discussed? Note, by the way, that we are not planning to do any research into encryption algorithms, a subject I am happy to leave to the mathematicians. Since I do not subscribe to ANY of the lists, please send replies directly to me (as well as the list if you like). Thanks for in advance for your help. Susan Bramhall Senior Research Programmer From: simsong@idr.cambridge.ma.us (Simson L. Garfinkel) 18-JUL-1989 16:04:52 To: security@rutgers.edu Subj: [310] Kevin Mitnick and other hackers in jail I'm thinking about writing an article on this for The Monitor (are people getting tired of these messages?) If anybody has any thoughts on the issue and would like to be quoted in a national newspaper, please send them to me, along with your title, company, and a phone number where I can reach you. -simson From: Ken Bell 19-JUL-1989 18:52:34 To: security@pyrite.rutgers.edu Subj: [468] Re: DES export laws > >Try substituting "tanks" for "DES implementations". > There is a fundamental difference. Tanks can obviously be used to assault There's another difference. You can't carry tanks over in your briefcase or buy the plans for them at B. Dalton's. There's an awful lot of published DES code, and various PC utilities (PCTOOLS, for example) contain DES. The only ones who are being deprived of DES are the non-security risks - the spies/terrorists already have it. From: jimkirk@UWYO.BITNET (Jim Kirkpatrick) 19-JUL-1989 19:34:37 To: security@ubvm Subj: [397] DES for PC/AT Does anybody have pointers to good DES implementations for the PC/AT type system (Zenith 248 in this case)? I'm interested in either software or hardware implementations. Quite a while ago there was mention of a board by Winterhalter but I can't seem to find the company. Any reviews in the trade magazines I (probably) missed? Please reply directly to me, and I'll summarize later. Thanks. From: Chris Petersen _ VUCC 19-JUL-1989 20:14:56 To: security@pyrite.rutgers.edu Subj: [544] Re: DES Export Laws > indeed, I would be surprised > if the Russians are not capable of writing their own DES code. I could have sworn I saw a posting about an article in a Soviet computer science journal that gave an algorithm for breaking badly chosen keys for DES. I may have even seen it [the reference] here... -Chris Petersen Vanderbilt University petersen@ctrvax.vanderbilt.edu Disclaimer: If I say anything at all, it is strictly off the record and should in no way be construed as legal or binding or even authoritative or responsible... :-) From: "PRL::BICKER" 19-JUL-1989 21:00:28 To: "security" Subj: [504] encryption source code in Fortran Hi I'm looking for a Fortran source code to do encryption of Ascii files before transfer over networks. The code will have to run on several different types of machines including Vax, Convex, Cray and PCs. It isn't necessary that it be the ultimate in encryption techniques but should be at least secure from less than major attacks. I checked the archives and found several requests for such codes but couldn't find any source codes. Thanks for the help Cliff Bicker BICKER%PRL.DECNET@NWC.ARPA From: "Keith F. Lynch" 19-JUL-1989 21:33:28 To: tsibouris@vms.macc.wisc.edu Subj: [742] RANDOM vs DETERMINISTIC systems Cc: KFL@ai.ai.mit.edu, misc-security@uunet.uu.net > Does anyone know to distinguish a system that spits out a sequence > of "truly" random numbers ... that has a complex (non-linear) but > deterministic structure? I don't think there is any way, other than to try and see a pattern. If you don't find one, that doesn't mean there isn't one. It might just be too subtle for you to have noticed. > A similar question is: how can you distinguish a good random > number generator from a great one? What tests are used? A good answer would take many k. Most of the poor generators flunk autocorrelation statistics, though. That doesn't mean one that passes is good. How good is good enough, and what tests are necessary, largely depend on what you intend to use it for. ...Keith From: Ken De Cruyenaere 204_474_8340 22-JUL-1989 3:09:24 To: Security@ohstvma Subj: [891] Security Conf. etc. I have not attended any MIS conferences but a colleague has and he did not like it much. Not much substance, I beleive, was the gist of his complaints. I have attended Computer Security Inst. annual conf. for the last 2 yrs and hope to go again this year. CSI annual conf. include a trade show which is quite interesting and informative as well as a variety of sessions, videos, etc. I have also attended a TOPIC conf (1987). TOPIC is/was CA's Top Secret users conference. We have TSS installed on our Amdahl (running MVS). I dont think CA calls it TOPIC any more but they still have an annual conf. p.s. where/what is OSU ? --------------------------------------------------------------------- Ken De Cruyenaere - Computer Security Coordinator Computer Services - University of Manitoba - Winnipeg, Manitoba, Canada, R3T 2N2 Bitnet: KDC@CCM.UManitoba.CA (204)474-8340 From: sph@apss.ab.ca (Shaun Hammond) 22-JUL-1989 3:53:02 To: misc-security@uunet.uu.net Subj: [1061] Re: airport metal detectors > I toss my metal pocket items into the basket that goes > around the metal detector. However, on the occasions I have not done this, > the metal detector has still not gone off. The sensitivity of the detectors seems to vary dependent on the whim of the aviation authority. I would be willing to bet that were you to NOT deposit ALL metal articles in the basket when travelling from an airport up here in W. Canada, the bells and whistles would go nuts. I have noticed a difference on the last two trips I made recently to the US, in that what sets the alarms off at the Edmonton International, goes merrily undetected by the systems in Washington, Minneapolis and Chicago. It would seem that Transport Canada perhaps requires a more sensitive setting than the FAA in the US. examples : I have been asked to remove my wallet with credit cards and try again; the foil in cigarette packages is enough to trigger a response. [Moderator tack-on: Someone also pointed out that any packaging foil, such as that around Lifesavers, can trigger them. _H*] From: Joe McMahon 22-JUL-1989 4:30:29 To: security@pyrite.rutgers.edu Subj: [1148] Re: IBM Mainframe rs232 call-back software=Defender interface? >I'm looking for information about a software package named "Defender" that >runs on IBM mainframes. Ooog. >It provides 3270 emulation over rs232 lines connected to inexpensive modems. >It uses a hang up and call-back approach. Yes, it does. Barely. >What kind of terminal does it expect to see at the remote end? It supports a lot of different terminals. The only one I've actually used with it is a Data General Dasher 200. It *may* be able to use ANSI control. The only file xfer protocol it supports is a proprietary one (can you say "big bucks"? I knew you could), which only runs on IBM PCs (what, there are OTHER machines?) It is not too great an emulator. You MIGHT be able to run RELAY through it, but I don't think it supports Kermit. It runs in "half-ASCII duplex", meaning that it does the character echoing, but doesn't allow type ahead, and locks you out when it is repainting the screen. Its repainting is very poor; usually it resends the whole blasted screen when you are using SPF. Don't know how well it works with VM. Summary recomendation: Security will love it. Your users will hate it (speaking as a user). --- Joe M. From: mfidelma@bbn.com (Miles Fidelman) 25-JUL-1989 0:02:07 To: misc-security@uunet.uu.net Subj: [305] need Unix password program Does anybody out there know of a strong password program for the (Sun) Unix environment? In particular, one that generates pronouncable but meaningless passwords, forces periodic password change, limits retries, etc (like Multics). Please reply by email. Thanks much, Miles Fidelman mfidelman@bbn.com From: palm@duvan.nada.kth.se (Christer Palm) 25-JUL-1989 0:39:17 To: misc-security@uunet.uu.net Subj: [263] Re: Consensus on locks? ABLOY makes Motorlocks (bolt is operated by a motor) an can thus be controlled in a noumerus ways. One way is to open up the door from out side with a key and let the door lock iteself directly when it's closed. This is dunn with a standard sensor in the lock. From: Barry Johnson 25-JUL-1989 1:20:29 To: security@pyrite.rutgers.edu Subj: [407] Re: "copy proof paper" - does such a thing exist? Here at Clemson we have have similar paper that transcripts are printed on. If you try to copy it, the copy is legible but has the words UNOFFICIAL COPY in big letters diagonally across the page. The paper is a reddish/orange color. Hope this helps. Thanks... Barry Johnson CYCLIST@CLEMSON.BITNET Information Systems Development Clemson University. Clemson S.C. 29631 From: lamaster@ames.arc.nasa.gov (Hugh LaMaster) 25-JUL-1989 1:56:56 To: misc-security@ames.arc.nasa.gov Subj: [809] Re: Consensus on locks? (Thanks for the information about Abloy locks - I have received a number of recommendations for them. If there is a consensus, Abloy seems to be it.) >In Finland we have usually decent >handles, that you can turn. Much more easier. This is strictly a safety issue. Handles have been denigrated as a safety hazard to children. Knobs are sized such that it is almost impossible to injure an eye on them. I do not know whether it materially increases safety, but I am sure someone must keep statistics on such things... Anyway, with more lawyers than engineers in the US, we can't afford to take chances with things like that :-) Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117 From: cheetah@blake.acs.washington.edu ( ) 25-JUL-1989 2:27:20 To: misc-security@ames.arc.nasa.gov Subj: [894] System Security I will be bringing a new UUCP site on-line within the next 60 days. In preparation, I am trying to learn as much as possible about information system security. The main emphisis is on the UNIX and VAX/VMS operating systems. If you are aware of any mailing lists, publications, texts, or other sources of information on these subjects, please drop me a note. In an attempt to conserve bandwidth, as well as other obvious reasons, please Email me directly. Thank you for your assistence in this matter. - Steve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." || - Jeremy S. Anderson #include cheetah@blake.acs.wahington.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From: "Kees de Groot (DEGROOT@HWALHW50)" 25-JUL-1989 2:54:59 To: security@finhutc.BITNET Subj: [2187] [2185] Return-path: Date: Tue, 11 Jul 89 13:21:04 EET From: "Kees de Groot (DEGROOT@HWALHW50)" To: security@finhutc.BITNET Automated fingerprint identification system ------------------------------------------- These systems are sold by: FINGERMATRIX Inc. 30 Virginia Road, North White Plains, NY 10603 (914) 428-5441 * Telex: 131236 * Fax: (914) 4280971 Washington, DC Office: (703) 893-3880 I have seen such a system in Katwijk, Holland. The Dutch security-firm 'Bavak en Jung' delivers those systems in Holland. It's a box with a keyboard and a sensor on which you place one of your fingers. Identification costs only a few seconds. To enhance performance PIN-codes can be used. In that case the system only compares fingerprints with the same PIN-code. After the security-operator has identified itself new persons can be registered by the system. To improve false rejection more fingers can be shown to the system. So if you loose one finger you can stil enter your office to get your spare finger! The system does not store a complete image of your fingerprints. It only stores certain unique points where fingerprint ridges end or divide, which are unique to each individual. Policemen have tried to fool the system with various artificial fingers made of rubber and plastic. They even tried to make the temperature and conduction equal to a human finger but no succes! They are still looking for volunteers who want to donate a real fresh cutoff finger.. I have no affiliation what so ever with Fingerprint. I just happened to have this info for a talk about security-devices a few months ago. Tel. +31-8370- .KeesdeGroot (DEGROOT@HWALHW50.BITNET) o\/o THERE AINT NO (8)3557/ 'Computer security' [] SUCH THING AS 4030 Wageningen Agricultural University .==. A FREE LUNCH! Computer-centre, the Netherlands X25: PSI%(+204)18370060638::DEGROOT disclaimer: I always speak for myself - if you go too far to the east, you find yourself in the west .. - From: silber@tcgould.tn.cornell.edu (Jeffrey Silber) 26-JUL-1989 9:35:45 To: misc-security@rutgers.edu Subj: [677] Re: "copy proof paper" - does such a thing exist? Light blue (also called non-reproducible blue) is difficult to copy. It is frequently used in graphic arts applications for outlines, etc. Another method of identifying (but not preventing) copies is to do a half-tone of the background color saying "COPY," which only appears when the item is copied in black and white. This is usually found on checks and other negotiable documents. -- "A billion here, a billion there, and pretty soon you're talking real money." --Sen. Everett Dirksen Jeffrey A. Silber/silber@tcgould.tn.cornell.edu Business Manager/Cornell Center for Theory & Simulation in Science & Engineering From: hplabs!walden@hpdml93.hp.com (Bob Walden) 26-JUL-1989 14:36:59 To: misc-security@rutgers.edu Subj: [225] Interesting Reading?? Does anyone know of any professional periodicals available regarding electronic surveillance and/or use of electronics in law enforcement and security work? Or any good reference material on the subject? Thanks in advance! From: german@uxh.cso.uiuc.edu (Gregory German) 26-JUL-1989 15:17:14 To: security@pyrite.rutgers.edu Subj: [605] TCP/IP encryption What is the status of encryption of the data stream in a protocol like TELNET? I would like to have a version of TELNET that would optionally encrypt the data stream to keep the causual curious net sniffer from reading data off the network. I have source for both ends of the connection I am concerned about, but would rather not totally re-invent the wheel if there has been some work done in this area. Greg German (german@sonne.CSO.UIUC.EDU) (217-333-8293) US Mail: Univ of Illinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801 Office: 129 Digital Computer Lab., Network Design Office From: gwyn@brl.mil 26-JUL-1989 15:59:12 To: security@rutgers.edu Subj: [450] Re: "copy proof paper" - does such a thing exist? >I think the paper was a special shade of red; any writing on this paper >would not show up when copied. ... Yes, it's a dark red and light black printing on it is almost illegible unless you view it under a STRONG light. The computer game "Werdna's Revenge" (Wizardry IV) uses a booklet of code numbers printed on the stuff as a form of software piracy protection. It sucks. I don't know where you get such paper, presumably from a paper mill. From: phil@diablo.amd.com (Phil Ngai) 26-JUL-1989 16:37:22 To: misc-security@ames.arc.nasa.gov Subj: [620] Re: locks |On the other hand, I have friends who had very good burglar alarms on their |house. Doors, windows. Didn't matter. The theives came in through the |walls. This is why I have always felt that a home security system is incomplete without a motion detector inside the house. Preferably at least two, so that they can cover each other. By the way, does anyone know if there are any prohibitions on a home security system releasing tear gas if an intruder enters your house? What about painfully loud sirens? -- Phil Ngai, phil@diablo.amd.com {uunet,decwrl,ucbvax}!amdcad!phil "The government is not your mother." From: wrf@ecse.rpi.edu (Wm. Randolph Franklin) 26-JUL-1989 17:30:15 To: security@pyrite.rutgers.edu Subj: [804] Re: "copy proof paper" - does such a thing exist? Another principle (I think) is a transparent spray coating that fluoresces when exposed to the UV in the xerox lamp. So the whole page copies as white. It's possible that Xerox sells it. I once saw an overpriced newsletter printed in light blue ink on white paper with yellow polka dots. However, it was illegible in the original, before being copied. I also get a laugh from local road maps that print in blue ink. They becore MORE legible after copying on the right machine. -------- Wm. Randolph Franklin Internet: wrf@ecse.rpi.edu (or @cs.rpi.edu) Bitnet: Wrfrankl@Rpitsmts Telephone: (518) 276-6077; Telex: 6716050 RPI TROU; Fax: on request Paper: ECSE Dept., 6026 JEC, Rensselaer Polytechnic Inst, Troy NY, 12180 From: "Craig Finseth" 26-JUL-1989 18:12:00 To: STGEORGE@unmb.bitnet Subj: [1077] [1075] Return-path: Date: Thu, 13 Jul 89 14:18:51 CDT From: "Craig Finseth" To: STGEORGE@unmb.bitnet Cc: security@pyrite.rutgers.edu Since we will only be hiring one person, this person will (gasp) have to handle ALL aspects of security at all levels, from micros to mainframes. My question is not with how to accomplish this, but one of where to place such a person organizationally. Consider for a moment the range of tasks that a security officer performs. In general, their duties cover host security (with account management figuring heavily), communications, building security, personnell (most breaches are inside jobs after all), and just about everything under the sun. It therefore makes sense to place them in some sort of "general administrative" group. Unfortunately, the person in charge of that group probably does not understand security. Cheer up, no one else does, either (:-). For confirmation, look to other organizations where security figures prominently (e.g., banks). I think you will find that they put security in just such a general, but centrally-run division. Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375 From: "John_Hodges.XSIS"@xerox.com 28-JUL-1989 13:24:11 To: hwchoy@zpovc.enet.dec.com Subj: [511] Ethernet Encryption Device Cc: "Frank_Presson.McLeanCSD"@xerox.com, Hodges.XSIS@xerox.com, security The Xerox Corpororation is nearing endorsement for the Xerox Encryption Unit (XEU). The XEU is a stand-alone device, providing Type I encryption service, which is installed in the drop cable between the processor and tranceiver. It can be used on most LANs and with most equipment which conforms to the IEEE 802.3 10BASE5 or Xerox Ethernet Version 1 or Version 2 local area network standard. IEEE 802.2 requirements are not specifically supported. The Xerox marketing manager is Frank Presson (703) 442-6777. From: ixi!clive@britain.eu.net 28-JUL-1989 14:27:36 To: security@ukc.ac.uk Subj: [695] Re: (none) Notice to UK readers - every police division (i.e. every reasonable town) has an officer called a Crime Prevention Officer. His/her duty is to offer *free* advice to anyone who wants it on home/business security. >I now live in a small town in the northwest. >I've been there three years, and have yet to be mugged, burglarized, or >threatened in any manner. Very true. My parents live in a large town (pop. 150 000) - there have been 4 buglaries this year in the 80 properties in their street. I live in a village (pop. 5 000). There have been 4 buglaries in the entire village in the last *fifteen years*. -- Clive D.W. Feather IXI Limited clive@ixi.uucp ...!uunet!ukc!ixi!clive (riskier) From: jad@dayton.dhdsc.mn.org (J. Deters) 28-JUL-1989 15:09:01 To: security@rutgers.edu Subj: [1177] Re: "copy proof paper" - does such a thing exist? There are a few different things you can use to slow down enterprising xerographers. Red appears black to the black and white imaging systems of most copying machines, so red paper makes it more difficult to copy. Light blue does not copy well, so you could write with a light blue felt tip. If you are more concerned about the legitimacy of the document (as in a check) as opposed to the value of the information on it, you could take the same approach that the check vendors use. It amounts to the words VOID-COPY written in a half-tone screen of a solid color being superimposed on a pastel background equating to the same color. (Tough to explain, but easy to see with an example.) Let's say you have a check in front of you that has soft yellow stripes running through it. If you look closely, you will see bright yellow dots (with white space) spelling out the word VOID. Normally it doesn't show, but the copying machine sees the bright yellow letters and reproduces them, ignoring the pastel areas. Examine some of the checks and/or official documents you run into in the next few weeks. -j -- "Captain's log: Stardate 2734.3. 'I am nailed to the hull.'" From: ishikawa@ultra.enet.dec.com (Jim Ishikawa, DTN_293_5054) 28-JUL-1989 15:48:25 To: susan@yalevm.bitnet Subj: [1247] RE: Encryption hardware/software available? There are some DEC products that might be useful to you. Digital's Ethernet Enhanced-Security System (EESS) products sound most applicable, though I'd have to hear a bit more about what gateway functionality is required to be sure. There are two EESS products: The DESNC secure network controller The VAX KDC security management software The EESS provides a number of security features for Ethernet/802.3 networks including transmission of encrypted data between Ethernet devices over unprotected segments. We also have some software encryption products, but none run on OS/2. If you could use a VMS or Ultrix workstation (e.g., VAXstation 3100 or DECstation 2100) you might consider Digital's DES software products. There will be a case study article on using EESS products to enhance the security of university campus backbones in the next revision to the Auerbach "Handbook on LANs." I'll also forward your message to some people who have been dealing with various security problems on campus networks. If you have any questions or would like some additional assistance please feel free to contact me. Jim Ishikawa Product Manager ishikawa@ultra.enet.dec.com decwrl!ultra.dec.com!ishikawa 508-264-5054 From: hughes@ns.network.com (Jim Hughes x1676) 30-JUL-1989 5:55:33 To: misc-security@rutgers.edu Subj: [326] Dial back modems A while ago there was a question about dial back modems. I stated that there was a "defender" modem, but that I did not know of the company name. They have just sent me some mail. The company name is: Digital Pathways Inc. 201 Ravendale Drive Mountain view, CA, USA 94043-5216 (415)964-0707 jim hughes@network.com From: zeleznik@cs.utah.edu (Mike Zeleznik) 30-JUL-1989 7:14:20 To: security@pyrite.rutgers.edu Subj: [816] Re: Thumb scanning devices As for explicit thumb print authentication, you might check out the ThumbScan Fingerprint System: ThumbScan, Inc. Two Mid-America Plaza, Suite 800 Oakgrook Terrace, IL 60181 312-954-2336 Another approach which avoids the need to carry something with you is the real-time analysis of typing keystroke characteristics, like in the Electronic Signature Lock (if it is still around): Electronic Signature Lock Corp. 1311 Ulloa St. San Francisco, CA 94116 415 558-9133 / 681-7325 I have NO personal experience with either of these; have only seen their literature and talked with them. Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617 From: Margie Rogis 30-JUL-1989 8:36:39 To: security@rutgers.edu Subj: [860] RACF question This is addressed to any site running RACF - I have a user who has only READ access to data sets under a generic profile 'ADMI.P.*'. This user was able to create (and therefore later delete) a data set falling under that profile's protection. No other more specific profile applied. I have read the Administrator's Guide, and I don't understand why she was able to do this. According to page 4-4, a user can create a new user data set ONLY if he/she has ALTER authority to the data set via the generic profile or global access checking; neither is true in this case. always-call, Additional info: We have always-call, the users do not have ADSP, and PROTECT-ALL is not in effect. Am I missing something? I'd appreciate any insight from someone who knows RACF better than I. Thanks in advance... [Moderator reminder: Replies to him, please.. _H*] From: mason@eddie.mit.edu (Nark Mason) 30-JUL-1989 10:15:24 To: security@pyrite.rutgers.edu Subj: [991] thumb scan devices I have seen a thumbscan in the kilobuck range made by, I believe, ThumbScan Inc, probably in Cambridge, Ma. The version I saw was attatched to a PC. They make a couple of other interesting security devices, one I thought do be really clever is called the Gordian Knot. It is a epoxy potted "thing" about the size of the average electronic stopwatch with a photodetector and an LCD readout, and it self destructs when it thinks someone is tampering with it. The idea was that the software would flash a spot on the screen in a certain pattern, you would hold the device to the screen, it would read the pattern being flashed, hash, trash, encrypt and discombobulate it and hand back a number that the software would already be expecting. Quite a bit more versatile than the IBM label Medeco locks on the 3270 and infinately more clever. (I seem to think they were about $14 in small quantity). They could also be programmed (only once) to self destruct at a given time or just expire. From: NESCC@nervm.nerdc.ufl.edu (Scott C. Crumpton) 30-JUL-1989 11:37:17 To: SECURITY@pyrite.rutgers.edu Subj: [1069] Another encryption software request I have a need to keep some of my PC (IBM clone) data encrypted. However, none of the encryption programs that I have tested to date do what I want. They all take an input file and encrypt it to produce an output file. All fine and good for the occasional file or two. What I want to do is declare entire directories as encrypted and have the encryption package automatically encrypt/decrypt any data in these directories. I know there are some full blown security packages that will do this, along with multiple users/passwords, protected directories/files, etc. But I'm not really interested in all of that and the associated overhead. Simple physical security is good enough in this case, the encryption is desired to protect only a small subset of the data in the event the PC is stolen. So, my question: Does anyone know of a package that will do what I need? A full blown system that can be selectively installed would be acceptable. (Note: This must be a software solution, there are no expansion slots on the PC in question.) Thanks in advance. ---Scott. From: makela@jyu.fi (Otto J. Makela) 30-JUL-1989 12:36:28 To: misc-security@cwi.nl Subj: [1122] Re: consensus on locks About Abloy locks not wearing down well: As is known, Abloys (originally) come from Finland. Here they are the most common type of locks. I just recently had to have my apartment lock replaced because it was so worn-out it was hard to get it to stay unlocked ! It had been originally installed when the house was built, in 1962. The lock still opened the door very nicely, though. Also, I personally changed the lock for my parent's front door - their house was built circa 1955... the lock was still quite operational, but had the same problem of not properly latching to the "unlocked" position. How long do apartment locks (used several times daily) last, in general ? Otto J. Makela, University of Jyvaskyla InterNet: makela@tukki.jyu.fi, BitNet: MAKELA_OTTO_@FINJYU.BITNET BBS: +358 41 211 562 (V.22bis/V.22/V.21, 24h/d), Phone: +358 41 613 847 Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE "In the week before their departure to Arrakis, when all the final scurrying about had reached a nearly unbelievable frenzy, an old crone came to visit the mother of the boy, Paul." - Frank Herbert, Dune From: bcn@june.cs.washington.edu (Clifford Neuman) 2-AUG-1989 19:34:31 To: misc-security@beaver.cs.washington.edu Subj: [144] Re: TCP/IP encryption The Kerberos system available from MIT's Project Athena comes with a version of rlogin that will optionally encrypt the data stream. ~ Cliff From: tower@bu_cs.bu.edu (Leonard H. Tower Jr.) 2-AUG-1989 20:19:56 To: misc-security@husc6.harvard.edu Subj: [177] ??: Are modems harmed by airport X-rays? Has anyone had problems with modems after they have gone through the X-Ray machines used by airport security guards? Have to do this soon, and wanted to check. thanx -len From: "Alejandro Kurczyn S." <499229@VMTECMEX> 2-AUG-1989 21:01:31 To: SECURITY@UGA Subj: [296] Security on a PC Hi, I'm not a member of this list, and perhaps this isn't the right place to post this but... Can anyone tell me what is the latest techinque to copy-protect a PC diskette? how can I do the protection? please mail me directly, this is really urgent.. -Alejandro System operator ITESM CEM * From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 2-AUG-1989 21:44:20 To: security@pyrite.rutgers.edu Subj: [450] DES on PC -- summary I recently asked about DES on PC-type computers, promising a summary of responses. Here's what I got -- 1. A request for a copy of what I get. 2. A reminiscence about a fairly old DES from another list 3. An address in West Germany that sells a software implementation. 4. A nice list of various manufacturers, complete with address. Thanks to those who responded. If anybody wants a copy of the responses, E-mail me and I'll forward. From: EVERHART%ARISIA.decnet@crdgw1.ge.com 2-AUG-1989 22:21:31 To: SECURITY@pyrite.rutgers.edu Subj: [1029] Re: "copy proof paper" Defeating a "copy proof" paper based on paper color only is fairly straightforward. You get a sheet of colored celluloid or the like and place it in front of the item being copied. Look through the celluloid and if you can't SEE the lettering, the copier generally won't either. Our copier (one of the newer Xerox models) has sufficient contrast adjustments that the quality of the copy can nevertheless be made most adequate. The same trick can be used if you want to duplicate the red "proof" photos some photographers use. A useful fact is that a CuSO4 solution (copper sulphate) of reasonable density will filter out ALL red light (down to the sub 1 photon level; it's used to filter lasers and select second harmonic radiation!). Use a small bit as a filter & contact print the pic onto roll film...voila! Your very own negative! (This is a major pain in the neck to do and should not become a habit...the poor photog. has to make a living, after all. The filtering technique is occasionally useful though.) Glenn Everhart From: mk59200@funet.fi (Kolkka Markku Olavi) 2-AUG-1989 23:07:13 To: misc-security@cwi.nl Subj: [948] Re: consensus on locks > ... However, according to this one locksmith, Abloy locks > don't wear well. If they are not treated gently, they will begin to jam. Several millions of Abloys are in use here in Finland, many of them decades old. The weather conditions aren't exactly 'gentle' here. The Abloy has a very simple but efficient design with a minimal number of moving parts. The manufacturer recommends lubrication with thin oil now and then (just a few drops into the keyhole), and that should keep it working. > Abloy keys cannot be duplicated at the shop as a standard Medeco can. The > "Platinum," or biaxial, Medecos are in the same boat as the Abloy.) There are also several variants of Abloy, with different levels of availability of key blanks and duplication service. Disclaimer: I have nothing to do with Wartsila Oy (manufacturer of Abloy locks), except that I have been using Abloys all my life. (well, almost) -- Markku Kolkka mk59200@tut.fi From: melling@gateway.mitre.org (Phil Mellinger) 6-AUG-1989 18:27:41 To: security@pyrite.rutgers.edu Subj: [349] Encryption Programs over International Nets Something interesting occurred to me concerning the transfer of encryption programs over networks that have international connectivity? Can you ship such encryption programs (which may be export sensitive) over international networks or is this a violation of export laws? This sounds silly but I am curious... Phil Mellinger From: Bob Dixon 6-AUG-1989 19:10:09 To: security@pyrite.rutgers.edu Subj: [242] Re: encryption source code in Fortran We have Fortran source codefor DES as part of our larger system of across-platform encryption software. But it is all tied up in the legalese problems now. Bob Dixon Ohio State University From: gwyn@brl.mil 6-AUG-1989 19:42:45 To: security@rutgers.edu Subj: [371] Re: encryption source code in Fortran >I'm looking for a Fortran source code to do encryption of Ascii files ... See section 7.5, "The Data Encryption Standard", of "Numerical Recipes -- The Art of Scientific Computing" by William H. Press, Brian P. Flannery, Saul A. Teukolsky, and William T. Vetterling (1986, Cambridge University Press), ISBN 0-521-30811-9 (book), ISBN 0-521-30957-3 (FORTRAN diskette). From: Earl Culham 6-AUG-1989 20:23:55 To: misc-security@watmath.waterloo.edu Subj: [746] Re: Encryption hardware/software available? >We are interested in providing an encrypting gateway for our campus network. >... Ideally, it would be a card with the ability to >encrypt/decrypt on its own chip rather than taking up workstation CPU cycles. I've recently run across a device which suits this purpose well. The FasTok box is a combination encryptor/compressor. Its normal configuration is as an active modem cable, plugging in between the computer and the modem, at both ends. It is transparent to both the computer, and the modem. It both encrypts and compresses. The quoted compression ratios were in the 2 to 5 times range. I have no connection with the manufacturer, other than friendship. However, I will relay questions to and from the net if there is an interest. From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin) 6-AUG-1989 20:54:59 To: att!misc-security Subj: [1021] Re: DES Export Laws > I could have sworn I saw a posting about an article in a Soviet computer > science journal that gave an algorithm for breaking badly chosen keys for > DES. I may have even seen it [the reference] here... There's been a rumor floating around on the net that the Soviets have cracked DES, and published that fact in one of their academic journals. Apart from the implausibility of that, Don Mitchell did a fairly thorough literature search, with the aid of a Russian-speaking reference librarian, and found nothing. Now -- for certain badly-chosen keys, that isn't out of the question. There are 4 "weak keys" -- 01010101 01010101, FEFEFEFE FEFEFEFE, 1F1F1F1F 0E0E0E0E, E0E0E0E0 F1F1F1F1 -- which should be avoided. There are also a set of "semi-weak keys" which present a smaller security risk. All of these should be avoided in critical situations, i.e., master keys used to encrypt session keys. See Davies and Price, "Security for Computer Networks", for details. --Steve Bellovin smb@ulysses.att.com From: Roy Stehle 6-AUG-1989 21:28:39 To: Security@pyrite.rutgers.edu Subj: [1110] Non-copyable paper Cc: stehle@tsca.istc.sri.com The following appeared in Denise Caruso's column in the 23 July 89 issue of the San Francisco Examiner: "Speaking of proprietary vs. public information, I'd like to personally thank NoCopi International of Montreal, makers of the uncopyable, unfaxable paper used by Apple Computer inc., Broderbund Software, Sierra On-Line and others to stem the flow of proprietary data. NoCopi's got a new product combo that's going to make my job a lot more creative. "Norm Gardner, president and CEO of NoCopi, says the two products are the first to come out of its new Canadian research center - a clear-ink highlighter and a white, chemically treated paper. You can type or print onto the paper with plain old ink, just like usual. But if you highlight text on the paper using the marker and try to photocopy or fax the page, the highlighted material is blocked out as completely as if you used a black marker. "He says the products will be ready to ship by year end, ..." This is provided for your information and further investigation. I have no experience with NoCopi. Roy Stehle SRI International From: "Quick, VT_180, to the VAXmobile." 6-AUG-1989 22:04:06 To: security@marist Subj: [2697] DES and the Soviets I have seen a reference to a Soviet article about DES, but no one has ever been able to provide me with enough information to track the article down. I am prepared to dismiss it as a myth, until someone puts a real reference here. While the question of export control (of DES, and of other things) is certainly of great interest, the issues are wildly complex and not going to be solved here. However, here are some comments on some stuff people have said: Just because something appears on Usenet doesn't mean that it has made it to the USSR. And just because it has made it to one or two folks there, doesn't mean that there is broad distribution. The USSR is just like the US. A piece of technology may be well embedded in a particular department or office, or even a whole building, but it is unlikely to spread quickly around the country, or even across the hall. Communications are heavily stifled. There is no concept of BBS/Usenet in the Soviet Union---the people who have access to Western databases number less than 100. I'm not saying that DES restriction is bad/good; what I am saying is that Dr. Dobbs is not widely read in the Soviet Union. A $40 subscription to Dr. Dobbs is 80 days pay for the average Soviet (because Dr. Dobbs doesn't take Rubles). The argument that ``this is everywhere in the US public domain'' has no relevance when extended to the USSR. When the argument is made that ``the spies/terrorists have whatever they want,'' that is also not very valid. This argument is used quite often by Soviet academics we meet to explain why the US should sell computers to the Soviets. In fact, the unstated policy of US export controls is to keep the Enemy (you know, the dark empire) in bare feet and technological illiteracy. What do you think the military industrial complex depends on? Answer: the research done everywhere else in the country. Whether we admit it or not, the policies that DoD promotes through Commerce (note that DoD, Commerce, and the Businesses-that-want-to-make-a-profit form three legs of a triangle that is in eternal conflict. DoD would have them in the stone age, while Business wants to increase exports and make our economy stronger) are aimed at restricting technology EVERYWHERE in the country. So, you can fight that particular policy, but you can't use a rational argument, since the policy isn't there for rational reasons (well, let's just say not for reasons that are entirely above board). jms Joel M Snyder, U Arizona MIS Dep't, Tucson, AZ, 85721 Phone: 602.621.2748 BITNET: jms@arizmis Internet: jms@mis.arizona.edu SPAN: 47541::uamis::jms SM-1700 - A small VAX that's *all* VAX (except it's made in the USSR) From: heim!scott@grian.cps.altadena.ca.us 10-AUG-1989 7:02:57 To: misc-security@ames.arc.nasa.gov Subj: [1478] Re: airport metal detectors >I would be willing to bet that were you >to NOT deposit ALL metal articles in the basket when travelling >from an airport up here in W. Canada, the bells and whistles would go nuts. No kidding! I was working for a computer game manufacturer a year or so ago, and we had a game called "Airborne Ranger" - a nice trench warfare simulation. Well, as a promotional gift, we had some practice HAND GRENADES stenciled w/ the games logo (they made good paperweights, if you go for that kind of thing). I have one of those metal briefcases (Zero Haliburton I think), which may have helped obscure things... but a friend tossed one of our little "promotions" into my briefcase with out my knowing! This was not done malicously, I had asked for one.... To continue, I traveled from Baltimore Int'l to John Wayne Int'l (Orange Co. CA.) with a plane change inbetween with my mock explosive brief- case as carry on! This meant two different scannings that failed to turn up something which should have a pretty blatent signature. The next day when I noticed what I had gotten away with, I was pleased that I hadn't been pulled aside for questioning, or inadvertantly shot for someone too nasty to be dealt with nicely, but it didn't take too long for me to realize that I might feel a little safer in the future if I had been stopped. True Story - no joke. -- Scott Watson - "Inane little message goes here" uucp: {rutgers,ames}!elroy!grian!heim!scott Internet: scott@heim.UUCP From: Homer 12-AUG-1989 23:36:23 To: "Security List." Subj: [323] Re: locks There is the story of the store owner who was robbed repeatedly by his fellow denizens. They came in through the roof of his store. He got fed up and wired the place with wall current. Someone came in and fell into his trap and was electrocuted. Well cooked I imagine. The jury threw the book at him for murder. From: Douglas James Martin 13-AUG-1989 0:13:15 To: silber@TCGOULD.TN.CORNELL.EDU, security@UBVM.BITNET Subj: [481] Re: "copy proof paper" - does such a thing exist? Light blue is also often used in some vital parts of the docs of computer games rather than copy-protection of the disk; you can copy the game disk fine but the game is unplayable without tedious manual copying of the non-photocopyable stuff. This was a long time ago, so I can't give sources, but I'm sure I read somewhere of the use of dyes that are highly flourescent under the lights used by copiers (something about there being lots of UV in them) used to screw up copying. From: Charlene Charette 13-AUG-1989 0:42:23 To: security@pyrite.rutgers.edu Subj: [586] home security When I was working for a security company (commerical and residental), we had a clothing store customer who insisted she didn't need a motion detector since all her doors and windows were protected. The thieves drilled through a cement wall and thus did not set off the alarm (they were after furs). As far as a home security system dispensing tear gas: with people being so sue happy today it could cause problems? Have you heard of the case where a thief robbed a house that was being bug-bombed and died? His family is suing the homeowners for his death! --Charlene Charette From: Dr. T. Andrews 13-AUG-1989 1:14:58 To: security@pyrite.rutgers.edu Subj: [500] Re: "copy proof paper" - does such a thing exist? ) I think the paper was a special shade of red; any writing on this ) paper would not show up when copied. ... This reminds me that I have never found a check printer who will provide checks on such red paper. The banks are reputed to use a variety of film for their copies on which such checks will not be legible. Does anyone know of a source for such checks? -- ...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!ki4pv!tanner or... {allegra attctc gatech!uflorida uunet!cdin-1}!ki4pv!tanner From: cowan@marob.masa.com (John Cowan) 13-AUG-1989 1:48:04 To: misc-security@rutgers.edu Subj: [825] Re: locks >By the way, does anyone know if there are any prohibitions on a home >security system releasing tear gas if an intruder enters your house? >What about painfully loud sirens? In general, an automatic system may do only what you might do if you were physically present. To take an extreme example: suppose you rig up an automatic device to fire a gun at intruders. Then anyone who is shot can sue you if you yourself would not have been justified in using deadly force. (This reflects actual cases: farmers setting up spring-guns to protect their crops and then blowing away a neighbor's kid.) -- Internet/Smail: cowan@marob.masa.com Dumb: uunet!hombre!marob!cowan Fidonet: JOHN COWAN of 1:107/711 Magpie: JOHN COWAN, (212) 420-0527 Charles li reis, nostre emperesdre magnes Set anz toz pleins at estet in Espagne. From: Bob Dixon 13-AUG-1989 19:58:38 To: security@pyrite.rutgers.edu Subj: [207] Re: Ethernet Encryption Device How much of the packet does the Xerox device encrypt? Can the packet pass thru a router after being encrypted? Bob Dixon Ohio State University From: gavron%dac@lanl.gov (Ehud Gavron, MS H828 (505)665_1131) 13-AUG-1989 21:21:27 To: "security@pyrite.rutgers.edu"%beta@lanl.gov, GAVRON%beta@lanl.gov Subj: [222] RE: ??: Are modems harmed by airport X-rays? I have passed modems through airport x-ray machines, magnetic detectors, and even (forbid) baggage handlers... The modems have survived with no problem, a tribute to their American Roboticized manufacturer no doubt. From: Bob Dixon 13-AUG-1989 22:03:17 To: security@pyrite.rutgers.edu Subj: [516] RE: Encryption hardware/software available? The DEC encryption approach was described to me to have 2 significant defects: 1. You have to have a VAX to use it. 2. Too much of the packet is encrypted, such that the packets can only pass thru bridges, and not routers. Can someone who really knows verify this? We would be very interested in ethernet encryption hardware that was vendor-independent and encrypted ONLY the innermost "text" portion of the packets. Bob Dixon Ohio State University From: Reality is not an Industry Standard 13-AUG-1989 22:49:40 To: security@marist Subj: [576] pc encryph - the whole directory Try using Lattice SECRET DISK II. It can set updirectories to be hidden and additionally encrypted in either DES or their faster (less secure?) format. You load it as a device driver and a COM or EXE program. It works well (I demoed it several months ago and havent used it since) but will not work on many Zenith DOS PCs because of the partition table and the partition assignment program. It should work if you have firmware defines disk partitions - if you have more than one. J. Peterson LIU/Southampton Academ Comp. Disclaimer? Show me where I signed. From: 13-AUG-1989 23:32:58 To: security@pyrite.rutgers.edu Subj: [701] Brand new DES? > 2. A reminiscence about a fairly old DES from another list I guess this refers to my message. I said that John Gilmore posted a C source to DES on netnews a while ago, which I got to work on PC with minimal effort. I wonder if Jim is using the attribute 'fairly old' to put down this implementation. DES itself is fairly old, and probably not very secure; there seem to be better codes around, but if one wants DES, then it should not probably matter how old the implementation is, as long as it's DES. S in DES is for Standard. A 'brand new DES' probably should not be called DES anymore. Is Jim using 'DES' as a generic term? I'm all confused. Dimitri Vulis Department of Mathematics CUNY GC From: Lambert@dockmaster.ncsc.mil 14-AUG-1989 0:11:25 To: Security@rutgers.edu Subj: [1263] Network Encryption System MOTOROLA GEG DEVELOPS SECURITY SYSTEM FOR PROTECTION OF LOCAL AREA NETWORKS (LANS) Motorola Government Equipment Group (GEG) has introduced its Network Encryption System (NES), which features the latest in security services for the protection of Local Area Networks (LANs). Designed in accordance with Secure Data Network System (SDNS) standards including SDNS electronic key management, the NES is a flexible internet security solution for Type I applications. The NES is unique in COMSEC technology because the protocol software is loaded via diskette. The NES is installed in the drop cable between the computer and the transceiver, or as a gateway device separating a LAN from a backbone network. The product supports both DoD and ISO internet standards allowing protection over wide area networks. The initial product accommodates connection to IEEE 802.3 and IEEE 802.4 medias. Motorola Inc. has a Memorandum of Agreement with the National Security Agency and anticipates product endorsement in the first quarter of next year. The LAN product represents the first of a family of SDNS products that will provide complete, interoperable system security solutions. Additional information on the NES can be obtained from Joe Marino at (602) 441-5827. From: joe@pnet51.cts.com (Jim Henderson) 15-AUG-1989 1:55:03 To: misc-security@uunet.uu.net Subj: [378] Re: Another encryption software request PC Tools Deluxe has a program with it called "PCSECURE" which will do an entire directory using the DES Encryption Standard. I have used it, and have found it to be a very good program. Jim Henderson, joe@pnet51.cts.com "Don't ask me how it works or I'll start to whimper." - Arthur Dent DISCLAIMER: "I speak for myself, and only for myself." (Except where noted.) From: McLellan@dockmaster.ncsc.mil 15-AUG-1989 2:08:14 To: Security@pyrite.rutgers.edu Subj: [482] Covert channels Why is there so little awareness of the way many third-party software packages open vulnerabilities in even the perfectly managed C2 commercial systems? Even IBM, I'm told, still sells third-party software which can be used to wrench open MVS. Haven't the core sw products matured enough that this problem can be acknowledged and we can begin to address it? Only the hackers, and maybe the EDP auditors, seem to discuss this problem. Vin McLellan The Privacy Guild Boston, Ma. From: Peter G. Capek 15-AUG-1989 2:20:20 To: security@pyrite.rutgers.edu Subj: [504] Non-copyable paper I don't know what relation NoCopi's product has to it, but Xerox patented a method for inhibiting document copying as long ago as 1973. I don't know whether Xerox ever manufactured what they patented (seems like it might not be in their best interest :-) ). The idea behind the Xerox work seems to be fluorescent dyes; is it publicly known how the NoCopi stuff works? For anyone who wants the details, the Xerox stuff is UK patent number 1 338 893. Peter Capek IBM Research -- Yorktown Heights, NY From: Cliff Collins 15-AUG-1989 2:52:14 To: security@pyrite.rutgers.edu Subj: [1057] Announcement This is a pre-announcement of the availability of DES software for a variety of computers with a new feature: interoperability! We at Ohio State University have successfully ported the code that was graciously made available by Phil Karn and James Gillogly to 8 different brands of computers. They are: IBM/MVS Pyramid/OSx HP-UX VAX/Ultrix VAX/VMS Sun/SunOS MS-DOS Macintosh/MacOS We are currently working to extend that to the following platforms: IBM/VM Cray/Unicos Macintosh/AU/X Xenix RISC/Ultrix You say, "there must be a catch." Well, I must concede, there is. Being a state university we are working with our lawyers to make it available on the network via ftp. Let me say two words:"EXPORT RESTRICTIONS." We will keep you up to date on any developments as they happen. Needless to say, we are committed to finding a way to distribute this covey of code the cheapest way possible. Thank you for your support. Clifford Collins Assistant Director, Special Projects Instruction and Research Computer Center From: Bill Doviak 15-AUG-1989 3:23:08 To: info-unix@sem.brl.mil Subj: [1126] Looking for: SNA Session-level encryption hardware/software. Apologies in advance if this query is not appropriate to this group. I have tried comp.protocols.ibm and comp.protocols.misc to no avail. Here goes ... I am looking for either commercial or public-domain software implementing SNA secondary-logical unit (SLU) LU0 protocol using process-based encryption. Usually, the actual encryption is performed with hardware assistance. If necessary, I am willing to integrate one vendor's LU0 product with the encryption support available from another source. I have already done this under MS-DOS using my own SNA/LU0 software. My preference is for a SYSV-compatable product running on the NCR Tower series including the 32/200. However, ANY pointers to hardware/software source are appreciated. Please respond by EMAIL and, if the volume is sufficient, I will summarize later. Thanks, Bill -- Bill Doviak | US MAIL: Electronic Data Systems (EDS) UUCP: vu-vlsi!lxn!bill | Lanark Building or bill%lxn.uucp@rutgers.edu | Center Valley, PA 18034 or lehi3b15!lxn!bill | Voice: (215) 282-1213 From: stodol@diku.dk (David Stodolsky) 14-SEP-1989 8:53:05 To: misc-security@dkuug.dk Subj: [4494] Personal Health Security System Radio Netherlands International, Saturday, 12 August 1989, will have more on this: ---- The objective of the research is to develop a Personal Health Security System. The term "personal" is used because the system is based on a card that can be carried by the person at all times. Security is enhanced by requiring entry of a secret code prior to operation. Computer-chip-based money cards use a similar technology. The term "personal" is also used to indicate that the system is designed to protect the right of users to control their own health records. This is particularly important when persons may be discriminated against because of their health status, or when sensitive personal information is to be stored. If health records are not stored because of inadequate data security, then people's exposure to infectious agents can not be effectively controlled. The term "health" is used because the card would store not only medical records, but also behavioral information. Also, our strategy for health maintenance includes social support as well as medical support. We use the term "security" to indicate that the objective is protecting and securing the health of the user, and to indicate that information security is a key feature of the system. Both physical and cryptographic security techniques are used to protect data. Cryptography is used to build information exchange procedures that permit both privacy and anonymity to be preserved. The term "system" is used because the health card, like a telephone, is only useful if there are other similar devices to exchange information with, and because both human and machine elements must act in coordination if the benefits are to be obtained. Finally, a system view, that considers the interaction of all system elements and the benefits to every person is necessary to ensure proper function. Recently, we have seen examples of what can happen when system wide effects are not considered. In one case, the number of persons donating blood in a city in Sweden increased sharply. Apparently people were using blood donor pins as evidence that they were in good health when meeting others at dance halls. Of course, since a person could acquire an infection after giving blood, or even use someone else's pin, there was no real security. The authorized user of a health card, and only the authorized user, could at any time cause the card to issue an up-to-date health certificate. It could also read and validate a certificate issued by another's card. The validation might be an unforgeable digital signature from a medical doctor on the certificate. Furthermore, ones health card could be programmed to automatically exchange certificates with another person's card. The purpose of exchanging certificates would be to evaluate infection risk from transfer of bodily fluids. Such transfers accompany sexual activities, and blood and tissue donation. A small display on the card could show the results of the evaluation. The certificates issued could not be used to identify or trace the card user. Furthermore, a privacy preserving procedure ensures that sensitive information is only released when needed, that is, when the automated negotiation process indicates that the interaction will take place. These exchange procedures can be thought of as generating informational barriers that prevent transmission of infectious agents. ----- Time and frequency information (UTC [Universal Time Coordinated] = GMT, Summer Time (DST) shifts *not* indicated: Europe at 11:30 - 12:25 UTC; 9715 & 5955 kHz (31, 49 meter bands) 14:30 - 15:25 UTC; 5955 kHz North America at 00:30 - 1:25 UTC; 15315, 6165 & 6020 kHz (19, 49, 49 m.) 3:30 - 4:25 UTC; 9590 & 6165 (31, 49 m.) Australia (central & eastern) 7:30 - 8:25 UTC; 9715 & 9630 kHz (31, 31 m.) 10:30 - 11:25 UTC; 9675 (31 m.) Coverage is world wide. For other areas consult a local information source. Otherwise, email me or contact Radio Netherlands Int'l, English Section: Email - RNI@500/202.fidonet.org (this hasn't worked for me), Int. Tel. +31 35 724 211, Fax. +31 35 724 352. ------- -- David S. Stodolsky, PhD Routing: <@uunet.uu.net:stodol@diku.dk> Department of Psychology Internet: Copenhagen Univ., Njalsg. 88 Voice + 45 31 58 48 86 DK-2300 Copenhagen S, Denmark Fax. + 45 31 54 32 11 From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 14-SEP-1989 9:34:41 To: security@pyrite.rutgers.edu Subj: [4955] Response on DES query Well, I got over 20 requests for my replies about DES stuff on PCs. As a result, I'm just going to post it rather than reply to each one of you. Hopefully the moderator will understand :-) The first is probably the most interesting. I will add the usual disclaimer that I'm not affiliated with any of these folks. Also, sorry for the delay, I was at SIGGRAPH last week! And hopefully none of the repliers will object to their mail being posted. Date: 19 Jul 89 13:17:06 GMT From: Russel Pearson Subject: DES for PC AT There is a lot. I will give you only the names of some companies who furnish interesting products. We do not possess any of them now but we are in the process of look what is available on the market. Technical Communications Corporation 100 Domino Drive Concord MA 01742 Tel: 617-862-6035 telex: 923407 Fax: 617-371-1280 They have a lot of products implementing DES, for example Secure Telecom Inc. P.O. Box 70337 Sunnyvale, CA 94086 Tel: 408-992-0572 Fax: 408-992-0573 The produce a modem/DES-encryptor/multiplexor-multidrop/remote-control Ficher International System Co. PO Box 9107 4073 Merchantile avenue Naples, Florida, 33942-9981 Tel:800-237-4510 Could be interesting: XEUS/3270 Coax, XEUS/Async XEUS/RSA RSA Data Security Inc 10 Twin Dorphin Drive Redwood City, CA 94065 Tel: 415-595-8782 Fax: 414-595-1873 They furnish an implementation for E-mail of RSA famous cypher algorithm American Computer Security Industries, Inc. 112 Blue Hills Ct. Nashville, TN 37214 Tel: 615-883-6741 Product: Compsec-II-Z1 and Comspec-II-Z1-H Sector Technology 5109 Leesburg Pike Suite 900 Falls Church, VA 22041 Tel: 703-379-1800 They can transform your machine in a C2 level secure system (with DES encryption included) Advanced Computer Security Concepts 4609 Logsdon Drive Annadate, VA 22003 Tel: 703-354-0985 CryptBoard(tm) implemented DES Wisdom Software Inc. P.O. Box 460310 San Fransisco, CA 94146-0310 Software: FileEncrypt(tm) for MS-DOS and OS/2 Hope that will of some utility. Good luck ! ------ Russel Pearson rpearson@drev.dnd.ca Defence Research Establishment Valcartier (DREV) phone: (418) 844-4664 Informatics Center/Scientific Support Service fax : (418) 844-4646 PO BOX 8800 Courcelette, Quebec Canada G0A 1R0 envoy: r.pearson/crdv.drev DISCLAIMER: The above was the opinions of an individual and in no way reflect the views of my employer (Department of National Defence) --------------------------------------------------------------------------- Date: Wed, 19 Jul 89 22:18 EST From: Dimitri Vulis Subject: DES for PC/AT I while ago, John Gilmore posted a DES implementation on news. I took it, and compiled it using MS C 3.0 (which should tell you when approximately it was). I made it much faster by pre-computing everything that could be pre-computed and using table lookups. Unfortunately, I have no idea where I put it later. Dimitri Vulis Department of Mathematics CUNY GC ------------------------------------------------------------------------- Date: Sat, 22 Jul 89 00:41:13 MEZ From: Bernd Fix Subject: DES for PC/AT Hi Jim, you can get a DES software implementation for PC/AT's from BrainON!, Schulstrasse 10, D-6925 Eschelbronn, West-Germany for approx. $140 plus shipping. On a 20MHz-386 (my computer) it en/decrypts about 8510 bytes/sec - quite good I think. All the best to you, Bernd. -- +------------------------------+-------------------------------+ | bernd fix | | | handschuhsheimer l'str. 45 | wer redet, luegt. | | d-6900 heidelberg | wer schweigt, kollaboriert. | +------------------------------+ nichts ist wahr. | | bernd@nexus.uucp | alles ist erlaubt. | | ...!doitcr!rnihd!nexus!bernd | | | bernd%nexus@DB0TUI11.BITNET | william s. burroughs | | tel.: +49 62 21 / 41 06 73 | | +--------------------------------------------------------------+ ------------------------------------------------------------------------------ From: devine@cookie.enet.dec.com (Bob Devine) Date: 2 Aug 89 17:16 Subject: Re: DES on PC -- summary Hi Jim, if you are still looking for a DES program for a PC, I have one that I will sell for $30. I wrote it about two years ago but never found a market for it. It is small (about 30K if I remember correctly) and will do a full encryption cycle in about 10 milliseconds on an AT. That's faster than any other DES program I've seen for a PC (including IBM's assembler code that runs inside of automated teller machines). If you are interested, send e-mail back and I'll give you more details. Bob Devine DEC Database Development/Colorado Springs From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 14-SEP-1989 7:54:59 To: security@pyrite.rutgers.edu Subj: [259] One more on DES OOPS, in my previous posting about DES for PCs, I forgot to mention that Darrel Long sent me a SHAR file containing a DES implementation in C for Unix. Way too big to post, so drop me a note if you want a copy. I have not tried it yet, being a VMS person. From: "Richard B. August" 14-SEP-1989 12:52:29 To: security@pyrite.rutgers.edu Subj: [343] RE: COPY PROOF PAPERS/DYES In the case of blue printing one has only to place a yellow filter between the copier plate and the item being copied. The yellow dye in yellow view graph transparency film is usually satisfactory to bring the print out. This will not make a good looking print, but it will allow you to get the data off the page. Regards, Richard B. August From: jimkirk@outlaw.uwyo.edu (Jim Kirkpatrick) 14-SEP-1989 13:54:20 To: security@pyrite.rutgers.edu Subj: [1146] Dongles are still alive Some time ago, there was a discussion on "dongles" on this list. The general impression was that dongles were a poor idea and nobody really was serious about them (at least that's my recollection). FYI a dongle is a physical device, plugged into a PC's parallel printer port as an example. The software looks for the dongle and refuses to work if it is not there. While at SIGGRAPH last week in Boston, there was a company called Rainbow Technologies showing off their "Software Sentinel" "revenue protection system." It is a small device that plugs into the PC's parallel printer port (and passes through), and since they were selling it as a development tool, includes software drivers for many languages. Older dongles were simply made up of a specific wiring, or perhaps even a ROM. The newer ones appear to include a chip that may even do encryption. Their flier says it "Uses highly-secure algorithm technique" and "all voltages are supplied by the computer or optional printer." I asked for more info which they will mail me, but in the meantime wanted to point out the dongle is not yet dead. Anyone already know more details? From: mwn@mike.ufnet.ufl.edu (Michael Nora) 14-SEP-1989 14:59:02 To: misc-security@ufl.edu Subj: [1189] Re: traps >He got fed up and wired the place with wall current. >Someone came in and fell into his trap and was electrocuted. You may be refering to what happened in the Overtown section of Miami a few years ago. I can't remember the store owner's name, but what happened was that people were breaking into his store through a hole in the roof. He placed a section of chain-link fence across the hole but a few feet below it, so if a person was to enter the hole he would be almost entirely inside before he made contact. This he hooked up to the AC in his store. Sure enough, someone did enter and was electrocuted by the device. I remember there being a big debate in the Miami area over the actions of this man, with most people siding WITH him. When it finally did come before the grand jury, they refused to indict the store owner for murder, and he was convicted of a much lesser charge (like an illegal security device or something . . ) and as far as I know he is still in business. device. -- Michael Nora | Internet: mwn@mike.ufnet.ufl.edu University of Florida | UUCP: uhmmm .. beats the hell outa me ??? Data & Video Network | MaBellNet: (904) 335-8312 {or 8300} From: az@angate.att.com (Zigmas J Astravas) 15-SEP-1989 13:12:52 To: misc-security@att.att.com Subj: [2025] AT&T_Alarms In response to many inquiries about BURGLAR ALARMS, AT&T has entered this market with their new WIRELESS SYSTEM (AT&T SECURITY SYSTEM 8000). CASTLE ALARMS PLUS, INC is the AT&T Authorized Dealer in the Southern New Hampshire area. They can be reached at (603) 898-9851 or (800) CAP-2580 outside NH. Over the past few years, I have built my own house and had an excellent alarm system wired into it for BURGLAR, FIRE, and SMOKE protection. In the course of building my own home, I researched every type of home security system on the market. These included all the features imaginable (Passive Infra-Red motion detectors, microwave motion detectors, shock detectors for pre-entry warning, pressure sensitive mats, smoke alarms (photoelectric and ionization), magnetic contact switches for doors and windows, delayed entry features, medical alert, digital communicators for automatically dialing authorities, etc....) However, the new WIRELESS SYSTEMS on the market today have all of the same features as the above wired systems, AND MORE! A WIRELESS ALARM SYSTEM has the added benefit that the entire system can be taken with you, should you decide to move. In fact, the AT&T WIRELESS SYSTEM (AT&T SECURITY SYSTEM 8000) utilizes the latest RF technology extending it beyond the capabilities of wired systems and has features OVER AND ABOVE other wireless systems. This modular system can incorporate BURGLAR, FIRE, SMOKE, MEDICAL, and ENVIRONMENTAL protection. CASTLE ALARMS PLUS, INC is the AT&T Authorized Dealer in the area. They can be reached at (603) 898-9851 or (800) CAP-2580 outside NH. They come highly recommended and can engineer a system that's tailored to your needs, at a very REASONABLE PRICE and RELIABLE SERVICE with your interests in mind. They may even offer financing and I heard they may offer a discount to AT&T employees or free Alarm Monitoring for the first year (about a $240 value)! I hope this information helps you "make the right choice". From: krvw@sei.cmu.edu (Kenneth Van Wyk) 15-SEP-1989 13:48:27 To: misc-security@rutgers.edu Subj: [4369] CERT Internet Security Advisory Many computers connected to the Internet have recently experienced unauthorized system activity. Investigation shows that the activity has occurred for several months and is spreading. Several UNIX computers have had their "telnet" programs illicitly replaced with versions of "telnet" which log outgoing login sessions (including usernames and passwords to remote systems). It appears that access has been gained to many of the machines which have appeared in some of these session logs. (As a first step, frequent telnet users should change their passwords immediately.) While there is no cause for panic, there are a number of things that system administrators can do to detect whether the security on their machines has been compromised using this approach and to tighten security on their systems where necessary. At a minimum, all UNIX site administrators should do the following: o Test telnet for unauthorized changes by using the UNIX "strings" command to search for path/filenames of possible log files. Affected sites have noticed that their telnet programs were logging information in user accounts under directory names such as "..." and ".mail". In general, we suggest that site administrators be attentive to configuration management issues. These include the following: o Test authenticity of critical programs - Any program with access to the network (e.g., the TCP/IP suite) or with access to usernames and passwords should be periodically tested for unauthorized changes. Such a test can be done by comparing checksums of on-line copies of these programs to checksums of original copies. (Checksums can be calculated with the UNIX "sum" command.) Alternatively, these programs can be periodically reloaded from original tapes. o Privileged programs - Programs that grant privileges to users (e.g., setuid root programs/shells in UNIX) can be exploited to gain unrestricted access to systems. System administrators should watch for such programs being placed in places such as /tmp and /usr/tmp (on UNIX systems). A common malicious practice is to place a setuid shell (sh or csh) in the /tmp directory, thus creating a "back door" whereby any user can gain privileged system access. o Monitor system logs - System access logs should be periodically scanned (e.g., via UNIX "last" command) for suspicious or unlikely system activity. o Terminal servers - Terminal servers with unrestricted network access (that is, terminal servers which allow users to connect to and from any system on the Internet) are frequently used to camouflage network connections, making it difficult to track unauthorized activity. Most popular terminal servers can be configured to restrict network access to and from local hosts. o Passwords - Guest accounts and accounts with trivial passwords (e.g., username=password, password=none) are common targets. System administrators should make sure that all accounts are password protected and encourage users to use acceptable passwords as well as to change their passwords periodically, as a general practice. For more information on passwords, see Federal Information Processing Standard Publication (FIPS PUB) 112, available from the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. o Anonymous file transfer - Unrestricted file transfer access to a system can be exploited to obtain sensitive files such as the UNIX /etc/passwd file. If used, TFTP (Trivial File Transfer Protocol - which requires no username/password authentication) should always be configured to run as a non-privileged user and "chroot" to a file structure where the remote user cannot transfer the system /etc/passwd file. Anonymous FTP, too, should not allow the remote user to access this file, or any other critical system file. Configuring these facilities to "chroot" limits file access to a localized directory structure. o Apply fixes - Many of the old "holes" in UNIX have been closed. Check with your vendor and install all of the latest fixes. If system administrators do discover any unauthorized system activity, they are urged to contact the Computer Emergency Response Team (CERT). Kenneth R. van Wyk Computer Emergency Response Team cert@SEI.CMU.EDU (412) 268-7090 (24 hour hotline) From: chet@retix.retix.com (Chet Mazur) 26-SEP-1989 18:43:19 To: misc-security@rutgers.edu Subj: [203] Re: pc encryph - the whole directory You might want to check out WatchDog P.C. Security System by Fischer (sp?) Intl. someplace in Florida... It's a neat package and they have excellent technical support!!! Try it.... You'll like it :)!!! From: pnet01!pro_realm!namerow@uunet.uu.net (Wayne Namerow) 27-SEP-1989 9:09:34 To: security@pyrite.rutgers.edu Subj: [636] Home booby traps One has to be VERY careful when considering booby traps (for burglers etc.) as mentioned in an earlier submission. For example, if your house dispensed tear gas to stop burglers, you might be in BIG trouble if you had a fire. Imagine the fire depts. surprise as they entered your home to extinguish the blaze and got doused by tear gas ! Your home certainly would not be high on their priority list for future calls. -Wayne ProLine:namerow@pro-realm BITNET:namerow%pro-realm.cts.com@nosc.mil UUCP:crash!pnet01!pro-realm!namerow ARPA:crash!pnet01!pro-realm!namerow@nosc.mil From: kodak!ektools!john (John H. Hall) 27-SEP-1989 10:13:19 To: misc-security@rutgers.edu Subj: [2197] Home Security Systems I am thinking about making some security-related improvements to my home. After putting deadbolts and strike reinforcements on the front and back doors, I'm wondering what to do about the windows. This is a 1955 ranch house with awning and casement type windows. They are all "manual", that is they don't have geared "operators", you just turn the latch and push to open them. Similarly, a burglar just breaks the glass, turns the latch and pulls. We close all the windows when we go to work, but I think we may be going to get an alarm system, too. What's a good book on do-it-yourself home security systems? What are the trade-offs of do-it-yourself vs. a professional security company? How do I protect my home without overtly annoying the neighbors, police, etc. with false alarms. Radio Shack sells "glass breakage detectors". These are ~1" diameter "pucks" that stick to the glass and are wired to an alarm. * What do these sense? * If they are in the corner of a picture window, and the other side of the window is broken but the glass under the puck remains intact will they trigger? * If they are impact-sensitive, will a truck or plane rumbling by set them off? How about area detectors, infra-red or sonic? We have no pets to set them off but: * Can IR detectors see movement through windows? Wouldn't want the paper boy setting them off by mistake. * How about changes in ambient IR levels caused by the sun coming in through a window or the furnace going on or off? * Are the sonic types sensitive to noises outside the house? * Will, say, thunder shake the house enough to trigger a motion detector? I see both wired and wireless alarm systems for sale. Since I have good attic and basement access, I am tending toward the wired sort. The wireless types seem to need occasional battery replacement. Aside from this are there reliability concerns wrt. either style? -- ------------------------------------------------------------------------- John Hall, Product Software Engineering, Software Systems Division EASTMAN KODAK COMPANY, 901 Elmgrove Rd., Rochester, NY 14650 716 726-9345 / john@kodak.COM / ...!rutgers!rochester!kodak!ektools!john From: *Hobbit* 27-SEP-1989 10:59:26 To: security@pyrite.rutgers.edu Subj: [2729] Ving Cards There used to be only one kind of Ving card lock. Now there are two kinds, as I discovered to my horror a while back while at a convention. The first and possibly "classic" version is all-mechanical, while the second is optical with an electronic controller. I did a longish article on the mechanical one back when I got to take it apart, which I will send to anyone who asks, and since the time of that writing discovered a few more things about it. I believe this article was sent to this very list years ago... My examination of the optical type occurred much more recently, and there are still several things I don't know about it -- in particular how master-keying is handled in software, since the pin-tumbler cylinder in this type appears primarily to be for programming. This lock uses the same technology as the Yaletronics and its ilk; the matrix of holes is simply read by a bunch of infrared LED/sensor pairs connected to the inputs of a small processor. You feed it the right number, it pulls the solenoid. There is no mechanical connection from the pin cylinder to the spring-latch mechanism, so I'm clueless as to what people do if the batteries die on them. Even with plenty of advance battery-low warning, you'd think there would be a mechanical bypass available... You can quickly tell which type you have by the noises it makes. The mechanical version produces all kinds of racket as the card slides over the ball-bearings; the optical presents no mechanical impediment to the card save the little spring-loaded protective bar at the opening. The mechanicals have a "combination card" loaded into them through the hinged black cover on the inside of the door, which is sometimes difficult to install and remove due to the way the pins sit inside the matrix. The pin-tumbler cylinders are made in-house by Ving, and sport a rather unique feature. About 30 degrees clockwise from the normal drivers there is a set of "extra" drivers which are retained up in the cylinder housing. All they appear to be for is to store extra mastering splits you aren't using in the regular lock. Thus to change between several known keys, one would turn key A over to this position, remove it and insert key B, and return it to the locked position. The difference between keys A and B causes splits to be left at or picked up from the spare driver area. They also have the magic- rear-pin-ring dealbolt hack commonly found in hotel systems. The last address I had for the makers of these things, if you want the corporate party line, is Elkem Ving 6200 Denton Dr Dallas TX 800 527 5121 If someone tries the above and it's horribly wrong, please let me know, since all of this was several years ago. _H* From: Lee SuBok 28-SEP-1989 5:06:03 To: Subj: [163] [161] Return-path: Date: MON, 4 SEP 1989 15:39 EXP From: Lee SuBok To: Recently I am seeking for papers on Computer Crime and its criminal investigation. Would you send me any pointers to papers and books on it? Thanks in advance. From: bywater!arnor!margoli@uunet.uu.net (Larry Margolis) 28-SEP-1989 5:43:45 To: misc-security@uunet.uu.net Subj: [628] Re: bike locks One other thing to check is that if you're locking to a sign post, there's a sign at the top of the post. I know people who've come back to find that someone apparently just threw the bike over the top of the pole, then walked away with the bike, lock and all. Whatever you're locking to, make sure it's firmly mounted in the ground. You mentioned Cobra locks. Does anyone have any familiarity with them? A friend gave me one he found, but I haven't had too much luck picking it. Do they use any kind of pick-resistant pins, or an I just rusty on Ace-type locks? Also, is there a pin I can drill to remove the cylinder? From: wjvax!mario@pyramid.com (Mario Dona) 28-SEP-1989 6:17:17 To: misc-security@decwrl.dec.com Subj: [1078] need advice on secure PS/2 I'm looking for some advice on setting up a PS/2 Model 70 for doing government classified work. The primary requirement is that the magnetic media be removable. I'd like to go with a Passport made by Plus, but its housing doesn't fit in the Model 70, which forces us to use an external chassis. Another problem is the fixed disk in the Model 70 cannot be active (turned on) while working on classified material. Before we got our PS/2's, we used ATs which we modified by installing a toggle switch on the back panel. This switch allowed us to turn off the power to the hard drive and boot off a Bernoulli. We would like something similar to this setup for the PS/2 70. If anyone has already solved these and related problems, I'd appreciate any advice you can give. BTW, I understand IBM won't give out their schematic of their PS/2's, so that we can't readily locate any of the power leads into the hard drive. Mario Dona ...!{ !decwrl!qubix, ames!oliveb!tymix, pyramid}!wjvax!mario The above opinions are mine alone and not, in any way, those of WJ. From: fec@whuts.att.com (F E Carey) 29-SEP-1989 4:02:51 To: misc-security@att.att.com Subj: [411] Surveillance Expo '89 A while back somebody requested info on surveillance. Today's mail brought the announcement of Surveillance Expo '89 - conference and exhibits - Dec 12 - 15 1989, Sheraton Washington Hotel, Wash. D.C. The mailing was from Ross Engineering in Adamstown MD 301/831-8400 They are in the surveillance business and are promoting a video tape and also appear to run a newsletter. Check 'em out - whoever you were. From: dave@ariel.unm.edu (Dave 'White Water' Grisham) 29-SEP-1989 4:17:59 To: misc-security@uunet.uu.net Subj: [827] Re: Requesting Information on Security Policies For those of you wishing to see what other universities are/have done, please use the archives here. I maintain an 'ethics' col- lection here at UNM from the world's universities. All entries have been submitted for posting by different universities and authors. You may email or postal mail me your submissions to the collection. And you may obtain any policy by 'anonymous' ftp to unma.unm.edu, the directory is ethics. The index is 00.INDEX. I hope this helps. And yes, I will have it LISTSERV available soon. dave Dave Grisham Senior Staff Consultant/Virus Security Phone (505) 277-8148 Computer & Information Resources & Technology USENET DAVE@unma.unm.EDU Univ. of New Mexico Albuquerque, NM 87131 BITNET DAVE@UNMB From: Yian Chang 1-OCT-1989 0:15:22 To: security@pyrite.rutgers.edu Subj: [355] Questions about DES Can anybody tell me how the encryption parameters of DES (like transposition and substitution arrays) were choosen ? And why the DES encryption programs can't be exported to the outside of USA ? I mean DES is a well known encrypt algorithms, everybody can write such programs. -- Yian Chang [Moderator tack-on: Replies/comments to sci.crypt, please.] From: boerner@emx.utexas.edu (Brendan B. Boerner) 1-OCT-1989 1:01:50 To: jimkirk@outlaw.uwyo.edu Subj: [1074] Dongles are still alive Cc: security@pyrite.rutgers.edu >there was a company called Rainbow >Technologies showing off their "Software Sentinel" I am using this device for a program which I am writing for a client (at his request). It was not that hard to interface to the code I was writing in Turbo Pascal v5.0 and the manual states that it supports other languages/operating systems. The only problem I had was that I was using an older version of the product and as a result was initializing it incorrectly. After a quick call to their tech support I got it cleared up. Disclaimer: The project I am working on which uses this device is in no way related to my work at the University of Texas at Austin. I'm just using this account to pass along the info which I obtained from outside work. If you have more questions, drop me a line and I'll try to answer. Brendan -- Brendan B. Boerner Phone: 512/471-3241 Microcomputer Technologies The University of Texas @ Austin Internet: boerner@emx.utexas.edu UUCP: ...!cs.utexas.edu!ut-emx!boerner BITNET: CCGB001@UTXVM.BITNET AppleLink: boerner@emx.utexas.edu@DASNET# From: "Michael J. Chinni, SMCAR_CCS_E" 1-OCT-1989 1:48:40 To: David Stodolsky Subj: [1016] Re: Personal Health Security System Cc: misc-security@dkuug.dk David, >The objective of the research is to develop a Personal Health Security >System. You mention that the emphasis is to allow a person to control their own records. What is to prevent the following situation: Person is told they have AIDS and this is entered into the records on the card. Person then deletes this AIDS info. from their card. VOILA! No more record of their AIDS infection. Given your explantion so far, I do think that this can be done. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Michael J. Chinni Chief Scientist, Simulation Techniques and Workplace Automation Team US Army Armament Research, Development, and Engineering Center User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey and dust covered workstation () ARPA: mchinni@pica.army.mil "System been down long?" () UUCP: ...!uunet!pica.army.mil!mchinni /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From: ishikawa@ultra.enet.dec.com (Jim Ishikawa, DTN_293_5054) 1-OCT-1989 2:33:11 To: "security@pyrite.rutgers.edu"@decwrl.dec.com Subj: [1546] RE: Encryption hardware/software available? >The DEC encryption approach was described to me to have 2 significant defects: >1. You have to have a VAX to use it. While it is true that the security management software (VAX KDC) will only run on a VAX system, only *one* VAX system is required on a network. Furthermore, VAX KDC software will run on any VAX, including small ones like the MicroVAX 3100. Digital's Ethernet Enhanced-Security System product set actually comprises two separate products. In addition to the VAX KDC software, there is the DESNC secure network controller. The DESNC controllers are freestanding devices that provide a secure network interface for client nodes. Client nodes may be any device that complies with Ethernet or IEEE 802.3 standards. The network security manager uses one or more VAX KDC systems to manage the DESNC controllers and their associated client nodes on a network. >2. Too much of the packet is encrypted, such that the packets can only pass > thru bridges, and not routers. It is true that DESNC encryption is done at the data-link layer, and as such, encrypted packets can only be forwarded through routers after first decrypting them. Of course, this means that DESNC controllers will support vendor-independent, multiprotocol environments. Network-layer encryption schemes, which allow packets to be forwarded through routers without decryption, are generally restricted to a single network-layer protocol and typically do not support other protocols that run directly on the data-link layer protocol. Jim Ishikawa DEC From: Paul=Zonfrillo%SQA%Banyan@thing.banyan.com 4-OCT-1989 22:17:37 To: SECURITY@vm.tcs.tulane.edu Subj: [879] re: Dongles are still alive Yes indeed, Dongles are alive and well! My company, Banyan Systems Inc. makes PC-based WAN/LAN software and uses such a device for copy protection as well as and upgrade. Our "server key" is a straight-thru device that sits on the pralell port. Users can also purchase additional "option keys" to enable additional operating systems options such as TCIP routing, that can be loaded on/off the server via these option keys . As far as reliability goes, in six years, we have NEVER had one burn out. (this is according to tech support). Our software encodes to the key after it has been loaded on the server. The option is also attractive because it does not take up any slots in the server. In short: Dongles seem to be an effective but unobtrusive form of copy protection. Paul Zonfrillo SQA Engineer, Banyan Systems Inc. Paul=Zonfrillo%SQA%BANYAN@thing.banyan.com From: barry@ads.com 4-OCT-1989 23:12:18 To: security@ucbvax.berkeley.edu Subj: [1288] Internet cracker on the loose. There is a cracker on the loose in the internet. This is the information I have so far. Traces of the cracker were found at the Institute for Advanced Studies in Princeton. He also left traces at one of the Super computer centers. Both CERT and the FBI have been called. The technique that is being used is as follows: 1) He has a modified telnet that tries a list passwords on accounts. Username forwards and backwards, username + pw, etc. 2) He seems to have a program call "ret", that is breaking into root. 3) He seems to be getting a list of victim machines via people's .rhosts files. 4) He copies password files to the machines that he is currently working from. 5) He is good about cleaning up after himself. He zeros out log files and other traces of himself. 6) The breakins are occurring bwtween 10pm Sunday night and 8am Monday morning. 7) He seems to bring along a text file of security holes to the machines he breaks into. 8) Backtracing the network connections seem to point to the Boston area as a base of operations. The sys admin at IAS found a directory with the name ".. " (dot dot space space). The files I mentioned above were found in this directory. Barry Lustig barry@ads.com Advanced Decision Systems (415) 960-7300 From: ORG5NMC@cms1.ucs.leeds.ac.uk 5-OCT-1989 16:05:31 To: SECURITY@pyrite.rutgers.edu Subj: [773] [771] Return-path: Date: Wed, 23 Aug 89 17:13:11 BST From: ORG5NMC@cms1.ucs.leeds.ac.uk To: SECURITY@pyrite.rutgers.edu > Why is there so little awareness of the way many third-party software > packages open vulnerabilities in even the perfectly managed C2 > commercial systems? I don't think its just a matter of third party software being poor security-wise. The vendor of the machines I work on (not IBM) seems to have a very poor record (security-wise) when it comes to their own "add on" s/w let alone third party. I see time after time new features introducing old bugs. On another subject (slightly related) what do readers think vendors should do to deter the writing of "home-grown" poorly written privileged s/w that effectively opens up systems? Is it just a matter of education or trying to make it difficult for s/w to make mistakes? Neill. From: Gary Buhrmaster 5-OCT-1989 16:35:00 To: security@ubvm Subj: [1165] [1163] Return-path: Date: Wed, 23 Aug 89 16:27:45 EDT From: Gary Buhrmaster To: security@ubvm In the IBM world, a promise to run 15% faster than the competition usually makes the sale to the DP manager. That manager is rarely concerned that the package happens to run faster because it runs the users in privleged mode, and the saleman is unlikely to volunteer that information. His competitor might, but he probably has his own hooks for some other function that he would prefer you not notice. It is getting better. While still a rare occurance, DP managers are learning to ask what special facilities or privleged functions that packages require, and then require that the package support the underlying security facilities. In the MVS world, that often means some sort of statement of integrity, and interface to RACF or ACF2. The driving force is often the EDP Auditor. While they may not understand computers (it is not their job,) they do exchange information between themselves as to what packages are the biggest abusers, and they do know the right questions to ask. After all, their interest is in understanding the risk of losing their companies assets, and programs that allow access to those assets without authorization are dangerous. From: Chess Ferrier 5-OCT-1989 16:50:03 To: misc-security@ukc.ac.uk Subj: [1499] REINIALISING PS/2 PASSWORDS HOW CAN A PS/2 PASSWORD BE REINITIALISED ? You use the REFERENCE DISK to set a PS/2 PASSWORD for the first time. You use OLDPW/NEWPW to change the current PASSWORD. But how do you re-invoke the password facility for the following situation: 1 The password had been set. 2 The password was removed by entering a blank value as a new password. (OLDPW/ ) You can no longer set the password via the REFERENCE DISK as it reports that the password is already set. You can not change the password from 'blank' to something else via the normal 'CHANGE PASSWORD' process as you are no longer required to enter a password when the system is turned on. The only way I know to over come this situation is to remove the PS/2's battery for about 20 minutes, and then rerun the system automatic configuration, and the REFERENCE DISK's SET PASSWORD facility. The above method is a real pain. I'm hoping that there is another way. Is there another way ? P.S. - Is there a way to find out the current power-on password value. Thanks in advance for any help. ---------------------------------------------------------------------------- Mr Chess Ferrier ESSO ENGINEERING (EUROPE) LIMITED. Apex Tower, High Street, New Malden, Surrey, KT3 4DJ. 01-949-8459 ----------------------------------------------------------------------------- -- Automatic Disclaimer: The views expressed above are those of the author alone and may not represent the views of the IBM PC User Group. From: feo@cbnewsl.ATT.COM (francis.e.o brien) 5-OCT-1989 22:20:16 To: misc-security@att.att.com Subj: [496] Home Alarms I'm interested in installing my own home security system. My house is mostly pre-wired, which makes the installation of a wired system relatively simple. The only problem is finding systems. So far the choice is Radio Shack. I haven't located any other distributors of alarm systems who sell to the general public. Most places insist on installaing and of course providing a monitoring service. Can anyone provide me with the name of some dealers that I can deal with directly? Thanks. From: jearly@lehi3b15.csee.lehigh.edu (John Early) 5-OCT-1989 22:52:42 To: misc-security@rutgers.edu Subj: [2441] Re: Home Security Systems >What's a good book on do-it-yourself home security systems? If you find one, let me know, too. If you do-it-yourself, it is cheaper and more secure(only you know the details of your system) but you might not think of everthing the pro's might. Personally, I don't let ANYBODY know the details of the systems I install, and I would not trust ANY company that doesn't have a good rep. >How do I protect my home without overtly annoying the neighbors, police, >etc. with false alarms. Don't have false alarms--seriously, they ARE annoying, and unless the only function an alarm system does is call YOUR phone, you will annoy someone. Some police dept. don't mind having auto-dialers call them, some do...check with the local and/or state police. >Radio Shack sells "glass breakage detectors". These are ~1" diameter >"pucks" that stick to the glass and are wired to an alarm. >* What do these sense? They are mercury switches (can be set to be normal open or closed) and change state when tilted more than a certain (preset) degree. If someone can break (or cut) just part of a window, they won't sense it. They are most sensitive to rotational motion around the center axis, so I did one installation where the window loop is always active, but the windows can be opened or closed without triggering the sensor...and trucks won't set them off. Do your best to hide them so that a potential intruder won't notice them and take precationary steps. >How about area detectors, infra-red or sonic? We have no pets to set >them off but: Some IR detectors are sensitive enough to measure through glass...most aren't. Sunlight WILL set them off...seen that happen more than once. Ultrasonic motion detectors shouldn't detect noise, per se, but if the thuder knocks a book off a shelf (had that happen to me once) it will. >I see both wired and wireless alarm systems for sale. I always use closed loop wired systems. And redundant systems in special areas. Don't forget to check back-up batteries at least 1/month! I think that any DIY can manage a good security system, if s/he thinks it out ahead of time, and tries to think like an intruder. Pay attention to small details--e.g. don't install an auto-dialer then forget to protet your phone wire entrance. Radio shack has good stuff...probably enough for the average home security needs. Hope this helps. John Early jearly@lehi3b15.csee.lehigh.edu JPE1@Lehigh.Bitnet From: letni!doug@texbell.swbt.com (Doug Davis) 5-OCT-1989 23:21:14 To: misc-security@attctc.dallas.tx.us Subj: [2684] Re: Home Security Systems >* What do these sense? These are mercury filled switches which you can set the "sensitivity" by providing the inital tilt of the switch. I use them in my car for things like tee-tops. (substatute velcro for the double stick tape) and they work reall well. For glass breakage they are only moderate I would suggest them only if tape is to obnoxious and you can't affored the "real ones" based off of piezo elements. >* Can IR detectors see movement through windows? No, not unless they were paper thin, Ultra sonics can't even see thru that. >* How about changes in ambient IR levels caused by the sun coming in >through a window or the furnace going on or off? Usually two slow in both cases, I once walked across a room that was protected via IR detectors, it took half an hour to cross 20 feet, but I won the bet. I suspect sonics are foolable in a similer fashion, but *I* can't do it. >* Are the sonic types sensitive to noises outside the house? Not unless its very very loud and in their detection range. >* Will, say, thunder shake the house enough to trigger a motion detector? I use both and we have lots and lots of thunder storms, the shaking of the house has never set them off.. Books falling from the shelf across the room will though. IR detectors love heating element furnaces, and steam radiators, generally anything that changes temperature quickly will set them off. Ultrasonic detectors love ceiling fans, and air vents (if they are set too sensitive) >I see both wired and wireless alarm systems for sale. Yeas, most wireless "broadcast" somehow, and like any RF signal it is subject to distortion caused by outside interference. Also someone else my have an alarm system using the same codes and/or frequencys that could cause yours to appear to false alarm. While wired alarms are subject to "rodent abuse." Like when the squirrel that has made your attic its home desides to "borrow" a chunk of alarm wire for its nest. Wired is by far more reliable, and more work ;-) Think closed loop, that *IS* the way to go, also the more loops the better, that way you can still have a partial alarm system when a loop goes out.. Thats not good, but it's thousands of times better than not having an alarm. Look real carefully at off the shelf "base units" most of them are low grade trash, generally in this area you get what you pay for. doug -- Doug Davis/1030 Pleasant Valley Lane/Arlington/Texas/76015/817-467-3740 {sys1.tandy.com, motown!sys1, uiucuxc!sys1 lawnet, attctc, texbell} letni!doug "Everything in this article is a Jolt Cola hallucination and in no way exhibits any signs of being remotely connection to any reality." From: simsong@prose.cambridge.ma.us (Simson L. Garfinkel) 5-OCT-1989 23:48:32 To: security@rutgers.edu Subj: [3550] home security I am in the process of installing a rather sophisticated security and access control system in my home. Deadbolts and strike reinforcement are a good first step, but the reality is that if somebody kicks hard enough, they will probably just take the frame out of the wall, unless you have a steel frame around a steel door. It's really not worthwhile to go to that trouble, though, because people will just come through the windows unless you have bars or security screens on them. If your goal is to keep somebody out physically, you will probably have to turn your house into a fortress. What's a good book on do-it-yourself home security systems? _The_Truth_About_Self_Defence_, available from the Police bookshelf, 603-224-6814, 800-624-9049. What are the trade-offs of do-it-yourself vs. a professional security company? Assuming you want central office monitoring, it is generally easier to get hooked up with a professional system. Most systems cost in the $1K-$2K price range, and they do a very good job, so unless you have done this stuff a lot, you are probably better off with something professional. It's also a question of how much you value your time, how close what you want is to what is available off-the-shelf, and wether or not you want to use a radio-controlled system. How do I protect my home without overtly annoying the neighbors, police, etc. with false alarms. Don't have false alarms. They are typically caused by friends setting the system off, wind blowing doors open, auto-headlights setting off IR detectors, and things like that. Radio Shack sells "glass breakage detectors". These are ~1" diameter "pucks" that stick to the glass and are wired to an alarm. * What do these sense? Vibration. Other units can actually detect the sound of breaking glass. * If the other side of the window is broken but the glass under the puck remains intact will they trigger? Yes. * If they are impact-sensitive, will a truck or plane rumbling by set them off? Only if it breaks the glass. * Can IR detectors see movement through windows? Wouldn't want the paper boy setting them off by mistake. Not unless you have windows made out of NaCl. Salt windows are typically only found in laboratories, in circles of 1", for IR spectroscopy. * How about changes in ambient IR levels caused by the sun coming in through a window or the furnace going on or off? Depends on the detector. Some of the newer detectors will only trigger if two or three beams are broken in succession, and these tend not to go off with slow changes in temperature. * Are the sonic types sensitive to noises outside the house? Ultrasonic detectors are generally not used anymore, since they are very susceptable to background things that make ultrasonics (like pipes). * Will, say, thunder shake the house enough to trigger a motion detector? Not of you have an IR detector, since they detect moving heat sources, rather than just movement. I see both wired and wireless alarm systems for sale. Wireless systems scare me, because of the potential for jamming. With wireless systems, there is a version which is called supervised wireless, in which the central station constantly polls the remotes and asks them if they are still working, and gives you an alarm when they fail. The more expensive ones will even send out messages when their batteries start to go. On the other hand, you can move a wireless system if you do. And they are much cheaper to install. From: GREENY 6-OCT-1989 0:20:11 To: Subj: [4241] re: Alarm systems > IR Detectors... What do these detect? They detect infrared energy in the area....a fresnel lens directs any and all infrared onto a pyrodetector, and some electronics determine whether or not it should be classified as an alarm or not....usually this is done via "Pulse counting" which is a method whereby the detector counts the number of pulses of energy that it has detected within a certain period of time (usually a{ 2-3 second period...)....At the security system which I consult for, we set this to TWO...makes for a good trade off between preventing false alarms due to air vents moving plants, and the ability to detect a person...NO they will not detect through the glass....although a good shot of sunlight right into the lens of the detector will trigger it....simple solution -- keep the drapes drawn... Glass breakage sensors -- what do these detect? There are two types: Ones which "listen" for the frequencies of breaking glass (audio discrimination) and the usual ones which sense low-level vibrations such as would be caused by someone attempting to pry open the windows... The Radio Shack ones work via mercury type switches that when shaken enough close a contact and trigger the alarm....they are not tooo reliable...The ones at the security company I consult for use Terminus sensors, and run them into a "processor" that makes heads or tails out of the signals comming from the detectors on the windows....Otherwise thunder and rumbling trucks would set them off all the time... My personal favorite is a sensor known as the "ShatterBox" by Sentrol which is an audio discriminator....of course if you have these armed at night and then break a glass, you will set off the alarm... My personal recommendation is to go with a system from a professional company because there is a lot of grunt work involved in fishing all the wires for a hardwired system (wireless systems are good, but another topic altogether..) and in choosing the best protection for your home. Also, if anything goes wrong, they get to fix it, and you wont have to listen to the wife (if you're married) saying "I told you it should have been done by a company! *whine*". Furthermore, they can and should be able to hook you up to a central monitoring station for a nominal fee (we charge $21.50/month) which will provide you with some neat features. 1) Assuming your phone lines dont get cut, then when the alarm goes off, it will send a packet of data via digital communicator to the central station over your phone line (it seizes the line even if someone is on the phone or it is off the hook) and tells them what zone got triggered....2) they call you back unless it's a panic zone and ask for a password....3) if you provide the correct one they dont send the police/fire dept/paramedics....4) if not, then they do... 5) if you arent there, they call a list of valid "keyholders" and tell them the alarm went off, and call the cops/fire dept/ambulance....6) you can have other sensors such as high/low temperature sensors, sump pump failure (flood) sensors, etc...wireless panic buttons (even with a hard wired system) and a variety of other goodies... Also, if the company you choose is up on things, then they will use recessed magnetic contacts that you will never see on the doors/windows...about the only thing you will see is the smoke detectors if you have fire coverage, and the shock sensors on the doors/windows (although these are practically invisible...), the control keypad(s) in the designated area, and the alarm CPU in the basement/closet of your home.... The CPU should have a battery backup, and recharge automatically. Stay away from the Radio Shack system, it uses lots of C or D cells and they are a pain...also, no digital communication is available, and they only offer their tape dialer which many police stations hate...also the panel is not zoned, which makes servicing a complete bear... More questions? Drop me some E-mail...I'm experiencing hard drive problems right now so I'm not on every day like I used to be, but I am here about 3 times a week... Bye for now but not for long... Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU GEnie: GREENY Macnet: GREENY