|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1990)
DOCUMENT: Rutgers 'Security List' for July 1990 (62 messages, 38366 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/07.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- From: antonyc@chamber.cco.caltech.edu (Bill T. Cat) 3-JUL-1990 20:21:28 To: security@rutgers.edu
but as the number of masters increases, so does the ease of picking the lock
-----------[000001][next][prev][last][first]---------------------------------------------------- From: kuras@josef.enet.dec.com 3-JUL-1990 21:00:26 To: misc-security@decwrl.dec.com
The dates of the workshop are August 27 & 28, 1990. Sorry, I don't have location or other particulars at this time, other than it's in Portland, Oregon. The organizer of the workshop is Matt Bishop, Dept of Mathematics & Computer Science, Bradley Hall, Dartmouth College, Hanover, NH 03755 (603) 646-2415
-----------[000002][next][prev][last][first]---------------------------------------------------- From: optilink!cramer@uunet.uu.net (Clayton Cramer) 3-JUL-1990 21:37:46 To: misc-security@uunet.uu.net
There's a much more low-tech version of this scam, that worked
successfully in Culver City, CA, a few years ago.
There was a bank heavily used by merchants in Fox Hills Mall. Of
course, merchants usually make night deposits filled with cash and
coin. A sign was placed on the night deposit box that said, "Out
of order". An armed security guard, in uniform, stood next to it,
with a large wooden box.
Yup! You guessed it! Few merchants questioned it -- they just
dropped their night deposits in the box. The next day at the
bank must have been pandemonium. "There's nothing wrong with our
night deposit box. What guard?"
--
Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer
Amtrak subsidies: adults playing with choo-choos.
----------------------------------------------------------------------------
Disclaimer? You must be kidding! No company would hold opinions like mine!
-----------[000003][next][prev][last][first]---------------------------------------------------- From: jearly@lehi3b15.csee.lehigh.edu (John Early) 3-JUL-1990 22:14:21 To: misc-security@rutgers.edu
The CC and CSEE here at Lehigh are going to set up a Sun SPACRstation *public* site (hopefully in time for the fall semester) and I'm trying to find out what is available as far as physical security systems. All we really need to do is bolt the CPU and monitor down (we will have both the 16 inch color and the 19 inch mono) and cable the keyboard and mouse to the CPU. (The optical mouse will be interesting...while there is no ball for people to steal the pad will certainly walk if not glued down, yet if I glue it down our left-handed users are screwed--and don't ask me to ask for money to buy two per station.) So if anybody knows of any systems for Suns please e-mail me. If people want I can let you know how things work out in the fall. Thanks, John. ---------------------------------------- John Early | jearly@lehi3b15.csee.lehigh.edu | I was just a child then; JPE1@Lehigh.Bitnet | now I'm only a man. [pf] LUJPE@VAX1.cc.lehigh.edu |
-----------[000004][next][prev][last][first]---------------------------------------------------- From: *Hobbit* <hobbit@pyrite.rutgers.edu> 3-JUL-1990 22:54:58 To: security
It would be REALLY GREAT if makers of "real" locks made drop-in replacements for car doors, complete with reinforcing plates and good pin cylinders and a mechanism that works such that once you turn the key a certain way the little lever is locked toward one direction and won't move at all. This would prevent use of a slim-jim. Unfortunately for the kind of car-door latch that doesn't work when the lock is locked, it could also trap people inside the car. Given that one would have to explicitly lock the door from the outside with such a rig, I think that I'd personally rather have that small risk than what, for instance, I have now, which is a car that's frighteningly easy to break into. I recently tore my door apart to investigate the possibility of doing this. The cylinder has a limit stop which prevents motion much more than 60 degrees either way from center, and this stop is somewhere underneath the stupid press-fit front bezel, which if bent apart and then back again will probably be rather weakened. So for the moment I've given up on the idea of redoing it so it could be turned 180 degrees and then the key pulled. If someone knows of a type of car cylinder whose limit stops are on the *back*, where I could get at them and file them down, please holler, and I could go off to a junkyard and find that kind of car. Yes, even with all that glass sitting there saying "break me", I still want to do this just for hack value. _H*
-----------[000005][next][prev][last][first]---------------------------------------------------- From: Doug Gwyn <gwyn@smoke.brl.mil> 3-JUL-1990 23:16:41 To: misc-security@rutgers.edu
>... The two of us who confronted them were threatened with instant >expulsion if we were ever caught USING such knowledge; we didn't tell >them about the others... That seems to be fairly typical of administrations. Lock hackers can be quite concerned about perceived weaknesses in the institution's security systems, but the administration often prefers to act on the principle that knowledge is bliss, rather than tackling the objectively significant problem. Anyway, one generally meets with the sort of response that you reported, when trying to bring the attention of the authorities to a real problem. That's one of the reasons that vigilantes come into existence. At Rice, I sat in on SDS meetings just to keep an eye on the radicals, and when they planned to blow up a building on campus, some of us were ready to foil their plans by entering through the steam tunnels; we didn't want our school destroyed. (I heard that later the local SDS leader, Karolyn Kendrick, was wanted "to help the authorities with their investigations", as the British would put it, in connection with a similar attempt.) >The cores had those convenient holes for picking the core sleeve. Of course that's not what they were intended for; they're for a small pin punch to push the pins out of the columns in case they're sticky. (You can also drive out the pins, cap and all, but it spoils the spring.) If you file the end of a 1/8" (I think it was) pin punch to a 45-degree angle, it makes removing the caps without damage a breeze. >The locks, by the way, had a master key cut for the deepest pin, even >though the school didn't use it. (Maybe the police or Best co?) Best locks are pinned either by the factory or by a local Best rep. It is NOT standard practice to add any levels of masterkeying for use other than as part of the customer's masterkeying system. It may be that your school was indeed required to provide a master key to police etc. I don't think Best would dare build in a key for their own use. >Someone let themselves into the locksmith's shop and stole the key >machine the next year; very crude, they should have used it on >the premises so no one would have suspected. There's always someone who doesn't have any sense of judgement and steps beyond the bounds of harmless activity. Stealing equipment is certainly beyond the bounds. At Rice, our lock hacking had to be toned down because some idiot started stealing stuff through the steam tunnels, and the administration threatened to expel anyone found exploring the steam tunnels no matter what their intentions were. That pretty much ended a major hobby for several students. One wonders why the school's official educational practices are so stifling or boring that students find themselves turning to such hobbies instead. I've never heard of a technically-oriented college or university, Best-using or not, where lock hacking didn't occur. Too bad some sort of locksmithing course credit isn't normally offered.
-----------[000006][next][prev][last][first]----------------------------------------------------
Date: 2 Jul 90 15:29:15 GMT
From: mchinni@PICA.ARMY.MIL ("Michael J. Chinni, SMCAR-CCS-E")
To: misc.security
Subject: [Theodore Lee: The F9 factoring result]FYI ... (this is a long message: 155+ lines) Date: Wed, 27 Jun 90 22:19:44 -0400 >From: Theodore Lee <lee@TIS.COM> Subject: The F9 factoring result MESSAGE FROM RON RIVEST VIA JIM BIDZOS VIA STEVE KENT VIA STEVE CROCKER: Thanks to Robert Silverman for keeping many people honest. As an additional effort to that end, I attach an analysis of the recent factoring effort, done by Ron Rivest. The early reports of RSA's demise have been greatly exaggerated... Note: Be sure and read the end of Rivest's note. Jim Bidzos, RSA Data Security To: Whom It May Interest (Feel free to distribute further...) >From: Ronald L. Rivest Date: June 21, 1990 Re: Recent Factoring Achievement (Preliminary draft; may contain typos or other inaccuracies. Please send corrections to rivest@theory.lcs.mit.edu) This note is in response to the numerous inquiries I've received regarding the recent factoring of a 155-digit number by A. Lenstra, M. Manasse, and others. (See the New York Times article of 6/20/1990 by G. Kolata.) This note attempts specifically to correct some of the misimpressions that may arise from a reading of such popular press articles. Using an ingenious new algorithm, Lenstra, Manasse, and others have factored the 155-digit number known as "F9", the ninth Fermat number: F9 = 2^(2^9) + 1 = 2^(512) + 1 . In binary, this number has the form 100000....000000001 where there are 511 zeros altogether. (F9 is a 513-bit number.) This is a fascinating development, and the researchers involved are to be congratulated for this accomplishment. The algorithm used is known as the "number field sieve", or "NFS" (not to be confused with a network protocol of the same acronym!). The NFS algorithm is described in the Proceedings of the 1990 ACM STOC Conference. The NFS algorithm is based on an idea due to Pollard, as developed further by Arjen Lenstra, Hendrik W. Lenstra, and Mark S. Manasse. The NFS algorithm is specifically designed to factor numbers that, like F9, have a very simple structure: they are of the form a^b + c where c is relatively small. (For F9, we have a=2, b=512, and c=1.) Some simple extensions of this algorithm are also possible, to handle numbers whose binary representation has many zeros, and related kinds of numbers (ternary, etc.) Numbers that have such a special structure are extremely rare and are unlikely to be encountered by chance. That is, the NFS algorithm does not apply to the kind of "ordinary" numbers that arise in practical cryptography, such as using RSA. They only apply to numbers with "sparse" representations having few nonzero components. (Let us call such numbers "rarefied".) When working on a rarefied number, the NFS algorithm has an estimated running time of the form (for an input number n): exp(1.56 (ln n)^1/3 (ln ln n)^2/3) (1) For n = F9, this evaluates to 4.1 x 10^15 operations, which, at 3.15 x 10^13 operations/year for a 1 MIP/sec machine (i.e. a MIP-year), gives a workload estimate of 130 MIP-years, only off by a factor of two from the actual work of 275 MIP-years. (That is, formula (1) may be roughly too low by a factor of two.) It is instructive to see the effect of doubling the size of the number being dealt with. A 1024-bit (332-digit) rarefied number requires an estimated 1.54 x 10^21 operations = 4.9 x 10^7 MIP-years, a dramatic increase in difficulty. The NFS algorithm algorithm is not a "polynomial-time" algorithm; the difficulty of factoring still grows **exponentially** with a polynomial function of the length of the input. What has this to do with RSA and cryptography? I think there are three basic points: -- This development indicates that the status of factoring is still subject to further developments, and it is wise to be conservative in one's choice of key-length. -- The NFS algorithm may yet be generalized to handle "ordinary" numbers, and the potential impact of this should be considered. -- Factoring is still a very hard problem, despite everyone's best efforts to master it. Regarding the further extensions of NFS to handle ordinary numbers, this is judged to be a reasonable possibility by those working on NFS, so it is helpful to consider what impact this may have. It is conjectured (see the ACM STOC paper referenced above) that a successful extension of the NFS algorithm to ordinary numbers would have a running time of the form: exp(2.08 (ln n)^1/3 (ln ln n)^2/3) (2) This is similar to equation (1) except that the constant 1.56 is replaced by the constant 2.08. Note that a practical version of such an extension does NOT yet currently exist (to the best of my knowledge), but even granting its plausibility we arrive at an estimate of the tie required to factor a 512-bit number of 6.5 x 10^20 operations = 2 x 10^7 MIP-years which (in my opinion) is a substantial degree of security. It is interesting to note that this work factor is actually GREATER than that required by the ``standard'' factoring algorithms (e.g., the quadratic sieve), which have a running time of exp((ln n)^1/2 (ln ln n)^1/2); for a 512-bit number, this gives a work-factor estimate of only 6.7 x 10^19 operations. Indeed, the NFS algorithm (when extended) will be asymptotically superior than the quadratic sieve algorithm, but will be slower for numbers with less than about 200 digits. That is, assuming that (2) is indeed the correct running-time estimate for any extension of NFS, then NFS will not affect the security of any numbers of less than about 215 digits. So any "standards" that have been considered using 512-bit RSA moduli are not likely to be affected by any NFS extensions. (At most, one could imagine that the RSA key-generation process might be extended to check that the resulting modulus n is not a rarefied number.) In the truly worst-case scenario, we would have that an extension of NFS would be found that allows ordinary numbers to be factored with a work-factor that is governed by equation (1); in this case one would need to adjust the sizes of moduli used by RSA upwards by a factor of less than two to more than offset the new algorithm. A factor of two in size affects the running time of public-key encryption (or signature verification) by a factor of four and the running time of private-key encryption (or signature generation) by a factor of eight. Noting that the speed of workstations has increased by a factor of over 100 in the last decade (indeed, such factors have been the technological advance that made the successful implementation of NFS possible!), such performance penalties, if necessary, seem to be easily absorbed by expected technological advances in the speeds of the underlying RSA implementation technologies. That is, the NFS-like factoring algorithms do not, even in this worst-case scenario, prevent successful implementations of the RSA cryptosystem. As a cryptographer, I am actually very happy with all the effort that is being spent trying to determine the exact level of difficulty of factoring. Achievements such as the recent development of NFS help to pin down the best-possible rate of growth of the difficulty of factoring, so that users of cryptographic schemes can pick key sizes with an increased degree of confidence that unforeseen developments are unlikely to occur. The best way to ensure confidence in a cryptographic system is to have it attacked vigorously and continuously (but unsuccessfully) by well-qualified attackers. If, despite their best efforts, the difficulty of cracking the system remains intrinsically exponential, then one can have a reasonably high degree of confidence that the system is actually secure. This is the process we have been seeing at work in the recent work on factoring. The results of the attacks can be used to guide the selection of the necessary key size for a desired level of security (with an appropriate margin of safety built in, of course). (As a closing note, here's a prediction: I expect that the 128-digit ``challenge RSA cipher'' published in the August 1977 issue of Scientific American to be cracked (probably by the quadratic sieve algorithm or a variant, not NFS) during the next 1-3 years. This accomplishment will require substantially more computer time than the 275 MIP-years required to factor F9.)
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 3 Jul 90 19:47:52 GMT From: 09nilles%cuavax.dnet@NETCON.CUA.EDU (Fiver Toadflax) To: misc.security Subject: re: SPARCstation Security
What you might try doing is to take and glue/fasten the pad to a steel sheet.
This sheet is then secured via cable to the same thing as the monitor or CPU.
The pad is now moviable, and yet is unlikely to walk out the door.
Dave
09nilles@cua.bitnet
Documentation Assistant
Catholic University of America
-----------[000008][next][prev][last][first]---------------------------------------------------- From: Doug Gwyn <gwyn@smoke.brl.mil> 5-JUL-1990 13:50:38 To: misc-security@rutgers.edu
>The NSA produces several pamphlets describing what they do. They even have a Public Affairs office, and their non-classified documents are subject to the Freedom Of Information Act. However, I haven't heard of any guided tours for sightseers, yet.
-----------[000009][next][prev][last][first]---------------------------------------------------- From: levine@csd4.csd.uwm.edu (Leonard P Levine) 5-JUL-1990 14:20:58 To: misc-security@uunet.uu.net
> Sorry Leonard. You must not be aware of any professionally designed > master keying systems that were set up according to common locksmithing > industry standards. Don't I wish. I spoke at length to our locking staff, as well as the building designers. They did not even believe that this really bad design was not the norm. I agree with Seth that this is dangerous, but never could get lock people to follow the problem. Seth, are you speaking from theory or do you have a high masterkey in your posession? I really want to know. len levine
-----------[000010][next][prev][last][first]---------------------------------------------------- From: mlindsey@x102c.ess.harris.com (Lindsey MS 04396) 5-JUL-1990 14:48:08 To: misc-security@ucsd.edu
Sorry if this is a dead horse ... I just bought a house and would like to put dead-bolts on every exterior door, and have all of them work from one key. Does anyone out there have any advice about which models/brands to buy or avoid. I'm looking for: - good security - easy installation - dependability (will it last a long time) - reasonable price Please email. If there is enough interest I will post a summary. Thanks. "Waste your brain, wax your board, and pray for waves!" Woody in E.G.A.E. /earth is 98% full! Please delete anyone you can! (anonymous) $teve Lindsey |-) uunet!x102a!mlindsey (407) 727-5893 :-) mlindsey@x102a.ess.harris.com
-----------[000011][next][prev][last][first]---------------------------------------------------- From: mark%beowulf@ucsd.edu (Mark Anderson) 5-JUL-1990 15:32:00 To: misc-security@sdcc6.ucsd.edu
>A properly selected master key must be impossible to create by filing >a change key. That means it must contain at least one cut that is >taller than the corresponding cut in every change key. I don't know about "common locksmithing industry standards", but the Foley-Belsaw training course doesn't mention any such concern in their lessons. Almost everywhere I've ever been you could find a change key to convert to a master. I think you are overestimating the training/concerns of most locksmiths. Or perhaps is just that facilities outgrew the original "correct" design. And who really cares about the master key shear line, any old shear line will work, even for keys that don't exist. I've always had the best luck picking locks on a master key system. And if you are in a position where you can request legitimate keys, you can often order masterkeys through the same office just by knowing the code (which you get by watching a janitor). mark
-----------[000012][next][prev][last][first]---------------------------------------------------- From: Carl DeFranco <DEFRANCO@tops20.radc.af.mil> 5-JUL-1990 16:24:37 To: security@pyrite.rutgers.edu
Recently, someone asked how to put together a system to provide protection for a computer system operation through a packet switch using some type of "box" for encryption. It's not that easy. Remember how packet swtiching works? Each packet contains address information that directs it on its way to a destination. Since the packet switch expects clear text information, the "box" must have some method of extracting the address data from the packet, encrypting the remainder, then restoring the address data to the packet. This process cannot be done once at the establishment of a comm session - it must be done for each packet that will pass through the packet switch. The Government has invested a lot of money in accomplishing just this type of operation. I am not aware of any commercial sources of equipment that do what you want using commercial encryption methods such as DES. The problem comes from using the "connectionless" networking provided by packet switching. IF you modify your system to one which allows "nailed down" communication, the "connection-oriented" method, you can do just what you mention - establish the connection in the clear, then "go secure". You will also need some method of exchanging encryption keys and managing them on some periodic basis. SO, as you can see, the problem is solvable, but it isn't a simple one. Sorry to be the bearer of less than encouraging news. Carl DeFranco defranco@tops20.radc.af.mil -------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 10:31:00 GMT From: MISS026@ecncdc.BITNET (GREENY) To: misc.security Subject: re: Failed: attempt #1 at securing the vehicle
Forget it. Just put a decent alarm system on the car, with an ignition kill and jack-up/motion sensor (and maybe an audio discriminator in case the glass breaks), and a nice loud siren (maybe the traditional "flashing" LED), and park in a lighted area. For the most part, reinforcing the locks, and making them "slim-jim" proof is next to impossible. There isn't a car around, that a qualified locksmith (or car repo. man, or car thief) cant get into quickly. And the tools are widely available, as are the instructions for the individual cars. Besides, you sorta want your car to be slim-jim-able so that when you lock your keys in it, or lose the things, then a locksmith can get you in! If you really wanna go nuts, get a 4 channel programmable voice driver from Oregon Scientific (no # readily available...), and use the different inputs from the alarm to trigger different voice outputs...). My car says "ILLEGAL TOWING IN PROGRESS" when jacked up/towed, yells "I'M BEING STOLEN" when the door/trunk/hook is being opened, yells "YOU BROKE MY WINDOW" when the glass gets broken....the 4th one I havent used...Also, I have a remote control (RF) to arm/disarm, have capabilities for passive arming, and have a pager linked into the alarm that will find me within 2 miles when the alarm goes off..... So far, it has saved me at least once. I had a crook trying to break into the car on campus during the summer, when not too many people would hear the siren, and my pager went off. I went off after the damn guy with a baseball bat. He didnt get in, and I didnt get any whacks in, but the cops found him shortly (seems that they heard the siren and were on the way...). at any rate, had he gotten in, I have purposely used multi-colored wires wrapped in seemingly insane configurations to confuse a crook, hidden the relays that trigger the pager/ign. cutout in a radio shack project box labeled HIGH VOLTAGE. CAUTION. under the dash. So it would take this "genius" of crime a longggggg time to start my car, and steal it. At most he would get the radio, and being a standard Ford install, he could have it with my compliments.... bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU GEnie: GREENY AOL: GREENY1 Compu$erve: 72567,457 Disclaimer: U use it, U B responsible fer it!
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 4 Jul 90 12:23:13 GMT From: levine@CSD4.CSD.UWM.EDU (Leonard P Levine) To: misc.security Subject: Re: Best Locks
The reason for the low cut master is simply laziness on the part of the locksmith, I believe. When a lock is assembled, does not the locksmith build up the pins in the rotating part by dropping in pieces and then slide the assembly together? If so, then there must be a key in the lock to make the top of the pins level with the top of the rotating part in order to let the system slide easily. Similarly, removal is done by the same method. Put in a key, and remove the part with the key in place. If the Master is not the lowest key, a separate key would have to be made for each lock assembled. If the Master is the lowest, it may be used for the assembly of each lock in turn. Thus any locksmith paid by the month will set up a Masterkey that is the lowest key in the system. Not good, but surely easy to work with. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail levine@cs.uwm.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. FAX (414) 229-6958 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + [Moderator tack-on: Not necessarily. You don't need a key present to *assemble* a lock at all; the plug can be inserted slightly offset and everything will just drop into place when it's turned to locked position. Also, any valid key will allow disassembly; you just have to retain all the other parts in the shell with a thing referred to as a "following tool". You can pick the rest of the parts out one by one afterward. _H*]
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 6 Jul 90 15:30:33 GMT From: shz@packard.att.com (Seth Zirin) To: misc.security Subject: Re: Security and Masterkeys
>Seth, are you speaking from theory or do you have a high masterkey in >your posession? I really want to know. Both. My home is master-keyed with Medeco Biaxial removable core locks. The locks are D-10 and D-11 deadbolts and Embassy cylindrical locksets. The layout is four level: GGMK, GMK, MK & CK. 1) Each core has a separate combination (CK). 2) There is a MK per side of each door (i.e., deadbolt and lockset) and the MK that fits the inside cores on a door does not fit the outside. This prevents a delivery person from stealing an "exit" key and using it to obtain entry. 3) The outside cores are grouped under GMKs to provide "entry via the front", "entry via the garage" or a "entry via the back" keys. 4) All inside cores are grouped under a "fire egress" GMK so a single key may be used to exit via any path. 5) Every core opens with the Great Grand Master Key. This system allows the change key (CK) for the front door lockset to be left with a neighbor in case of a lockout, prevents a visitor from gaining entry with a stolen "inside" key, and allows someone to enter to water plants without letting them into the garage. I set-up the master-keying system myself, including the calculations, installation of the locks, pinning of the cores and cutting of the keys. It turns out that only a few different keys were cut: the GGMK and several GMKs, MKs and CKs. No key in the system can be altered into a higher level key and each key (including the GGMK and every GMK and MK) has a wide range of cuts. Each key has at least two cuts that differ by the MACS (Maximum Adjacent Cut Separation) which varies from cut to cut because of the fore and aft biaxial Medeco pins. Seth Zirin, CPL Member Associated Locksmiths of America Member Safe and Vault Technicians Association
-----------[000016][next][prev][last][first]---------------------------------------------------- From: deronwal@tybalt.caltech.edu (Deron Walters) 10-JUL-1990 11:23:05 To: security@rutgers.edu
>On a recent visit I noticed they had rekeyed with Medeco Bi-axial locks, but
^^^^^^^^^^^^^^^^^^^^^
Huh? Bi-axial? I'm familiar with regular Medeco locks, but I've never heard
of these. Please describe them in more detail!
Deron A. Walters
[Moderator explanatory tack-on: Biaxial refers to Medeco's offset-chisel-tip
pin design, in which the bottom edge of the pin is offset forward or back
by .025". Thus the bottom of the keycut has to not only be at the right
height and twist, it also has to be at the correct offset along the key bit.
_H*]
-----------[000017][next][prev][last][first]---------------------------------------------------- From: shz@packard.att.com (Seth Zirin) 10-JUL-1990 11:57:43 To: security@rutgers.edu
The Foley-Belsaw lesson plan is outdated. I say this from experience because I took the course a few years ago. Check with the NY School of Locksmithing or with Lockmasters. The Associated Locksmiths of America (ALOA) Proficiency Registration Program (PRP) in which I hold the certification of Certified Professional Locksmith (CPL, I'm one elective away from Certified Master Locksmith, CML) has sections on "Master-Keying" and "Advanced Master-Keying." Both of these sections and every book on master-keying repeatedly state that no key should be alterable to a higher level. You are correct about many improperly setup master-keying systems. There are way too many curbside commandos that call themselves locksmiths. Seth Zirin
-----------[000018][next][prev][last][first]---------------------------------------------------- From: "Chuck Sechler" <TS0258@ohstvma.bitnet> 11-JUL-1990 21:08:21 To: SECURITY@MARIST, BIG-LAN@SUVM
Some breakins to a computer at a university in Ohio has prompted us at Ohio State to look into enforcing use of more obscure passwords on our systems. Basically, Iwould like to know if there has been any work on MVS and/or CMS platforms to keep users from picking obvious passwords, like their name, password same as userid, password is a word, etc. On MVS we are working on Top Secret software, and it has some interesting capabilities for restriction, including generating random passwords, when a user is forced to change their password, but it is not ready for full implementation yet. Some UNIX platfors check against large lists of restricted words(like 50000 or more). Any thoughts? Please respond to me. Thanks.
-----------[000019][next][prev][last][first]---------------------------------------------------- From: "Jacques Beland (a.k.a. Mickey) Trent University" <BELANDJ@trentu.ca> 11-JUL-1990 21:40:07 To: security@UBVM
Can someone please show me what the different "security levels" mean in terms of operating system. What I mean is one sees that "xxx's o/s is a B2 rating". What is B2 and what are the different availale levels? And is there somewhere one can look up what o/s are rated at what level? For example, VMS is B1, Novell is K9 etc?? Thanks.
-----------[000020][next][prev][last][first]---------------------------------------------------- From: "Kees de Groot, Information Systems Security" <DEGROOT@rcl.wau.nl> 11-JUL-1990 22:01:27 To: security@pyrite.rutgers.edu
Bob,
Intel's micro-controllers in the MCS-51-series
have a feature in which you can program a sort of
hashing or mask. The effect is that it is impossible
to read directly from the EPROM, but you can erase
the whole device and reprogram it.
This is al from between my ears. if you want
more detailed information I can try to find some docs.
Tel. +31-8370- .KeesdeGroot (DEGROOT@RCL.WAU.NL) o\/o THERE AINT NO
(8)3557/ Computer Systems Security [] SUCH THING AS
4030 Inform. & Datacomm. Dreijenplein 2 .==. A FREE LUNCH!
6703 HB Wageningen, the Netherlands
X25: PSI%(+204)18802031937::DEGROOT
disclaimer: I always speak for myself
- if you go too far to the east, you find yourself in the west .. -
-----------[000021][next][prev][last][first]---------------------------------------------------- From: David Haimson <dmh@cnd.hp.com> 11-JUL-1990 22:27:55 To: security@pyrite.rutgers.edu
from Science News, June 2, 1990
Bits of Uncertainty: Quantum Security, by I. Peterson
The trouble with sending a secret message is that the recipient must
have a key for deciphering it. This means the two parties must
initially either meet in person or risk sending the key by some less
secure communications channel, and that invites interception. Inspired
by an idea first proposed nearly a decade ago, a group of researchers
has now designed and constructed a device that uses the uncertainty
principle of quantum physics to provide a safe but public means for
transmitting vital, secret information.
The device uses extremely faint flashes of light -- only one photon
per flash -- to carry messages. Each photon has a certain linear
polarization (whether the electric field associated with the light is
oscillating horizontally or vertically) and a certain circular
polarization (whether the electric field is rotating in a right-handed
or left-handed sense about its direction of travel). According to the
uncertainty principle, there's no way to measure a photon's linear and
circular polarizations simultaneously. Measuring one disturbs the
other.
A sender can use the polarizations of individual photons to send a
sequence of signals to the receiver, randomly choosing whether to encode
a bit of information as a specific linear or circular polarization. For
each photon detected, the receiver chooses randomly which type of
polarization to measure. About half the polarization measurements would
match the values the sender transmitted. By ascertaining which photons
were correctly measured, the sender and receiver could derive a code,
known only to them, which would serve as a key for encrypting and
deciphering messages.
Because any measurement attempted by a third party would
unpredictably alter a photon's polarization, an eavesdropper couldn't
intercept the transmission without irrevocably scrambling the message
and alerting both the sender and receiver to the surreptitious
surveillance. To check for eavesdropping, the receiver would simply
compare notes with the sender, ascertaining what the results for a
number of selected measurements should have been. Statistical
deviations from the expected results would signal an eavesdropper's
presence.
This so-called "quantum public key distribution system" is the first
communications system ever built to depend on the uncertainty principle
to ensure secrecy, say its inventors, Charles H. Bennett of the IBM
Thomas J. Watson Research Center in Yorktown Heights, N.Y., and Gilles
Brassard of the University of Montreal. "The system relies on the
uncertainty principle to enable its users to detect eavesdropping on the
quantum channel, even by an opponent with superior technology, and
reject the compromised transmissions."
After playing with the idea for several years, Bennett and a
colleague constructed a working model of the system last summer. The
device consists of tiny diode lasers for generating faint light flashes
and detectors for picking up the signals. The entire apparatus sits
within a light-tight box about 13 inches long. A computer program
controls the apparatus, tallies the signals sent, received and
intercepted, and displays the results.
Because it is relatively slow and can be used only for communicating
random bits, the apparatus is best suited for transmitting cryptographic
keys. Once the two users establish a key, they can exchange secret
messages by way of a faster, conventional communications channel.
However, the device's present size severely limits its usefulness.
Bennett, who described his demonstration model at last week's Eurocrypt
conference in Aarhus, Denmark, now plans to build an improved device
using an optical-fiber cable for transmitting light pulses over
distances up to 500 meters. Going to greater lengths is tricky because
the light pulses must necessarily be weak, which means they travel only
a limited distance along optical fibers before fading away.
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 10 Jul 90 14:01:00 GMT From: UCCXNCS@osucc.BITNET To: misc.security Subject: Userid maintenance Automation
Since userid maintenance and security seem to go hand-in-hand, I thought I might be able to get some ideas on how to go about attacking a problem we are facing here at OSU. If you know of a list that addresses this sort of thing, please let me know. Userid creation and maintenance is one of our biggest headaches. We have an IBM 3090 on which we run VM/SP with MVS running as a guest under it. The MVS system is used mainly by our administrative users. We have only had VM a few months and are wanting to open it up to our academic users who, for the most part, abhor MVS and JCL. The idea is for the VM system to be "friendlier", not requiring password changes, etc. So, we are looking for ideas on how to automate the setup and maintenance of permanent (faculty) and temporary (student) userids on the VM system. Right now we are managing the few VM userids that we have set up through DIRMAINT. However, we do have VMSECURE setting on the shelf. It seems to me that DIRMAINT is rather cumbersome, and I'm not sure how we could set up an automated process that would create several hundred userids using DIRMAINT. Anyone that has dealt with this problem and would be willing to give us some suggestions is welcome to respond. Nancy C. Stevens (405) 744-6301 uccxncs@osucc.bitnet
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 90 15:56:11 GMT From: nagle@well.sf.ca.us (John Nagle) To: misc.security Subject: Re: Password Checking
>Basically, Iwould like to know if there has been any work on MVS and/or CMS
>platforms to keep users from picking obvious passwords, like their name,
I first posted a simple solution to this problem back in 1984. The
technique used does not require any dictionary or large tables; it relies
on some statistics of letter sequence usage in English which allow one to
determine whether something is a likely English word. The code can be obtained
from the comp.sources.unix archive, or I can send a copy to interested parties.
The code is in C, but there is no UNIX dependency; in fact, I wrote the
original code on a DECsystem 2060, in C. The archive reference appears below.
John Nagle
Newsgroups: comp.sources.unix
Subject: v16i060: Tell if a password is "obvious"
Date: 10 Nov 88 14:47:09 GMT
Submitted-by: "John B. Nagle" <jbn@glacier.stanford.edu>
Posting-number: Volume 16, Issue 60
Archive-name: obvious-pw
[ This program does NOT try brute-force methods to guess passwords,
but instead tells if a password is an "obvious" one likely to be
guessed by such a program. ]
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: 12 Jul 90 18:13:51 GMT From: lorence@SCTC.COM (Len Lorence) To: misc.security Subject: Re: Different security ratings
>Can someone please show me what the different "security levels" mean in >terms of operating system. What I mean is one sees that "xxx's o/s is a >B2 rating". What is B2 and what are the different availale levels? What you want is a copy of the DOD Trusted Computer System Evaluation Criteria (DOD 5200.28-STD) from the National Computer Security Center. It sets the criteria for a system to meet each of the evaluation ratings (D, C1, C2, B1-3, and A1.) You also want a copy of the Evaluated Products List, available from the same people. You may be disappointed to find that there are not many products which have successfully made it through the evaluation process, and some that have are no longer available. Ask your librarian if they can get you copies, ask a friend who has a Dockmaster account, or write to NCSC. Len Lorence Secure Computing Technology Corp.
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 14:45:32 GMT From: corey@esl.com (Corey Yee) To: misc.security Subject: Re: Different security ratings
There's an article titled "Certifying A System's Security" in the June 25th edition of "Unix Today!" that discusses the NCSC security ratings.
-----------[000026][next][prev][last][first]---------------------------------------------------- From: Pete Nielsen <CSMSPCN@oac.ucla.edu> 15-JUL-1990 4:14:09 To: security@pyrite.rutgers.edu
I'd ask a bank, I believe wired funds include an authentication code. RSA is an interesting question. I heard that some mathematician recently factored a 155 digit number, and that they are consequently recommending at least 200 digit primes for the RSA stuff.
-----------[000027][next][prev][last][first]---------------------------------------------------- From: owen blevins <blevinso@silver.ucs.indiana.edu> 15-JUL-1990 4:48:39 To: security@ohstvma.bitnet
Need to find out if it is possible to obtain copy of YOUR record. i.e. if i've been accused,convicted, etc. of a federal (or for that matter state) crime.....I assume the FBI keeps it online somewhere-- is it possible (it probably is) to get a copy, and logically, how/who do I contact to get a copy of my criminal record. thanks! blevinso@silver.ucs.indiana.edu
-----------[000028][next][prev][last][first]---------------------------------------------------- From: 09nilles%cuavax.dnet@netcon.cua.edu (Fiver Toadflax) 15-JUL-1990 5:23:52 To: security@netcon.cua.edu
What you might try doing is to take and glue/fasten the pad to a steel sheet.
This sheet is then secured via cable to the same thing as the monitor or CPU.
The pad is now moviable, and yet is unlikely to walk out the door.
Dave
09nilles@cua.bitnet
Documentation Assistant
Catholic University of America
-----------[000029][next][prev][last][first]---------------------------------------------------- From: smb@ulysses.att.com (Steven Bellovin) 15-JUL-1990 5:57:20 To: misc-security@att.att.com
There was a paper published in Cryptologia Vol 11, no. 4, on cracking Word Perfect 4.2; I have no idea if they changed the encryption algorithm. It was reprinted in ``Cryptology: Machines, History, and Methods''. That same volume has a another reprint ``Survey of Data Insecurity Packages'' that doesn't include Word Perfect; however, the same author did a followup report on some other bad encryption programs that you may want to look for.
-----------[000030][next][prev][last][first]---------------------------------------------------- From: Stacey Son 377_4965 <sson%remus.Berkeley.EDU%@rutgers.edu> 15-JUL-1990 6:25:36 To: misc-security@ucbvax.berkeley.edu
I have a friend who has a company that specializes in data recovery. He markets a program that will recover crypted Word Perfect documents. He also decrypts other programs such as Lotus, Microsoft Excel, etc. You can reach him at the following address: Access Data Recovery % Eric Thompson 87 E 600 S Orem, UT 84058 (801) 224-6970 ----------------------------------------------------------------------------- Stacey D. Son | "I think there is a world market for Network Manager, Supercomputer Center | about five computers" -- Thomas J. Brigham Young University | Watson, CEO, IBM Corporation, 1947 Dept. of Electrical/Computer Eng. | 459 Clyde Building | "The number of UNIX installations has Provo, UT 84602 | grown to ten, with more expected." Voice:(801)378-5950 FAX:(801)378-6586 | -- UNIX Programmers Manual, 2nd Email: sson@ee.byu.edu | Edition, June, 1972 -----------------------------------------------------------------------------
-----------[000031][next][prev][last][first]---------------------------------------------------- From: mii@philabs.philips.com (Melik I. Isbara) 15-JUL-1990 6:59:19 To: misc-security@uunet.uu.net
I am posting this article to inform the netters about a problem with Citibank ATM machines and to ask for any information and suggestions. Please bear with me. When I received my last bank statement, I have noticed three transactions in which $900 dollars were withdrawn from my accounts from a Citibank ATM machine at a downtown NYC branch which I have never used. FACTS: 1. I did not do those transactions. 2. When they took place I was at work out of NYC. 3. I did not lose my bankcard or give it to anyone. 4. I did not write down my password or tell it to anyone. After I received my statement I went to my branch and talked to a customer representative. After a couple of days I got two letters from Citibank saying that results of their investigation (which consists only of looking at the ATM machine records for those specific transactions) showed that for those transactions my bankcard and my password were used therefore they could not honor my claim. Now my guess is that this is most probably a software problem because last weekend I went to the branch where money was withdrawn and there was a sign on the door saying that the ATM machines there were out of order. I also learned that they have been out of order for about a week. I am goig to take a legal action against to Citibank therefore I would like to know if anybody is aware of a similar situation or if anyone has any ideas on how this might have happened. I would appreciate any information and suggestions that can help me to fight Citibank to recover my money and to explain how this event might have happened. Please e-mail to mii@briar.philips.com isbara@cs.columbia.edu Thanks in advance. Melik Isbara Columbia University Dept. of Electrical Eng.
-----------[000032][next][prev][last][first]---------------------------------------------------- From: GREENY <MISS026@ecncdc.bitnet> 15-JUL-1990 7:30:46 To: <security@pyrite.rutgers.edu>
Forget it. Just put a decent alarm system on the car, with an ignition kill and jack-up/motion sensor (and maybe an audio discriminator in case the glass breaks), and a nice loud siren (maybe the traditional "flashing" LED), and park in a lighted area. For the most part, reinforcing the locks, and making them "slim-jim" proof is next to impossible. There isn't a car around, that a qualified locksmith (or car repo. man, or car thief) cant get into quickly. And the tools are widely available, as are the instructions for the individual cars. Besides, you sorta want your car to be slim-jim-able so that when you lock your keys in it, or lose the things, then a locksmith can get you in! If you really wanna go nuts, get a 4 channel programmable voice driver from Oregon Scientific (no # readily available...), and use the different inputs from the alarm to trigger different voice outputs...). My car says "ILLEGAL TOWING IN PROGRESS" when jacked up/towed, yells "I'M BEING STOLEN" when the door/trunk/hook is being opened, yells "YOU BROKE MY WINDOW" when the glass gets broken....the 4th one I havent used...Also, I have a remote control (RF) to arm/disarm, have capabilities for passive arming, and have a pager linked into the alarm that will find me within 2 miles when the alarm goes off..... So far, it has saved me at least once. I had a crook trying to break into the car on campus during the summer, when not too many people would hear the siren, and my pager went off. I went off after the damn guy with a baseball bat. He didnt get in, and I didnt get any whacks in, but the cops found him shortly (seems that they heard the siren and were on the way...). at any rate, had he gotten in, I have purposely used multi-colored wires wrapped in seemingly insane configurations to confuse a crook, hidden the relays that trigger the pager/ign. cutout in a radio shack project box labeled HIGH VOLTAGE. CAUTION. under the dash. So it would take this "genius" of crime a longggggg time to start my car, and steal it. At most he would get the radio, and being a standard Ford install, he could have it with my compliments.... bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU GEnie: GREENY AOL: GREENY1 Compu$erve: 72567,457 Disclaimer: U use it, U B responsible fer it!
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 13 Jul 90 22:38:03 GMT From: fitz@wang.com (Tom Fitzgerald) To: misc.security Subject: Re: Quantum Security
> Because any measurement attempted by a third party would > unpredictably alter a photon's polarization, an eavesdropper couldn't > intercept the transmission without irrevocably scrambling the message I don't see how this really gains you anything. An eavesdropper can still get in by cutting the line and putting in a complete receiver/transmitter station. The legitimate receiver will never see any tapped bits because they can all be completely regenerated by the eavesdropper's transmitter. Under some circumstances, the eavesdropper might have to receive a complete message and do whatever ECC is necessary to compensate for the 50% error rate on the line before forwarding the message on, but the legitimate receiver should never know the difference. > To check for eavesdropping, the receiver would simply > compare notes with the sender This implies an out-of-band communication. If you have such a thing in the first place, why use quantum signalling? If the comparisons are going over the quantum link, the eavesdropper can modify them in transit to hide his own presence. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
-----------[000034][next][prev][last][first]---------------------------------------------------- From: shz@packard.att.com (Seth Zirin) 17-JUL-1990 1:51:30 To: security@rutgers.edu
>but as the number of masters increases, so does the ease of picking the lock This is not necessarily correct. It depends on the master keying algorithm used. I've rekeyed locks, changing them from a 2 level (1 level of MK) to a 3 level (GMK, MK) and wound up with fewer pins in each lock. Some would say that with fewer pins in some of the stacks, the lock was more difficult to pick... Seth Zirin, CPL
-----------[000035][next][prev][last][first]---------------------------------------------------- From: levine@csd4.csd.uwm.edu (Leonard P Levine) 17-JUL-1990 2:26:38 To: misc-security@uunet.uu.net
The reason for the low cut master is simply laziness on the part of the locksmith, I believe. When a lock is assembled, does not the locksmith build up the pins in the rotating part by dropping in pieces and then slide the assembly together? If so, then there must be a key in the lock to make the top of the pins level with the top of the rotating part in order to let the system slide easily. Similarly, removal is done by the same method. Put in a key, and remove the part with the key in place. If the Master is not the lowest key, a separate key would have to be made for each lock assembled. If the Master is the lowest, it may be used for the assembly of each lock in turn. Thus any locksmith paid by the month will set up a Masterkey that is the lowest key in the system. Not good, but surely easy to work with. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail levine@cs.uwm.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. FAX (414) 229-6958 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + [Moderator tack-on: Not necessarily. You don't need a key present to *assemble* a lock at all; the plug can be inserted slightly offset and everything will just drop into place when it's turned to locked position. Also, any valid key will allow disassembly; you just have to retain all the other parts in the shell with a thing referred to as a "following tool". You can pick the rest of the parts out one by one afterward. _H*]
-----------[000036][next][prev][last][first]---------------------------------------------------- From: "Larry Margolis" <MARGOLI@ibm.com> 17-JUL-1990 2:59:28 To: security@pyrite.rutgers.edu
> as the number of masters increases, so does the ease of picking the lock Not necessarily. You can have a sectional master section, where each pin chamber has at the most one master pin. Assume a 7-pin lock. Pins 1 and 2 could be the site-wide master, pins 3 and 4 the building master, and pins 5 to 7 the floor master. So, on each floor, all the change keys will have pins 1 - 4 the same, and pins 5 - 7 different. A floor master key would have cuts 1 - 4 the same as the change keys for that floor, with cuts 5 - 7 cut to the master levels. Each floor in the building be done similarly, with pins 1 and 2 the same and pins 3 and 4 differing by floor. The building master then has cuts 1 and 2 the same as all the other keys for that building, with cuts 3 to 7 cut to the master levels. Finally, each building has pins 1 and 2 different, and the grand master key has all cuts cut to the master levels. The one thing you *don't* want to do is put too many master pins in a lock. I once came across some Best padlocks that were meant to be opened by any <company> serviceman in the state. The locks had 2 or 3 master pins in the first and last chambers, and chambers 2 - 6 had master pins for *every level* !!! The things practically fell open in my hands. And, of course, once I had one in my posession, it was trivial to make a control key for it so I could have gained access to any of their buildings. (What surprised me was that their locksmiths told them this couldn't be done.) Larry Margolis, MARGOLI@YKTVMV (bitnet), MARGOLI@IBM.COM (csnet)
-----------[000037][next][prev][last][first]---------------------------------------------------- From: shz@packard.att.com (Seth Zirin) 17-JUL-1990 3:36:30 To: security@rutgers.edu
>Seth, are you speaking from theory or do you have a high masterkey in >your posession? I really want to know. Both. My home is master-keyed with Medeco Biaxial removable core locks. The locks are D-10 and D-11 deadbolts and Embassy cylindrical locksets. The layout is four level: GGMK, GMK, MK & CK. 1) Each core has a separate combination (CK). 2) There is a MK per side of each door (i.e., deadbolt and lockset) and the MK that fits the inside cores on a door does not fit the outside. This prevents a delivery person from stealing an "exit" key and using it to obtain entry. 3) The outside cores are grouped under GMKs to provide "entry via the front", "entry via the garage" or a "entry via the back" keys. 4) All inside cores are grouped under a "fire egress" GMK so a single key may be used to exit via any path. 5) Every core opens with the Great Grand Master Key. This system allows the change key (CK) for the front door lockset to be left with a neighbor in case of a lockout, prevents a visitor from gaining entry with a stolen "inside" key, and allows someone to enter to water plants without letting them into the garage. I set-up the master-keying system myself, including the calculations, installation of the locks, pinning of the cores and cutting of the keys. It turns out that only a few different keys were cut: the GGMK and several GMKs, MKs and CKs. No key in the system can be altered into a higher level key and each key (including the GGMK and every GMK and MK) has a wide range of cuts. Each key has at least two cuts that differ by the MACS (Maximum Adjacent Cut Separation) which varies from cut to cut because of the fore and aft biaxial Medeco pins. Seth Zirin, CPL Member Associated Locksmiths of America Member Safe and Vault Technicians Association
-----------[000038][next][prev][last][first]---------------------------------------------------- From: mark%beowulf@ucsd.edu (Mark Anderson) 17-JUL-1990 4:11:24 To: misc-security@sdcc6.ucsd.edu
Chapter 8.5 of the California "Business and Professions Code" is the section relevant to Locksmiths. You'll have to check your city charter for any local rules. It is really most interested in people who work for hire to the general public. Some general definitions from the code "Key duplicator" means an operator of a key duplicating machine who merely duplicates keys for retail customers and who does not perform an other functions of a locksmith. "Locksmith" means a person, other than a key duplicator, who installs, repairs, opens and modifies locks and who makes keys for locks. Some relevant rules: Permits. On and after April 1, 1988, it is unlawful for any person to practice as a locksmith without first obtaining a permit from the bureau. Locksmiths working for hire; person exempt (a) This chapter applies only to locksmiths working for hire. (b) This chapter does not apply to the following persons: (1) Any person, or his or her agent or employee, who is the manufacturer of a product, other than locks and keys, and who installs, repairs, opens or modifies locks or who makes keys for the locks of that product as a normal incident to its marketing. (2) Key duplicators. (3) Employees who are industrial or institutional locksmiths and whose services are provided only to an employer who does not provide locksmith services for hire to the public. ------- You should be able to set yourself up as a key duplicator without any problem. You might stop by some key duplicating center and find someone who will tell you how they go about ordering keys. If you are interested in just a few blanks, I'm sure you can find a key duplication place that will sell them to you uncut. Another route is to take a mail correspondence locksmithing course. At the time I took mine, the cost was $400. In the deal I got to keep a key making machine and can order locksmithing supplies (picks, blanks, cutting machines, code books, etc) thru the mail order company. I wouldn't recommend it unless you don't really care about the money. The first lesson was something like match like keys together in pairs. From experience I know you can buy stuff and subscribe to trade journals as a "student of locksmithing". mark anderson ~
-----------[000039][next][prev][last][first]---------------------------------------------------- From: "Michael J. Chinni, SMCAR_CCS_E" <mchinni@pica.army.mil> 17-JUL-1990 5:41:33 To: security@pyrite.rutgers.edu
FYI ... (this is a long message: 155+ lines) Date: Wed, 27 Jun 90 22:19:44 -0400 From: Theodore Lee <lee@TIS.COM> Subject: The F9 factoring result MESSAGE FROM RON RIVEST VIA JIM BIDZOS VIA STEVE KENT VIA STEVE CROCKER: Thanks to Robert Silverman for keeping many people honest. As an additional effort to that end, I attach an analysis of the recent factoring effort, done by Ron Rivest. The early reports of RSA's demise have been greatly exaggerated... Note: Be sure and read the end of Rivest's note. Jim Bidzos, RSA Data Security To: Whom It May Interest (Feel free to distribute further...) From: Ronald L. Rivest Date: June 21, 1990 Re: Recent Factoring Achievement (Preliminary draft; may contain typos or other inaccuracies. Please send corrections to rivest@theory.lcs.mit.edu) This note is in response to the numerous inquiries I've received regarding the recent factoring of a 155-digit number by A. Lenstra, M. Manasse, and others. (See the New York Times article of 6/20/1990 by G. Kolata.) This note attempts specifically to correct some of the misimpressions that may arise from a reading of such popular press articles. Using an ingenious new algorithm, Lenstra, Manasse, and others have factored the 155-digit number known as "F9", the ninth Fermat number: F9 = 2^(2^9) + 1 = 2^(512) + 1 . In binary, this number has the form 100000....000000001 where there are 511 zeros altogether. (F9 is a 513-bit number.) This is a fascinating development, and the researchers involved are to be congratulated for this accomplishment. The algorithm used is known as the "number field sieve", or "NFS" (not to be confused with a network protocol of the same acronym!). The NFS algorithm is described in the Proceedings of the 1990 ACM STOC Conference. The NFS algorithm is based on an idea due to Pollard, as developed further by Arjen Lenstra, Hendrik W. Lenstra, and Mark S. Manasse. The NFS algorithm is specifically designed to factor numbers that, like F9, have a very simple structure: they are of the form a^b + c where c is relatively small. (For F9, we have a=2, b=512, and c=1.) Some simple extensions of this algorithm are also possible, to handle numbers whose binary representation has many zeros, and related kinds of numbers (ternary, etc.) Numbers that have such a special structure are extremely rare and are unlikely to be encountered by chance. That is, the NFS algorithm does not apply to the kind of "ordinary" numbers that arise in practical cryptography, such as using RSA. They only apply to numbers with "sparse" representations having few nonzero components. (Let us call such numbers "rarefied".) When working on a rarefied number, the NFS algorithm has an estimated running time of the form (for an input number n): exp(1.56 (ln n)^1/3 (ln ln n)^2/3) (1) For n = F9, this evaluates to 4.1 x 10^15 operations, which, at 3.15 x 10^13 operations/year for a 1 MIP/sec machine (i.e. a MIP-year), gives a workload estimate of 130 MIP-years, only off by a factor of two from the actual work of 275 MIP-years. (That is, formula (1) may be roughly too low by a factor of two.) It is instructive to see the effect of doubling the size of the number being dealt with. A 1024-bit (332-digit) rarefied number requires an estimated 1.54 x 10^21 operations = 4.9 x 10^7 MIP-years, a dramatic increase in difficulty. The NFS algorithm algorithm is not a "polynomial-time" algorithm; the difficulty of factoring still grows **exponentially** with a polynomial function of the length of the input. What has this to do with RSA and cryptography? I think there are three basic points: -- This development indicates that the status of factoring is still subject to further developments, and it is wise to be conservative in one's choice of key-length. -- The NFS algorithm may yet be generalized to handle "ordinary" numbers, and the potential impact of this should be considered. -- Factoring is still a very hard problem, despite everyone's best efforts to master it. Regarding the further extensions of NFS to handle ordinary numbers, this is judged to be a reasonable possibility by those working on NFS, so it is helpful to consider what impact this may have. It is conjectured (see the ACM STOC paper referenced above) that a successful extension of the NFS algorithm to ordinary numbers would have a running time of the form: exp(2.08 (ln n)^1/3 (ln ln n)^2/3) (2) This is similar to equation (1) except that the constant 1.56 is replaced by the constant 2.08. Note that a practical version of such an extension does NOT yet currently exist (to the best of my knowledge), but even granting its plausibility we arrive at an estimate of the tie required to factor a 512-bit number of 6.5 x 10^20 operations = 2 x 10^7 MIP-years which (in my opinion) is a substantial degree of security. It is interesting to note that this work factor is actually GREATER than that required by the ``standard'' factoring algorithms (e.g., the quadratic sieve), which have a running time of exp((ln n)^1/2 (ln ln n)^1/2); for a 512-bit number, this gives a work-factor estimate of only 6.7 x 10^19 operations. Indeed, the NFS algorithm (when extended) will be asymptotically superior than the quadratic sieve algorithm, but will be slower for numbers with less than about 200 digits. That is, assuming that (2) is indeed the correct running-time estimate for any extension of NFS, then NFS will not affect the security of any numbers of less than about 215 digits. So any "standards" that have been considered using 512-bit RSA moduli are not likely to be affected by any NFS extensions. (At most, one could imagine that the RSA key-generation process might be extended to check that the resulting modulus n is not a rarefied number.) In the truly worst-case scenario, we would have that an extension of NFS would be found that allows ordinary numbers to be factored with a work-factor that is governed by equation (1); in this case one would need to adjust the sizes of moduli used by RSA upwards by a factor of less than two to more than offset the new algorithm. A factor of two in size affects the running time of public-key encryption (or signature verification) by a factor of four and the running time of private-key encryption (or signature generation) by a factor of eight. Noting that the speed of workstations has increased by a factor of over 100 in the last decade (indeed, such factors have been the technological advance that made the successful implementation of NFS possible!), such performance penalties, if necessary, seem to be easily absorbed by expected technological advances in the speeds of the underlying RSA implementation technologies. That is, the NFS-like factoring algorithms do not, even in this worst-case scenario, prevent successful implementations of the RSA cryptosystem. As a cryptographer, I am actually very happy with all the effort that is being spent trying to determine the exact level of difficulty of factoring. Achievements such as the recent development of NFS help to pin down the best-possible rate of growth of the difficulty of factoring, so that users of cryptographic schemes can pick key sizes with an increased degree of confidence that unforeseen developments are unlikely to occur. The best way to ensure confidence in a cryptographic system is to have it attacked vigorously and continuously (but unsuccessfully) by well-qualified attackers. If, despite their best efforts, the difficulty of cracking the system remains intrinsically exponential, then one can have a reasonably high degree of confidence that the system is actually secure. This is the process we have been seeing at work in the recent work on factoring. The results of the attacks can be used to guide the selection of the necessary key size for a desired level of security (with an appropriate margin of safety built in, of course). (As a closing note, here's a prediction: I expect that the 128-digit ``challenge RSA cipher'' published in the August 1977 issue of Scientific American to be cracked (probably by the quadratic sieve algorithm or a variant, not NFS) during the next 1-3 years. This accomplishment will require substantially more computer time than the 275 MIP-years required to factor F9.)
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 01:01:22 GMT From: bishop@BEAR.DARTMOUTH.EDU (Matt Bishop) To: misc.security Subject: UNIX Security Workshop
I don't read this list, but the following message was pointed out to me:
> The organizer of the workshop is Matt Bishop, Dept of Mathematics &
> Computer Science, Bradley Hall, Dartmouth College, Hanover, NH 03755 (603)
> 646-2415
Here is the complete blurb, with the program and other relevant information.
If you have any questions, please contact me (Matt.Bishop@dartmouth.edu) or
the USENIX office. I'm handling the technical end (program, panels, etc.);
they are doing everything else (thank goodness!)
Matt
-----
UNIX Security Workshop
Marriott Hotel, Portland, OR, August 27-28, 1990
The Second USENIX UNIX Security Workshop will be held in Portland, Oregon
on Monday and Tuesday, August 27-28, 1990. The workshop is organized to bring
researchers, system administrators and others together to discuss their needs
and interests in the many aspects of computer security as they relate to the
UNIX Operating System.
This meeting will have elements of both a conference and a workshop; the
former in that there will be presentations, the latter in that discussion and
audience participation are expected. Speakers will discuss work in progress
and/or work that is planned and will solicit opinions, comments and sugges-
tions from other participants. There will be at least three panel sessions.
Tentative Program
Monday, August 27
9-10:30 Authentication I
David Goldberg, MITRE
The MITRE User Authentication System
Daniel Klein, Software Engineering Institute, CMU
A Survey of, and Improvements to, Password Security
Matt Bishop, Dartmouth College
An Extensible Password Changing Program
Michele Crabb, NASA Ames Research Center
Password Security in a Large Distributed Environment
11-12 Potpourri I
Maria Pozzo, UCLA Computer Science Dept.
An Automatic Policy Checker for Controlling Undesirable Program Behaviors
John Linn, DEC
Generic Security Service Application Program Interface
Henry Teng, DEC, and David Brown, Worchester Polytechnic Institute
An Expert Systems Approach to Security Inspection of UNIX
1:30-2:30 Secure Systems and Tools
Raymond Wong, Oracle
A Survey of Secure UNIX Operating Systems
David Gill, MITRE
Roles for Users and Privileges for System Processes:
High Trust Mechanisms for Low Trust Systems
Pat Bahn, GTE
Beyond Bell-LaPadula: A Security Model for Real Applications
3:00-5:00 Access Control
Marshall Abrams, Leonard LaPadula, & Ingrid Olson, MITRE
Building Generalized Access Control on UNIX
David Wichers, ARCA Systems, and Douglas Cook, Ronald Olsson, John Crossley,
Paul Kerchen, Karl Levitt, & Raymond Lo, University of California at Davis
An Access Control List Approach to Anti-Viral Security
Frank Kardel, Friedrich Alexander University
Frozen Files
Hermann Strack, University of Karlsruhe
to be arranged
Panel and discussion on access control
Tuesday, August 28
9-10:30 Authentication II
Ana Maria De Alvare, Lawrence Livermore National Laboratory
How Crackers Crack Passwords
Steven Lunt, Bellcore
Experiences with Kerberos
Joe Tardo, Kannan Alagappan, & Richard Pitkin, DEC
Public Key-based Authentication using Internet Certificates
Panel and discussion on authentication
11-12 Security Considerations and the Environment
Richard Neely, Ford Aerospace
System Design and Verification for Secure Applications Under UNIX
Gary Christoph, Los Alamos National Laboratory
Security Considerations of Going to a UNIX Based
Supercomputer Operating System
Bjorn Satdeva, /sys/admin, inc.
to be arranged
1:30-3:15 Networked Systems
Mark Carson, Janet Cugini, Sohail Malik, Mythili Kannan, & Wen-Der Jiang, IBM
Networked UNIX without the Superuser
Jeffrey Roth, Defense Logistics Agency
Hardening Anonymous FTP
Jerry Carlin, Pacific Bell
Gateway Security Measures
Eugene Schultz, Lawrence Livermore National Laboratory
UNIX Network Naivete
Panel and discussion on network security
3:45-5 Potpourri II
Fuat Baran, Howard Kaye, & Margarita Suarez, Columbia University
Security Breaches: Five Recent Incidents at Columbia University
Panel and discussion on security in Large installations
______________________________
Program Chair: Matt Bishop, Dept. of Mathematics & Computer Science, Dart-
mouth College
Full-time students please note: a limited number of scholarships are avail-
able. For an application form contact office@usenix.org
For registration information, contact:
USENIX Conference Office
22672 Lambert Street, Suite 613
El Toro, CA 92630
(714) 588-8649
(714) 588-9706 (FAX)
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 17 Jul 90 14:54:52 GMT From: pyron@skvax1.csc.ti.com (If Clayton's an Aggie, I'm not!) To: misc.security Subject: Re: Authentication of electronic commercial documents
>recently factored a 155 digit number, and that they are consequently
>recommending at least 200 digit primes for the RSA stuff.
The original article in CACM recommended 200 digit numbers, but made note of
the fact that factor these larges numbers was difficult, which is both a
blessing and a curse. Of course, difficult in 1977 is a breeze in 1991?
Dillon Pyron | The opinions are mine, the facts
TI/DSEG VAX Systems Support | probably belong to the company.
pyron@skvax1.ti.com |
(214)575-3087 | Jim Henson - Now that was talent
|
-----------[000042][next][prev][last][first]---------------------------------------------------- From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) 22-JUL-1990 1:42:32 To: security@pyrite.rutgers.edu
Has anybody heard about this, Sun's new NFS authentication system that uses public key encryption?
-----------[000043][next][prev][last][first]---------------------------------------------------- From: lorence@sctc.com (Len Lorence) 22-JUL-1990 10:55:42 To: misc-security@uunet.uu.net
>Can someone please show me what the different "security levels" mean in >terms of operating system. What I mean is one sees that "xxx's o/s is a >B2 rating". What is B2 and what are the different availale levels? What you want is a copy of the DOD Trusted Computer System Evaluation Criteria (DOD 5200.28-STD) from the National Computer Security Center. It sets the criteria for a system to meet each of the evaluation ratings (D, C1, C2, B1-3, and A1.) You also want a copy of the Evaluated Products List, available from the same people. You may be disappointed to find that there are not many products which have successfully made it through the evaluation process, and some that have are no longer available. Ask your librarian if they can get you copies, ask a friend who has a Dockmaster account, or write to NCSC. Len Lorence Secure Computing Technology Corp.
-----------[000044][next][prev][last][first]---------------------------------------------------- From: srt@grad19.cs.duke.edu (Stephen R. Tate) 22-JUL-1990 11:19:51 To: misc-security@mcnc.org
> RSA is an interesting question. I heard that some mathematician > recently factored a 155 digit number, and that they are consequently > recommending at least 200 digit primes for the RSA stuff. AARRGGHH!!! You would not believe how many people I have heard say this lately, and is proof that a little information is a dangerous thing. The "popular press" (Washington Post, New York Times,...) ran a story saying exactly the above, so it's no wonder that people have this impression. Now the REAL story: the number factored was of a very special form, and the algorithm used excelled for numbers of that form (in fact, the algorithm was originally developed *only* for numbers of that form). The RSA algorithm does not use numbers of this form (it uses the product of two randomly generated large primes), and so public keys of the form used by RSA are in NO DANGER from the new algorithm. Steve Tate ARPA: srt@duke.cs.duke.edu UUCP: ..!decvax!duke!srt
-----------[000045][next][prev][last][first]---------------------------------------------------- From: nagle@well.sf.ca.us (John Nagle) 22-JUL-1990 11:49:15 To: misc-security@uunet.uu.net
>Basically, Iwould like to know if there has been any work on MVS and/or CMS
>platforms to keep users from picking obvious passwords, like their name,
I first posted a simple solution to this problem back in 1984. The
technique used does not require any dictionary or large tables; it relies
on some statistics of letter sequence usage in English which allow one to
determine whether something is a likely English word. The code can be obtained
from the comp.sources.unix archive, or I can send a copy to interested parties.
The code is in C, but there is no UNIX dependency; in fact, I wrote the
original code on a DECsystem 2060, in C. The archive reference appears below.
John Nagle
Newsgroups: comp.sources.unix
Subject: v16i060: Tell if a password is "obvious"
Date: 10 Nov 88 14:47:09 GMT
Submitted-by: "John B. Nagle" <jbn@glacier.stanford.edu>
Posting-number: Volume 16, Issue 60
Archive-name: obvious-pw
[ This program does NOT try brute-force methods to guess passwords,
but instead tells if a password is an "obvious" one likely to be
guessed by such a program. ]
-----------[000046][next][prev][last][first]---------------------------------------------------- From: Will Martin <wmartin@stl_06sima.army.mil> 22-JUL-1990 12:13:13 To: owen blevins <blevinso@silver.ucs.indiana.edu> Cc: security@pyrite.rutgers.edu
Here in St. Louis, getting a copy of your "criminal record" or police record is part of the pistol-permit process. It appears there is no restriction on any individual getting a copy; it costs $10 and I suppose it is a nice source of extra income for the city or the department. All you need is $10 cash or money order (no checks) and ID, like a drivers license. You go to an office at the main downtown police station and fill out a short request form, and hand over your ID & money. They keep the money and give back the ID. :-) You wait 10 minutes or so. If you have no record, all you get in return is a form with a big purple stamp on it that says something like "NO RECORD FOUND". If you have a record, you get some sort of printout with the data on it. (All I got back was the stamped form, so I can't offer details on what a record-printout is like... :-) Most of the other people there getting records seemed to be getting them for security-guard job applications. Regards, Will Martin
-----------[000047][next][prev][last][first]---------------------------------------------------- From: fitz@wang.com (Tom Fitzgerald) 22-JUL-1990 12:38:39 To: misc-security@uunet.uu.net
> Because any measurement attempted by a third party would > unpredictably alter a photon's polarization, an eavesdropper couldn't > intercept the transmission without irrevocably scrambling the message I don't see how this really gains you anything. An eavesdropper can still get in by cutting the line and putting in a complete receiver/transmitter station. The legitimate receiver will never see any tapped bits because they can all be completely regenerated by the eavesdropper's transmitter. Under some circumstances, the eavesdropper might have to receive a complete message and do whatever ECC is necessary to compensate for the 50% error rate on the line before forwarding the message on, but the legitimate receiver should never know the difference. > To check for eavesdropping, the receiver would simply > compare notes with the sender This implies an out-of-band communication. If you have such a thing in the first place, why use quantum signalling? If the comparisons are going over the quantum link, the eavesdropper can modify them in transit to hide his own presence. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
-----------[000048][next][prev][last][first]---------------------------------------------------- From: mccurley@cs.sandia.gov (Kevin McCurley) 22-JUL-1990 13:01:13 To: security@pyrite.rutgers.edu
The recent factorization of a 155 digit number was a remarkable feat, but it holds less interest for RSA than meets the eye. The number that was factored was 2^512+1. This number has binary representation 100000000000000000000000 ... 00000000000000000000001 which is of course rather special. In fact, the method at present works only for numbers of a very special form, and a much better gauge of current factoring progress is provided by the RSA challenge number that was published in Scientific American years ago. This number has "only" 129 decimal digits, but it has never been factored, in spite of the obvious publicity that would result from this. It is estimated that the RSA challenge number might take 10 times as much work to factor as the 155 digit number factored recently. The moral of the story is that as a result of many people working on the problem, we have seen a steady improvement in what numbers can be factored. We are NOT yet to a point where generic 155 digit numbers can be factored, but future advances may allow us to do so. If it's a question of adopting a system for which the modulus must be good for ten years, then I might be skeptical about a 155 digit modulus. For a 200 digit modulus, we will need a significant new idea to be able to factor those. We stand a far greater risk from a total collapse of the banking system! Kevin McCurley
-----------[000049][next][prev][last][first]----------------------------------------------------
Date: 23 Jul 90 13:37:32 GMT
From: ah0i+@ANDREW.CMU.EDU ("Andrew A. Houghton")
To: misc.security
Subject: locksmithing schoolsI know this subject has probably been run into the ground, but could people please send me the addresses for good locksmithing schools, along with any thoughts they have about them (like relative merits, etcetera) Please e-mail, no need to post on the net. Andrew Houghton (ah0i@andrew.cmu.edu)
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 23 Jul 90 15:42:12 GMT From: de5@STC06.CTD.ORNL.GOV (SILL D E) To: misc.security Subject: Re: Authentication of electronic commercial documents
>Now the REAL story: the number factored was of a very special form, AARRGGHH!! Apparently you missed the recently posted article (comp.risks?) by Ron Rivest (the `R' in RSA) that gave the REAL story. Actually, both of the above posters are (in)correct. The number factored was of the form 10000...00001 (binary). Such numbers are used by RSA only by coincidence, that is to say very rarely. Rivest further conjectured that that and other developments in factoring would lead to the breaking of some short-key RSA within a couple years, I believe (this is from memory, I forget the numbers). He also said they were recommending longer keys for paranoids...er... folks wanting utmost security. Anybody save that article? How 'bout posting it or sending me a copy? -- -- Dave Sill (de5@ornl.gov) These are my opinions. Martin Marietta Energy Systems Workstation Support
-----------[000051][next][prev][last][first]---------------------------------------------------- From: UCCXNCS@osucc.bitnet 26-JUL-1990 6:45:00 To: security@ohstvma.bitnet
Since userid maintenance and security seem to go hand-in-hand, I thought I might be able to get some ideas on how to go about attacking a problem we are facing here at OSU. If you know of a list that addresses this sort of thing, please let me know. Userid creation and maintenance is one of our biggest headaches. We have an IBM 3090 on which we run VM/SP with MVS running as a guest under it. The MVS system is used mainly by our administrative users. We have only had VM a few months and are wanting to open it up to our academic users who, for the most part, abhor MVS and JCL. The idea is for the VM system to be "friendlier", not requiring password changes, etc. So, we are looking for ideas on how to automate the setup and maintenance of permanent (faculty) and temporary (student) userids on the VM system. Right now we are managing the few VM userids that we have set up through DIRMAINT. However, we do have VMSECURE setting on the shelf. It seems to me that DIRMAINT is rather cumbersome, and I'm not sure how we could set up an automated process that would create several hundred userids using DIRMAINT. Anyone that has dealt with this problem and would be willing to give us some suggestions is welcome to respond. Nancy C. Stevens (405) 744-6301 uccxncs@osucc.bitnet
-----------[000052][next][prev][last][first]---------------------------------------------------- From: Hoffman.es@xerox.com 26-JUL-1990 7:13:40 To: SECURITY@rutgers.edu
[Moderator injection: Apologies to those who have already seen this sixteen
times, but there might be folks out there who haven't yet. Use your D key
or local equivalent. _H*]
COMPUTER PROFESSIONALS FOR SOCIAL RESPONSIBILITY
PRESS RELEASE
Embargoed for release on July 10, 1990
CPSR TO UNDERTAKE EXPANDED CIVIL LIBERTIES PROGRAM
CPSR, a national computing organization, announced today that it would
receive a two-year grant in the amount of $275,000 for its Computing and
Civil Liberties Project. The Electronic Frontier Foundation, founded by
Mitchell Kapor and John Barlow, made the grant to expand ongoing CPSR
work on civil liberties protections for computer users.
At a press conference in Washington today, Mr. Kapor praised CPSR's
work. "CPSR plays an important role in the computer community. For the
last several years, it has sought to extend civil liberties protections
to new information technologies. Now we want to help CPSR expand that
work."
Marc Rotenberg, director of the CPSR Washington Office said, "We are
obviously very happy about the grant from the EFF. There is a lot of
work that needs to be done to ensure that our civil liberties
protections are not lost amidst policy confusion about the use of new
computer technologies."
CPSR said that it will host a series of policy round tables in
Washington, DC, during the next two years with lawmakers, computer users
including "hackers," the FBI, industry representatives, and members of
the computer security community. Mr. Rotenberg said that the purpose of
the meetings will be to "begin a dialogue about the new uses of
electronic media and the protection of the public interest."
CPSR also plans to develop policy papers on computers and civil
liberties, to oversee the Government's handling of computer crime
investigations, and to act as an information resource for organizations
and individuals interested in civil liberties issues.
The CPSR Computing and Civil Liberties project began in 1985 after
President Reagan attempted to restrict access to government computer
systems through the creation of new classification authority. In 1988
CPSR prepared a report on the proposed expansion of the FBI's computer
system, the National Crime Information Center. The report found serious
threats to privacy and civil liberties. Shortly after the report was
issued, the FBI announced that it would drop a proposed computer feature
to track the movements of people across the country who had not been
charged with any crime.
"We need to build bridges between the technical community and the policy
community," said Dr. Eric Roberts, CPSR President and a research
scientist at Digital Equipment Corporation in Palo Alto, California.
"There is simply too much misinformation about how computer networks
operate. This could produce terribly misguided public policy."
CPSR representatives have testified several times before Congressional
committees on matters involving civil liberties and computer policy.
Last year CPSR urged a House Committee to avoid poorly conceived
computer crime laws that could criminalize a wide range of computer
activity. "In the rush to criminalize the malicious acts of the few we
may discourage the beneficial acts of the many," warned CPSR. A House
subcommittee recently followed CPSR's recommendations on computer crime
amendments.
Dr. Ronni Rosenberg, an expert on the role of computer scientists and
public policy, praised the new initiative. She said, "It's clear that
there is an information gap that needs to be filled. This an important
opportunity for computer scientists to help fill that gap."
CPSR is a national membership organization of computer professionals,
based in Palo Alto, California. CPSR has over 2,000 members and 21
chapters across the country. In addition to the civil liberties
project, CPSR conducts research, advises policy makers and educates the
public about computers in the workplace, computer risk and reliability,
and international security.
For more information contact:
Marc Rotenberg
CPSR Washington Office
1025 Connecticut Avenue NW
Suite 1015
Washington, DC 20036
(202) 775-1588
Gary Chapman
CPSR National Office
P.O. Box 717
Palo Alto, CA 94302
(415) 322-3778
-----------[000053][next][prev][last][first]---------------------------------------------------- From: corey@esl.com (Corey Yee) 27-JUL-1990 12:17:55 To: misc-security@ames.arc.nasa.gov
There's an article titled "Certifying A System's Security" in the June 25th edition of "Unix Today!" that discusses the NCSC security ratings.
-----------[000054][next][prev][last][first]---------------------------------------------------- From: Don Irmiger <don@delta.com> 27-JUL-1990 12:42:23 To: SECURITY@ohstvma.ircc.ohio-state.edu
These are rating systems per the DOD as defined in "the Orange Book". UNIX Sys V is classified at a C2 rating (poor). Some O/S extensions can improve this to about B2-B1. I've not heard of an out-of-the-box implementation in the A classification... -- Donald K. Irmiger III UUCP: uunet!delta.com!don Data Systems Coordinator Internet: don@delta.com Michiana Rehabilitation Institute's Data Systems Center \ Altos 2086/Xenix 3.4b
-----------[000055][next][prev][last][first]---------------------------------------------------- From: Matt Bishop <bishop@bear.dartmouth.edu> 27-JUL-1990 13:06:22 To: security@marist.bitnet
I don't read this list, but the following message was pointed out to me:
> The organizer of the workshop is Matt Bishop, Dept of Mathematics &
> Computer Science, Bradley Hall, Dartmouth College, Hanover, NH 03755 (603)
> 646-2415
Here is the complete blurb, with the program and other relevant information.
If you have any questions, please contact me (Matt.Bishop@dartmouth.edu) or
the USENIX office. I'm handling the technical end (program, panels, etc.);
they are doing everything else (thank goodness!)
Matt
-----
UNIX Security Workshop
Marriott Hotel, Portland, OR, August 27-28, 1990
The Second USENIX UNIX Security Workshop will be held in Portland, Oregon
on Monday and Tuesday, August 27-28, 1990. The workshop is organized to bring
researchers, system administrators and others together to discuss their needs
and interests in the many aspects of computer security as they relate to the
UNIX Operating System.
This meeting will have elements of both a conference and a workshop; the
former in that there will be presentations, the latter in that discussion and
audience participation are expected. Speakers will discuss work in progress
and/or work that is planned and will solicit opinions, comments and sugges-
tions from other participants. There will be at least three panel sessions.
Tentative Program
Monday, August 27
9-10:30 Authentication I
David Goldberg, MITRE
The MITRE User Authentication System
Daniel Klein, Software Engineering Institute, CMU
A Survey of, and Improvements to, Password Security
Matt Bishop, Dartmouth College
An Extensible Password Changing Program
Michele Crabb, NASA Ames Research Center
Password Security in a Large Distributed Environment
11-12 Potpourri I
Maria Pozzo, UCLA Computer Science Dept.
An Automatic Policy Checker for Controlling Undesirable Program Behaviors
John Linn, DEC
Generic Security Service Application Program Interface
Henry Teng, DEC, and David Brown, Worchester Polytechnic Institute
An Expert Systems Approach to Security Inspection of UNIX
1:30-2:30 Secure Systems and Tools
Raymond Wong, Oracle
A Survey of Secure UNIX Operating Systems
David Gill, MITRE
Roles for Users and Privileges for System Processes:
High Trust Mechanisms for Low Trust Systems
Pat Bahn, GTE
Beyond Bell-LaPadula: A Security Model for Real Applications
3:00-5:00 Access Control
Marshall Abrams, Leonard LaPadula, & Ingrid Olson, MITRE
Building Generalized Access Control on UNIX
David Wichers, ARCA Systems, and Douglas Cook, Ronald Olsson, John Crossley,
Paul Kerchen, Karl Levitt, & Raymond Lo, University of California at Davis
An Access Control List Approach to Anti-Viral Security
Frank Kardel, Friedrich Alexander University
Frozen Files
Hermann Strack, University of Karlsruhe
to be arranged
Panel and discussion on access control
Tuesday, August 28
9-10:30 Authentication II
Ana Maria De Alvare, Lawrence Livermore National Laboratory
How Crackers Crack Passwords
Steven Lunt, Bellcore
Experiences with Kerberos
Joe Tardo, Kannan Alagappan, & Richard Pitkin, DEC
Public Key-based Authentication using Internet Certificates
Panel and discussion on authentication
11-12 Security Considerations and the Environment
Richard Neely, Ford Aerospace
System Design and Verification for Secure Applications Under UNIX
Gary Christoph, Los Alamos National Laboratory
Security Considerations of Going to a UNIX Based
Supercomputer Operating System
Bjorn Satdeva, /sys/admin, inc.
to be arranged
1:30-3:15 Networked Systems
Mark Carson, Janet Cugini, Sohail Malik, Mythili Kannan, & Wen-Der Jiang, IBM
Networked UNIX without the Superuser
Jeffrey Roth, Defense Logistics Agency
Hardening Anonymous FTP
Jerry Carlin, Pacific Bell
Gateway Security Measures
Eugene Schultz, Lawrence Livermore National Laboratory
UNIX Network Naivete
Panel and discussion on network security
3:45-5 Potpourri II
Fuat Baran, Howard Kaye, & Margarita Suarez, Columbia University
Security Breaches: Five Recent Incidents at Columbia University
Panel and discussion on security in Large installations
______________________________
Program Chair: Matt Bishop, Dept. of Mathematics & Computer Science, Dart-
mouth College
Full-time students please note: a limited number of scholarships are avail-
able. For an application form contact office@usenix.org
For registration information, contact:
USENIX Conference Office
22672 Lambert Street, Suite 613
El Toro, CA 92630
(714) 588-8649
(714) 588-9706 (FAX)
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 26 Jul 90 14:28:00 GMT From: EVERHART@arisia.dnet.ge.com To: misc.security Subject: "secure nfs"
If looking for a secure distributed file system, I'd suggest checking out AFS, from Transarc. It uses Kerebros authentication, and supplies tools for maintenance of large networks. It was designed for 10,000+ workstation environments and scales much better than NFS; also tends to avoid eating networks for lunch as NFS can and does. Transarc is in Pittsburgh; 412 338 4400; their domain name is transarc.com. Glenn
-----------[000057][next][prev][last][first]---------------------------------------------------- From: "Richard B. August" <AUGUST@vlsi.jpl.nasa.gov> 28-JUL-1990 10:11:24 To: SECURITY-REQUEST@pyrite.rutgers.edu
In a posting, sometime within the last couple of years, there was mention of the existence of an article purported to have been published in the Soviet Academy of Applied Sciences. The posting went on to describe how someone at this Academy had developed a "table" with which one could break DES. This subject came up recently and I "quoted" the posting. Naturaly those skeptics in the audience want "proof". If anyone out there remembers the posting or (even better) the publication in which this appeared, please let me know. Thanks in advance. Richard B. August august@vlsi.jpl.nasa.gov
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 27 Jul 90 17:28:04 GMT From: tep@tots.logicon.com (Tom Perrine) To: misc.security Subject: cheap Master combo lock
I have one of those cheap Master combination locks that I need to remove, and the combination is long gone. The options I can think of are (in order of preference): get combination from Master (from serial number) bolt cutters hacksaw Of course, the cheaper the better, so a locksmith is out. I'm not in any hurry, can I just call (or write) to Master and get the combination? I really don't care about the lock, but if I can get the combo, thats easier than finding some bolt cutters or spending an hour? with a hacksaw.... Any recommendations? Tom Perrine (tep)
-----------[000059][next][prev][last][first]---------------------------------------------------- From: nitrex!rbl@uunet.uu.net ( Dr. Robin Lake ) 1-AUG-1990 22:22:09 To: misc-security@uunet.uu.net
It is possible to write to the FBI and ask them if they have a folder on you and to send you a copy of the contents of the folder if the folder does exist.
-----------[000060][next][prev][last][first]---------------------------------------------------- From: *Hobbit* <security_request@pyrite.rutgers.edu> 1-AUG-1990 23:43:16 To: security@pyrite.rutgers.edu
[Crunched into a "digest" to save a little network bandwidth. _H*]
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 19 Jun 90 11:49:49 GMT
From: Doug Gwyn <gwyn@smoke.brl.mil>
To: misc-security@rutgers.edu
The solution is so obvious that I wonder that you don't see it --
Stop gratuitously requiring people to change their passwords.
If the password is not thought to have been compromised, there
is more reason to continue using it than to change it.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 19 Jun 90 20:08:41 GMT
From: levine@csd4.csd.uwm.edu (Leonard P Levine)
To: misc-security@uunet.uu.net
I carefully examied the material on making Unix more secure (Improving the
security of your Unix System by David Curry, SRI International) in hopes
of finding just why changing the password makes a system secure. Curry's
well thought out work has many good suggestions but he says about changing
passwords only the following: (page 7)
"Finally it is important to establish a policy that users must change
their passwords from time to time, say twice a year."
He gives no reason for such a need, although all of the other problems
he discusses are couched in terms of speed of cracking and methods of
penetration.
He (correctly) points out that users should never write down their
passwords, should not use easy to guess words, and the like, but somehow
feels that a user who has a good password, who never allows him/herself
to be observed logging in, who sees no history of problems, should
nevertheless change the password fairly often.
Why twice a year? Why not twice a day? I think it would be better
to have a good password that you do not have to write down because
you know it (from long and careful use) than to have a password
that you write down because you easily forget it, or to have a
password that is easy to crack because you do not want to write it
down.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Wed, 20 Jun 1990 10:19:42 +0200
From: "UFOBI2::RMEYER" <U0018@dgogwdg5.bitnet>
To: security@pyrite.rutgers.edu
I know some people, who change their password like:
blahmmyy
blah = 4 character unique password
mm = month
yy = year
( or blmmyyyy, yymmblah, ........)
I think it's better, if they changed the password sometimes to
a "really new" password. Password lifetime must be long. A user
should have a chance to use an old password again, if she/he thinks
that it is not known to other people.
If the expiring period is short an you cannot use the same password
again, people will write their password on a piece of paper....
This is the real problem.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Thu, 21 Jun 90 13:05 EDT
From: Kilgallen@dockmaster.ncsc.mil
To: hobbit@pyrite.rutgers.edu
Well I am not in an environment which requires dealing with academic freedom,
but it would seem simply a matter of offering the alternative of signing a
form in which they agree to financial liability to any damage to the computer
system (including time and effort to repair) due to break-ins over their
account.
By the way DEC says they have fixed this problem (with a password history
file consulted by the Set Password command) in VMS V5.4. For those who
use Unix, presumably the answer is to write your own modifications to Unix
following that model.
As a security practice, I would say you should *never* tolerate people
changing their password back to the same thing. If you think keeping a
password for a long period of time is permissible, then change your
permissible password lifetime parameter. To set a short lifetime and
then permit people getting around it (look for two successive password
changes in the pre-V5.4 VMS audit alarms), just sends the message that
system administrators are not serious about the rules they lay down.
It is better to change the rules.
Larry Kilgallen
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Sun, 1 Jul 90 21:17:44 EST
From: Don Irmiger <don@delta.com>
To: SECURITY@ohstvma.ircc.ohio-state.edu
> I have heard the argument made that forcing frequent password changes is
> counterproductive
I agree with the counterproductive argument. I'm running a Unix box which
allows the user to reset their own passwords. If I were more sensitive, this
would be restricted to system administrator use. I've used two methods of
password generation:
1) alternating series of consonants and vowels. This produces only
marginally pronouncable passwords, but served its purposes. Most
users made written copies which is frowned upon as a whole.
2) an english word of 3-4 characters in length, a digit(0-9), and
another English word of 4-3 characters in length. My Unix box
only allows 8 character max passwords and this satifies it. I
choose the words randomly the the set of 3-4 character words in
my spelling checker dictionaly (/usr/dict/words). I wrote a
program that generated about 200 of them (40 users on my box)
and I pick the topmost from the list, assign it and delete the
line from the file (highly restricted access to the file, BTW).
Particularly with naive users, you have to *stress* that these passwords
are priviledged bits of information as they should not be distributed or
shared in any way. I can't hold them responsible for security flaws if they
don't know the rules...
--
Donald K. Irmiger III UUCP: uunet!delta.com!don
Data Systems Coordinator Internet: don@delta.com
Michiana Rehabilitation Institute's Data Systems Center \ Altos 2086/Xenix 3.4b
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Tue, 3 Jul 90 22:08:48 EDT
From: retants@rodan.acs.syr.edu
Just to pass along my experience with the password generators, we had
a lot of people writing things down. the ones that didn't would spend
literally hours flipping through the password generator until it came
up with something vaguely english (example being SUNNDUG...not a real
world, but something easy to remember). THis was a waste of time in
general, but which is worse...writing down passwords or spending an
hour finding one that can be remembered.
one suggestion made was that each time a person changed thier password,
they were given a randomized number for the space they had to put a
numeral into. example: place a number as the 6 character of a password.
then the person could make up a password, and the system would check
to make sure that 1) there was a number in the 6th position, and 2) it
was not the same number as the position number. Passwords would look
like DOGHO1USE which is easy to remember as a word that you add your
number to, and a bit harder to break.
any comments on that one?
Becki Tants RETANTS@SUNRISE.BITNET RETANTS@RODAN.ACS.SYR.EDU
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Mon, 23 Jul 90 22:58:00 EST
From: zik@bruce.cs.monash.oz.au (Michael Saleeba)
To: misc-security@munnari.oz.au
On the subject of passord checking, I am doing a project on password
security for my honours comp. sci. unit "Security in Computing". I'd
be grateful if anyone with password guessing or checking programs
would sendfile them to me or direct me to the appropriate archives.
Also, I'd welcome any general comments that people have on password
security and its flaws.
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 31 Jul 90 23:40:06 GMT From: security-request@PYRITE.RUTGERS.EDU (*Hobbit*) To: misc.security Subject: Leftover msgs about password expiration
[Crunched into a "digest" to save a little network bandwidth. _H*]
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 19 Jun 90 11:49:49 GMT
>From: Doug Gwyn <gwyn@smoke.brl.mil>
To: misc-security@rutgers.edu
The solution is so obvious that I wonder that you don't see it --
Stop gratuitously requiring people to change their passwords.
If the password is not thought to have been compromised, there
is more reason to continue using it than to change it.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 19 Jun 90 20:08:41 GMT
>From: levine@csd4.csd.uwm.edu (Leonard P Levine)
To: misc-security@uunet.uu.net
I carefully examied the material on making Unix more secure (Improving the
security of your Unix System by David Curry, SRI International) in hopes
of finding just why changing the password makes a system secure. Curry's
well thought out work has many good suggestions but he says about changing
passwords only the following: (page 7)
"Finally it is important to establish a policy that users must change
their passwords from time to time, say twice a year."
He gives no reason for such a need, although all of the other problems
he discusses are couched in terms of speed of cracking and methods of
penetration.
He (correctly) points out that users should never write down their
passwords, should not use easy to guess words, and the like, but somehow
feels that a user who has a good password, who never allows him/herself
to be observed logging in, who sees no history of problems, should
nevertheless change the password fairly often.
Why twice a year? Why not twice a day? I think it would be better
to have a good password that you do not have to write down because
you know it (from long and careful use) than to have a password
that you write down because you easily forget it, or to have a
password that is easy to crack because you do not want to write it
down.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Wed, 20 Jun 1990 10:19:42 +0200
>From: "UFOBI2::RMEYER" <U0018@dgogwdg5.bitnet>
To: security@pyrite.rutgers.edu
I know some people, who change their password like:
blahmmyy
blah = 4 character unique password
mm = month
yy = year
( or blmmyyyy, yymmblah, ........)
I think it's better, if they changed the password sometimes to
a "really new" password. Password lifetime must be long. A user
should have a chance to use an old password again, if she/he thinks
that it is not known to other people.
If the expiring period is short an you cannot use the same password
again, people will write their password on a piece of paper....
This is the real problem.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Thu, 21 Jun 90 13:05 EDT
>From: Kilgallen@dockmaster.ncsc.mil
To: hobbit@pyrite.rutgers.edu
Well I am not in an environment which requires dealing with academic freedom,
but it would seem simply a matter of offering the alternative of signing a
form in which they agree to financial liability to any damage to the computer
system (including time and effort to repair) due to break-ins over their
account.
By the way DEC says they have fixed this problem (with a password history
file consulted by the Set Password command) in VMS V5.4. For those who
use Unix, presumably the answer is to write your own modifications to Unix
following that model.
As a security practice, I would say you should *never* tolerate people
changing their password back to the same thing. If you think keeping a
password for a long period of time is permissible, then change your
permissible password lifetime parameter. To set a short lifetime and
then permit people getting around it (look for two successive password
changes in the pre-V5.4 VMS audit alarms), just sends the message that
system administrators are not serious about the rules they lay down.
It is better to change the rules.
Larry Kilgallen
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Sun, 1 Jul 90 21:17:44 EST
>From: Don Irmiger <don@delta.com>
To: SECURITY@ohstvma.ircc.ohio-state.edu
> I have heard the argument made that forcing frequent password changes is
> counterproductive
I agree with the counterproductive argument. I'm running a Unix box which
allows the user to reset their own passwords. If I were more sensitive, this
would be restricted to system administrator use. I've used two methods of
password generation:
1) alternating series of consonants and vowels. This produces only
marginally pronouncable passwords, but served its purposes. Most
users made written copies which is frowned upon as a whole.
2) an english word of 3-4 characters in length, a digit(0-9), and
another English word of 4-3 characters in length. My Unix box
only allows 8 character max passwords and this satifies it. I
choose the words randomly the the set of 3-4 character words in
my spelling checker dictionaly (/usr/dict/words). I wrote a
program that generated about 200 of them (40 users on my box)
and I pick the topmost from the list, assign it and delete the
line from the file (highly restricted access to the file, BTW).
Particularly with naive users, you have to *stress* that these passwords
are priviledged bits of information as they should not be distributed or
shared in any way. I can't hold them responsible for security flaws if they
don't know the rules...
--
Donald K. Irmiger III UUCP: uunet!delta.com!don
Data Systems Coordinator Internet: don@delta.com
Michiana Rehabilitation Institute's Data Systems Center \ Altos 2086/Xenix 3.4b
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Tue, 3 Jul 90 22:08:48 EDT
>From: retants@rodan.acs.syr.edu
Just to pass along my experience with the password generators, we had
a lot of people writing things down. the ones that didn't would spend
literally hours flipping through the password generator until it came
up with something vaguely english (example being SUNNDUG...not a real
world, but something easy to remember). THis was a waste of time in
general, but which is worse...writing down passwords or spending an
hour finding one that can be remembered.
one suggestion made was that each time a person changed thier password,
they were given a randomized number for the space they had to put a
numeral into. example: place a number as the 6 character of a password.
then the person could make up a password, and the system would check
to make sure that 1) there was a number in the 6th position, and 2) it
was not the same number as the position number. Passwords would look
like DOGHO1USE which is easy to remember as a word that you add your
number to, and a bit harder to break.
any comments on that one?
Becki Tants RETANTS@SUNRISE.BITNET RETANTS@RODAN.ACS.SYR.EDU
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Mon, 23 Jul 90 22:58:00 EST
>From: zik@bruce.cs.monash.oz.au (Michael Saleeba)
To: misc-security@munnari.oz.au
On the subject of passord checking, I am doing a project on password
security for my honours comp. sci. unit "Security in Computing". I'd
be grateful if anyone with password guessing or checking programs
would sendfile them to me or direct me to the appropriate archives.
Also, I'd welcome any general comments that people have on password
security and its flaws.
END OF DOCUMENT
| ISSN 1742-948X |