|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1990)
DOCUMENT: Rutgers 'Security List' for June 1990 (58 messages, 35024 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 90 04:30:21 GMT From: annala@NEURO.USC.EDU (A J Annala) To: misc.security Subject: Re: Security and Masterkeys
> Has anyone, as an exercise, tried to make a very highly protected area? Yes, we put the crypto equipment in a large double steel door enclosed steel box suspended on huge shock absorbers and placed a double 24 hour marine guard with automatic weapons at the entrance with shoot to kill and ask questions later orders. To my knowledge no unauthorized people ever even tried to get into the crypto vault.
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Jun 90 18:29:47 EDT From: wcs@erebus.att.com (William Clare Stewart) To: security@rutgers.edu Subject: Re: abolishing /etc/passwd
/etc/passwd has become the traditional location for user-info other than passwords, so of course it needs to be kept, but I agree with the shadow-password approach that puts (encrypted) passwords in a non-world-readable file. Yes, this means that YOUR software can't use the real password, but this is good - I'm not going to trust my real password to non-system software, because of the increased risk of trojan horses and insecurity; terminal-lockers and such get their own passwords. ]If DES is breakable, then a new algorithm needs to be implemented. And ]users should be encouraged to choose good passwords, otherwise it ]doesn't matter what encryption mechanism is used. The point of the modified-DES used by UNIX is that it isn't the same as the real DES, so a real-DES breaker won't work, and a fast hardware implementation of real-DES will make it hard to search for obvious passwords. Unfortunately, though, people have gotten 10-fold speedups in password encryption through software, and hardware is 1-2 orders of magnitude faster than the old PDP-11 days (much more, if you have a network of machines to bum cycles off of). So DES isn't real secure enough either, given readable passwords. -- Thanks; Bill # Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs # Actually, it's *two* drummers, and we're not marching, we're *dancing*. # But that's the general idea.
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 4 Jun 90 22:29:47 GMT From: wcs@erebus.att.com (William Clare Stewart) To: misc.security Subject: Re: abolishing /etc/passwd
/etc/passwd has become the traditional location for user-info other than passwords, so of course it needs to be kept, but I agree with the shadow-password approach that puts (encrypted) passwords in a non-world-readable file. Yes, this means that YOUR software can't use the real password, but this is good - I'm not going to trust my real password to non-system software, because of the increased risk of trojan horses and insecurity; terminal-lockers and such get their own passwords. ]If DES is breakable, then a new algorithm needs to be implemented. And ]users should be encouraged to choose good passwords, otherwise it ]doesn't matter what encryption mechanism is used. The point of the modified-DES used by UNIX is that it isn't the same as the real DES, so a real-DES breaker won't work, and a fast hardware implementation of real-DES will make it hard to search for obvious passwords. Unfortunately, though, people have gotten 10-fold speedups in password encryption through software, and hardware is 1-2 orders of magnitude faster than the old PDP-11 days (much more, if you have a network of machines to bum cycles off of). So DES isn't real secure enough either, given readable passwords. -- Thanks; Bill # Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs # Actually, it's *two* drummers, and we're not marching, we're *dancing*. # But that's the general idea.
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Tue, 05 Jun 90 16:51 CDT From: UCCXNCS@osucc.bitnet To: security@ohstvma.bitnet Subject: Expiring passwords
I was interested in the message about users who deliberately
changed their password several times so they could use
the same password again. Here at Oklahoma State we have
met with a lot of resistance from faculty who do not even
like the idea of having their passwords expire, much less
not being able to use the same one again. They seem to
think that having to change their passwords periodically
restricts their academic freedom or something. I wonder
if any other computing centers out there have the same
problem, and if you do, how do you handle it?
Nancy Stevens - Oklahoma State University
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 90 21:51:00 GMT From: UCCXNCS@osucc.BITNET To: misc.security Subject: Expiring passwords
I was interested in the message about users who deliberately
changed their password several times so they could use
the same password again. Here at Oklahoma State we have
met with a lot of resistance from faculty who do not even
like the idea of having their passwords expire, much less
not being able to use the same one again. They seem to
think that having to change their passwords periodically
restricts their academic freedom or something. I wonder
if any other computing centers out there have the same
problem, and if you do, how do you handle it?
Nancy Stevens - Oklahoma State University
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 90 08:54:09 GMT From: annala@NEURO.USC.EDU (A J Annala) To: misc.security Subject: Re: Opening a safe by manipulation
> (And Group I R are also proof against radiological attack - i.e., they have > plastic wheels so they can't be X-rayed.) Maybe they can't be x-rayed ... but they can be attacked with fast neutron activation analysis, magnetic resonance imaging, etc ... don't assume you can't image the tumblers because they can't be x-rayed ... of course, most spy types would rather compromise someone with access to a safe rather than try to get into the safe themselves.
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Jun 90 22:27 PDT From: "Ned Freed, Postmaster" <NED@hmcvax.claremont.edu> To: security@pyrite.rutgers.edu, blount@media-lab.media.mit.edu Subject: Re: a new scam
It's been done before, pretty much as you described. The article I saw was
on the RISKS Digest some time back. It may have also appeared in this
newsgroup as well.
Some details:
(1) The fake machine was built in front of the real one, which if done
in an inobvious manner insures a lot of "clientele" - the regular users.
(2) I believe the machine swallowed the cards completely, saying that it
was confiscating them or some such. This saves the trouble of getting
a card reader operational.
I don't recollect where this occurred. I don't keep such details handy.
It wasn't here in Claremont, CA -- I would have remembered *that*.
All in all, given the limit on the amount of cash dispensed per card, it
does not sound like a very effective scam. Better to rip off/out the whole
machine, as some have done. My recollection is that the amount reported
stolen was large enough to make it cost-effective but not stunningly so.
An interesting question -- is this sort of thing a white or blue collar
type of crime? I recently heard a statistic comparing the amount stolen
in your basic blue collar bank robbery (peanuts), white collar robbery
(i.e. fraud, in the millions), the chances of getting caught (blue collar
quite high, white collar quite low), and the penalties if caught (blue collar
quite severe, white collar quite lenient). In view of the active nature of
such a crime, it comes across like a stickup. But it is quite clever...
like a clever scheme for fraud. Thoughts?
Ned Freed
Innosoft International, Inc.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Thu, 07 Jun 90 10:09:27 -0500 From: nugent@gargoyle.uchicago.edu To: misc-security@uunet.uu.net Cc: strick@osc.com (HAR56) Subject: Re: Best Locks
One University I attended had the policy that the master key was always the deepest key cut. If you took apart a multi-keyed cylinder and made a key with the deepest of all the possible cuts, you reliably ended up with a grand-master key for the building or even group of buildings! It made collecting the "complete master key collection" rather easy--just one cylinder to take apart per building. On a recent visit I noticed they had rekeyed with Medeco Bi-axial locks, but I'm afraid I didn't have the time to see if they had learned any lessons about keying plans. Todd
-----------[000008][next][prev][last][first]----------------------------------------------------
Date: 7 Jun 90 05:27:00 GMT
From: NED@HMCVAX.CLAREMONT.EDU ("Ned Freed, Postmaster")
To: misc.security
Subject: Re: a new scam
It's been done before, pretty much as you described. The article I saw was
on the RISKS Digest some time back. It may have also appeared in this
newsgroup as well.
Some details:
(1) The fake machine was built in front of the real one, which if done
in an inobvious manner insures a lot of "clientele" - the regular users.
(2) I believe the machine swallowed the cards completely, saying that it
was confiscating them or some such. This saves the trouble of getting
a card reader operational.
I don't recollect where this occurred. I don't keep such details handy.
It wasn't here in Claremont, CA -- I would have remembered *that*.
All in all, given the limit on the amount of cash dispensed per card, it
does not sound like a very effective scam. Better to rip off/out the whole
machine, as some have done. My recollection is that the amount reported
stolen was large enough to make it cost-effective but not stunningly so.
An interesting question -- is this sort of thing a white or blue collar
type of crime? I recently heard a statistic comparing the amount stolen
in your basic blue collar bank robbery (peanuts), white collar robbery
(i.e. fraud, in the millions), the chances of getting caught (blue collar
quite high, white collar quite low), and the penalties if caught (blue collar
quite severe, white collar quite lenient). In view of the active nature of
such a crime, it comes across like a stickup. But it is quite clever...
like a clever scheme for fraud. Thoughts?
Ned Freed
Innosoft International, Inc.
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jun 90 11:02:31 EDT From: shz@packard.att.com (Seth Zirin) To: security@rutgers.edu Subject: Re: Opening a safe by manipulation
Group II locks offer no intentional protection against manipulation, but wheel shadowing, sticky flies, etc can prevent successful manipulation. Group I locks can also be manipulated in an infinite period of time but cannot be manipulated within 20 hours, which makes them group I. Group 1R locks meet Group I guidlines and are additionally immune to radiological attack. Seth Zirin
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 90 13:11:00 From: jpc@fctunl.rccn.pt (Jose Pina Coelho) To: security@rutgers.edu Subject: Re: a new scam
It has been made. The pseudo ATM was in a box in front of the real one.
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 90 09:48:12 GMT From: zimmerma@lan.informatik.tu-muenchen.de (Kai Werner Zimmermann) To: misc.security Subject: Re: a new scam
This has been done here in Germany more than 2 years ago. In Germany most of those card machines stand inside the entrance halls of the banks. To enter the hall you have to put your card into a reader slot but NOT to type your password, e.g. every card owner may enter. The thieves placed their card reader in a plastic box which they simply fixed in front of the entrance card slot and asked the people via an LCD display to enter their password. -- =============================================================================== |Kai Zimmermann zimmerma@lan.informatik.tu-muenchen.dbp.de | | Hold fast to your dreams, for if dreams die, | ---------------- life is a broken winged bird that cannot fly. ----------------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 90 15:09:27 GMT From: nugent@GARGOYLE.UCHICAGO.EDU To: misc.security Subject: Re: Best Locks
One University I attended had the policy that the master key was always the deepest key cut. If you took apart a multi-keyed cylinder and made a key with the deepest of all the possible cuts, you reliably ended up with a grand-master key for the building or even group of buildings! It made collecting the "complete master key collection" rather easy--just one cylinder to take apart per building. On a recent visit I noticed they had rekeyed with Medeco Bi-axial locks, but I'm afraid I didn't have the time to see if they had learned any lessons about keying plans. Todd
-----------[000013][next][prev][last][first]----------------------------------------------------
Date: 7 Jun 90 16:29:04 GMT
From: jslove@starch.enet.dec.com ("J. Spencer Love; 508-841-2751; SHR1-3/E29 07-Jun-1990 1229")
To: misc.security
Subject: Re: Best LocksI remember hacking Best locks in high school, say about 17 years ago (now it can be told). There are a lot more than 250 possible combinations. We had "A" blanks, 6-pin tumblers, and a keying system called "X". Each pin could be cut at at either the odd or even 5 of 10 possible levels. With one level reserved for the master cut, that left 4 cuts/pin for pass keys. That means there were 4,096 possible pass keys. The locks were zoned into 64 groups of 64, with the school apparently having only licensed the first 8 zones. The 3 shallowest cuts (neat the handle end of the key) varied within a zone. Different zones were lettered A-H, and assigned to different departments within the school -- something like A for upper school, B for offices, C for the kitchen, D for boarding student's rooms, E for maintenance and grounds, F for the middle school, G for the gym, and H for the lower school. (These are probably scrambled -- it's been a long time.) The keys were stamped with codes ranging from XA1 to XH64. The codes were in simple base-4 correspondence to the cuts, starting from the first cut modularly above the master cut as zero. It was only necessary to measure 3 keys with a microcaliper to solve the whole system except for the control key. We made a pretty good guess at the control key (one of 2 patterns). They stamped these numbers on the locks, too. Since they really wanted to label everything, it's really too bad they didn't use a random codebook. (We made friends with the locksmith later and he used a codebook, not the math.) The "X" corresponded to the pattern of evens and odds of the individual pins. I suppose in theory that 64 different patterns could have been given out, but any pattern that had only one (or even two) differences of even/oddness had better be on a different blank (or 1000+ miles away) or there would be too much chance of interchangability of keys. The other basis I have for thinking that they only licensed part of "X" is that their grand master key had a passkey cut for the deepest pin. This would only open 1/4 of the possible X locks (twice as many as they actually used). We got quite a rise out of the administration by showing them just how easy it had been to solve their key system, and describing the real grand master (not the one they had) without ever having seen it. 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... I think they had the cheapest available system, or maybe it was just bought early in Best's career. The cores had those convenient holes for picking the core sleeve. The pins had little (removable!) press in caps over the springs, so we could pick and remove a core, disassemble it and measure the pins, and reassemble and replace it, unharmed. Took about an hour, but we were amateurs. There were mushroom pins in some of the cores. 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?) There were competing groups of students who stole padlocks and disassembled them to figure out the system. There must have been 3 separate successful masterkey projects in my class alone (I knew of 2, counting my own, and had evidence of another. There might have been more, but with a graduating class of 59, I doubt it). 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. Best locks are convenient, but only elementary schools should dare to use them. RPI used them also; when I went to check the place out senior year, practically the first thing I noticed was in the undergraduate handbook where it threatened instant expulsion to anyone who was caught with a master key. Might as well try to sweep back the tide. I went to a college with a more relaxed attitude. Speaking of common practice, key combinations are recycled. Suppose that there are 40 doors and 64 possible keys. If you "lose" your key, you pay a fine and get a new lock and key. 24 lost keys later, someone else will get a new copy of your "lost" key. The loss rate is fairly low; the migration of students from room to room each year is much more likely to create unauthorized access. -- Spencer
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 90 20:23:32 GMT From: Doug Gwyn <gwyn@smoke.brl.mil> To: misc-security@rutgers.edu Subject: Re: Best Locks
It's pretty easy to figure. There are two pinning schemes for Best locks: 10 depths at 12.5 mil increments and 7 depths at something like 18 mil increments. The former is the most common; however, to avoid using 12.5 mil pin sections, which tend to jam, the convention is to use only every second depth for each pin in the 10-depth scheme. Thus, pin columns can be labelled "even" or "odd", depending on which of the two alternate sets of depths they use. If you were to pin a core with splits every 25 mils, with the bottom pin segment chosen as a #0 or #1 length depending on whether the column is even or odd, the core would open on any key in the system. (This would make a good universal substitute for replacing a core removed for study, since it would open the lock for its intended keyholder -- as well as others in the unlikely event that they were to try while the substitute is in place.) Anyway, the number of possible day key changes for the 10-depth scheme can therefore be no more than 5^7 = 78125, while for the 7-depth scheme it is no more than 7^7 = 823543. The actual number is reduced by three considerations: Some key bittings are too insecure, for example all depths the same can be unlocked by a stiff straight wire. Some key bittings are infeasible (at least for some lock brands, possibly not Best), for example the deepest depth adjacent to the most shallow depth (the deep cut's slope overlaps the base of the shallow one's). And finally, to avoid accidental cross-keying, the day keys cannot use the master-key depths. This latter consideration lowers the upper limit to 4^7 = 16384 and 6^7 = 279936, respectively, for one level of masterkeying. Since most campuses use multiple levels of masterkeying (3 or 4 is typical), cross-keying avoidance reduces the number of day key changes still further. There are probably no more than 2000 available; to go beyond that multiple keyway sections are normally used. Best offers several, in at least two distinct families, with special blanks available for the masterkeys to allow them to pass multiple keyway sections within the family. >Is it common practice on campi to have two locks the same, assuming >the residents will never notice? Occasionally a group of people would >all go down a hall trying locks, but we never found a double. I've never encountered a masterkeying setup where duplicate day keys for different access was considered acceptable practice, so I suspect they're not using that at your campus either. >p.s. are there any other HAR56's out there? The "HAR" codes are specific to your campus.
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jun 90 12:38:11 -0600 From: zeleznik@cs.utah.edu (Mike Zeleznik) To: security@pyrite.rutgers.edu Subject: Re: Internet Security
The only problem is that within an organization, a level of trustworthiness
may be assumed among users, and various other security controls may be
relaxed, based on this. It helps in getting work done.
However, if one user makes the mistake of chosing a low level of security
for themselves (e.g., an easy password), many other users may be affected.
Of course, there are other ways they can leave themselves wide open (e.g.,
access modes on certain files), but at least we can try and stop the
ones we can.
Mike
Michael Zeleznik Computer Science Dept.
University of Utah
zeleznik@cs.utah.edu Salt Lake City, UT 84112
(801) 581-5617
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 90 03:02:01 GMT From: robert@anagld.analytics.com (Robert Gottlieb) To: misc-security@uunet.uu.net Subject: DES routine for VMS
I'm not sure if this is the right place to post this, so sorry if this causes any trouble. I am looking for some source C code for a DES routine. It isn't for me, so I don't know the details except that it has to run on a VMS running 5.2 and SmartStar, a co-worker of mine is looking for this. Any replies would be greatly appreciated. I'm looking for ftp'able stuff or email is fine too, or any other suggested methods. Thanks in advance. /No fancy sig as of yet | Robert Gottlieb aka robert@analytics.com / /But look in this space | #include <stdisclaimer> / /For future fancy sig | "I'd rather have a bottle in front of me.. " /
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Jun 90 08:57 +1200 From: Simon Travaglia <CCC_SIMON@waikato.ac.nz> To: security@rutgers.edu Subject: Re: Opening a safe by manipulation
> All Group II safe locks, by definition, can be manipulated. Group I locks, > which are mostly sold to the government, are not susceptible to manipulation. That's a pretty tall order - Not susceptable to manipulation. It's probably more accurate to say that It's not manipulatable in a short time with current common knowledge Locks really only buy you time. Although I agree with your comments about group I locks (people will KNOW if you've been in), most new locks were non-manipulatable until someone did it. I would always leave the shadow of doubt so that there isn't blind faith in a mechanism. ---------------------------------------------------------------------------- | | | | | ___ spt@grace.waikato.ac.nz | | of | | .^. o |/ .^. + .^. SimonT, Computer Services, | |NI | | | +-+ | |\ +-+ | | | University of Waikato, \__/ \_^_/ | | | | \ | | | `v' New Zealand. PSI 0530171000004 Disclaimer: I didn't do it, I'm a helicopter! ---------------------------------------------------------------------------- When a man says, "Get thee behind me, Satan," he's probably ashamed to have even the devil see what he's up to.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Jun 90 16:04:48 EDT From: shz@packard.att.com (Seth Zirin) To: security@rutgers.edu Subject: Re: Best Locks
HAR56 is a blind code that would likely have no meaning within a different master keying system. The 'H' probably indicates the keyblank, 'A' the grandmaster, 'R' the master under the 'A' GMK, and '56' the actual change under the master. A properly designed master keying system should arrange that HAR56 and HAR57 or HAR56 and HAS56 have no relationship that would allow someone to calculate or guess other keys. Whenever I set up a master keying system, I randomly select changes under a master and randomly select masters under the GM, etc. Seth Zirin, CPL
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 90 20:04:48 GMT From: shz@packard.att.com (Seth Zirin) To: misc.security Subject: Re: Best Locks
HAR56 is a blind code that would likely have no meaning within a different master keying system. The 'H' probably indicates the keyblank, 'A' the grandmaster, 'R' the master under the 'A' GMK, and '56' the actual change under the master. A properly designed master keying system should arrange that HAR56 and HAR57 or HAR56 and HAS56 have no relationship that would allow someone to calculate or guess other keys. Whenever I set up a master keying system, I randomly select changes under a master and randomly select masters under the GM, etc. Seth Zirin, CPL
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Jun 90 20:12 CST From: Ken Selvia x3547 <UCS_KAS@shsu.bitnet> To: security@tcsvm Subject: VideoCipher II
I have asked this question on three other lists and no one (yet)
has been able to help. I was referred to this list, so if you can
help please jump in.
I would like to find out more about the encryption methods used with
home-satellite audio systems. I know the signals are digitally encoded and
encrypted with the DES encryption algorithm. This scheme (called
VideoCipher II) was designed by General Instruments. I understand that a
variation of this has been released (VideoCipher II plus) which is more
secure. A friend of mine has a set of replacement EPROM's in his
descrambler unit which allow him to receive all scrambled channels, once
given a valid key for one scrambled channel. Apparently even one valid key
is not necessary for some reprogrammed EPROMs. Can anyone tell me how this
works? Does anyone have any information about the new VC2+ encryption
algorithms? I have seen (and ordered from) adds for software which
explains and demonstrates VC2 encryption techniques. Please send any
pointers or references. I read that there are BBS's which might be
helpful, but the ones I have tried are no longer running.
[Moderator injection: they probably got busted for piracy or something... _H*]
Kenneth Selvia Internet : ucs_kas%shsu.decnet@utadnx.cc.utexas.edu
Programmer Analyst II BITNET : UCS_KAS@SHSU.BITNET
Sam Houston State University
Huntsville, TX 77341 [I have no opinions. I make no claims]
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 90 21:37:19 GMT From: OPSRJH@uccvma.BITNET (Richard Hintz) To: misc.security Subject: Authentication of electronic commercial documents
We are interested in technology for authenticating electronic commercial documents, such as Purchase Orders. Can someone provide some pointers to references on this? Also, does it make sense to talk about using the RSA technology for this purpose? By the way, I'd like to get RSA's phone number,. if someone has it handy. Richard Hintz University of California (415) 987-0437 opsrjh@uccvma
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Jun 90 12:14:55 pdt From: ssc-vax!ssc-bee!maa@beaver.cs.washington.edu To: security@beaver.cs.washington.edu
Do you folks know anything about the upcomming UNIX security conference coming up in Portland this August? I need dates, places, etc. Thanks Mark Allyn uw-beaver!ssc-vax!ssc-bee!maa
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: 12 Jun 90 19:14:55 GMT From: maa@ssc-bee.UUCP To: misc.security Subject: (none)
Do you folks know anything about the upcomming UNIX security conference coming up in Portland this August? I need dates, places, etc. Thanks Mark Allyn uw-beaver!ssc-vax!ssc-bee!maa
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Jun 90 15:42:32 EST From: Don Irmiger <don@delta.com> To: SECURITY@ohstvma.ircc.ohio-state.edu (John Opalko, N7KBT) Subject: Re: RS-232 encryption boxes??
> destroy-before-reading, but it does have to make it difficult for > eavesdroppers. Call Black Box Corp. See what they can offer you. -- 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
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 90 15:04:48 GMT From: vancleef@FS01.NAS.NASA.GOV (Robert E. Van Cleef) To: misc.security Subject: Re: Expired passwords...
Oh - Cute! That means YOU, or one of your staff, know all of the
passwords. What we did is:
1 - Make the password program reject dumb passwords.
2 - Run a fast password cracker against all of our systems to insure
the "root" hasn't given someone a dumb password.
You are assuming that you and your staff will assign passwords that are
safe and memorable. My experience is that, under the pressure of
events, people will assign passwords to others that are as bad, or worse,
that those others would have picked for themselves.
Let your software do the work for you.
Of course, you did say a "medium sized system". The problem with most
solutions that I have seen, to all Unix system administration problems,
are that they are not scalable. As systems grow, things break! Can you
safely say that your current procedures would work if your system
doubled in size or the number of users?
Bob
__
Bob Van Cleef - vancleef@nas.nasa.gov
RNS Distributed Systems Team Leader
NASA Ames Research Center (415) 604-4366
Mail Stop 258-6 FTS 464-4366
Moffet Field, CA 94035-5000 FAX (415) 604-4377
__
"If you're not a liberal at 20, you have no heart, and
if you're not a conservative at 40, you have no head."
Winston Churchill
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Jun 90 22:25:35 EDT From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) To: netcom!onymouse@claris.com Cc: security@pyrite.rutgers.edu Subject: National Security Agency
You cannot, as a plain old, lowly American citizen, get anything from the NSA. All requests are declined. This is patently not true. You can, for instance, get a job from the NSA. You can also get a job interview, reimbursement for your travel expenses, and the like. On a slightly more serious note, you can get papers that the NSA has published. The NSA has a research group which does non-classified work and publishes papers, as well as presents them at various meetings. You can get a bibliography from the NSA of all the books that have been published about The Agency, both pro and con (they will even tell you which are which.) The NSA produces several pamphlets describing what they do. One of the things that you cannot get from the NSA is their budget. I could go on.
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Jun 90 10:06:49 EDT From: shz@packard.att.com (Seth Zirin) To: security@rutgers.edu Subject: Re: Security and Masterkeys
>In every >case I am aware of the master key is the lowest key of all. Sorry Leonard. You must not be aware of any professionally designed master keying systems that were set up according to common locksmithing industry standards. 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. The master key should also have a wide assortment of cuts so that the master key shear line in the lock (every lock) is difficult to pick. If the master key was always the "lowest key of all", whatever that means, it would be a very flat key or provide very few cut depths (and thus key combinations) for the change keys. Calculating the top level master key by measuring pins becomes increasingly difficult as the number of levels (i.e., MK, GMK, GGMK, GGGMK, etc) increases. It is possible for a lock in a single level master-keying system to have more pins than an idential lock in a four level system. Seth Zirin, CPL
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 90 14:06:49 GMT From: shz@packard.att.com (Seth Zirin) To: misc.security Subject: Re: Security and Masterkeys
>In every >case I am aware of the master key is the lowest key of all. Sorry Leonard. You must not be aware of any professionally designed master keying systems that were set up according to common locksmithing industry standards. 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. The master key should also have a wide assortment of cuts so that the master key shear line in the lock (every lock) is difficult to pick. If the master key was always the "lowest key of all", whatever that means, it would be a very flat key or provide very few cut depths (and thus key combinations) for the change keys. Calculating the top level master key by measuring pins becomes increasingly difficult as the number of levels (i.e., MK, GMK, GGMK, GGGMK, etc) increases. It is possible for a lock in a single level master-keying system to have more pins than an idential lock in a four level system. Seth Zirin, CPL
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 90 17:58:11 GMT From: 6600tlee@ucsbuxa.ucsb.edu (Tennyson Lee) To: misc-security@ucsd.edu Subject: Re: RS-232 encryption boxes??
Here's a list of vendors that produce the cryptographic hardware you're looking for: Pailen-Johnson Associates (703) 442-9051 Products: LEAD, 9600bps, $500 Secureware, Jr., 9600bps, $195 Racal-Guardata, Inc (703) 471-0892 Products: CAT-2000, 19200bps, $1125, DES ISM, 9600bps, $2195, DES (eeprom based keys) Microframe, Inc (201) 494-4440 Products: Cipher Key, 3000bps, $400, DES Jones Futurex, Inc (916) 635-3972 Products: ENC324, 9600bps, $595, DES ENC400, 9600bps, $595, DES Intellicom (818) 407-3900 Products: microcipher, 19200bps, $499, DES GN Telematic (800) 468-8353 Products: safematic, 9600 bps, $900, DES/RSA/custom algorithms This is a partial list of companies that manufacture crytographic hardware of the type you're looking for. See the June 11, 1990 issue of computerworld for a brief article and listing of companies that manufacture such devices. -- Tennyson Lee University of California, Santa Barbara 6600tlee@ucsbuxa.ucsb.edu 6600tlee@ucsbuxa.bitnet
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 90 20:26:57 GMT From: gwyn@SMOKE.BRL.MIL (Doug Gwyn) To: misc.security Subject: Re: Security and Masterkeys
>In every >case I am aware of the master key is the lowest key of all. In a properly designed system, it shouldn't be. Otherwise, any "day key" (ordinary operating key) could be filed down to produce a master key. This would especially compromise security when restricted blanks are used. However, the procedure you suggest can often be used in modified form to determine the highest-level masterkey, because if there are multiple splits in a pin column you can be fairly sure that the one that matches your day key is NOT the master split, and if there is only one split then your day key and all levels of master key must share that depth in that column. Thus, if there are no more than two splits in each column, using the ones that differ from your day key (when there is a choice) will very likely produce the highest level master key. (Lower-level mastering is often done by sharing splits in a column or two with the day keys in that submaster group.)
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 90 20:26:57 GMT From: Doug Gwyn <gwyn@smoke.brl.mil> To: misc-security@rutgers.edu Subject: Re: Security and Masterkeys
>In every >case I am aware of the master key is the lowest key of all. In a properly designed system, it shouldn't be. Otherwise, any "day key" (ordinary operating key) could be filed down to produce a master key. This would especially compromise security when restricted blanks are used. However, the procedure you suggest can often be used in modified form to determine the highest-level masterkey, because if there are multiple splits in a pin column you can be fairly sure that the one that matches your day key is NOT the master split, and if there is only one split then your day key and all levels of master key must share that depth in that column. Thus, if there are no more than two splits in each column, using the ones that differ from your day key (when there is a choice) will very likely produce the highest level master key. (Lower-level mastering is often done by sharing splits in a column or two with the day keys in that submaster group.)
-----------[000032][next][prev][last][first]----------------------------------------------------
Date: 17 Jun 90 06:30:00 GMT
From: NED@HMCVAX.CLAREMONT.EDU ("Ned Freed, Postmaster")
To: misc.security
Subject: Re: Security and MasterkeysDon't expect the master to always be the lowest cut key. It is not in many cases, although the pins where it is the "high cut" tend to be ones reserved for zone master/grand master distinctions. However, I've never seen a system where the highest cut was used in more than a couple of pin positions, so the number of keys possible, even when working from a single lock as an information source, is not very large. Use of different grooves in the blank is the usual mechanism to differeniate grand masters from great grand masters. However, adding additional grooves to a key is pretty easy if you have access to a mill and a tool of the proper size. Making your own key from brass stock is also not too hard if you know what you're doing, and it makes complete hash out of all these foolish "registered blank" schemes. I mentioned making a key out of sheet metal in a previous posting. I once made one out of mild steel as a sort of joke for somebody; it wasn't even a master since that was not part of the joke (his key broke off in his lock on two different occasions and I thought I'd make one that would not suffer from this problem). Ned Freed
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 18 Jun 90 15:26:57 GMT From: DIXON@OHSTVMA.IRCC.OHIO-STATE.EDU (Bob Dixon) To: misc.security Subject: Re: DES routine for VMS
We have DES software which is compatible across all common operating systems,
including VMS. It is available to non-profit organizations for free.
Bob Dixon
Ohio State University
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 19 Jun 90 13:39:00 GMT From: EVERHART@arisia.dnet.ge.com To: misc.security Subject: Virus prevention
Re Kees deGroot's posting. The DECUS library sells to anyone (membership in DECUS is free and nobody is that concerned whether you are or are not a member.) The software in it (multiple gigabytes of software) covers a great many machines, and is NOT, repeat NOT, limited to boxes DEC makes. You won't find much systems code for, say, Unisys boxes in the DECUS library, but applications that will run on Unisys boxes certainly abound. The library is run by a staff, who are DEC employees. It has two basic virus/trojan resistant attributes. First, the submitter is ALWAYS known and recorded, and everyone who gets software from the library (for which a production fee is charged; the cost is NOT paying for the software, but is covering part of the cost of running a fulltime library) has that name. What you get is a copy of what the submitter sent in. The production machines aren't on any nets or outside hookups; this makes them fairly resistant to penetration by ill-doers. Further, there's a central office with people who answer the phone. When covert behavior of a program is detected, here's what happens: 1. The program is pulled from further distribution. 2. People are notified by whatever means are available (which these days will include the net) about the nature of the problem and all specifics that are known. 3. Efforts are made if the program was otherwise useful to reset the covert behavior and distribute the cleaned-up one together with a complete analysis of what happened. Source code is usually available also. This happened only once so far where a program had a covert time-out. The damage to someone's reputation when he submits a program and suffers all the adverse publicity which we can and WILL produce is such that there's not much incentive to try putting covert behavior into programs going into the DECUS library. Besides this, a good many of us use the code and look for "funny" stuff. It's not organized so that there's 100% coverage, and we don't want to say there is coverage even where it exists in too strong a form; we are after all human and don't want lawsuits by someone who says we should have tested more. But there are paths for reporting odd behavior and reacting to it. This applies to the sig tapes also, which are produced and distributed outside the DECUS library as well as contributed to it. Most funny behavior that's been reported are version or site dependencies (which can be quite hard for an author to detect) and we try to tell what we find. In all, the path from author to recipient is probably shorter dealing with DECUS library stuff or SIG tape stuff than it is for most commercial software, and we won't and haven't concealed any reported covert behavior; we are best protected by publicizing any such as quickly and widely as possible. Be sure this list will get such reports, as well as info-vax/comp.os.vms and, if we find a worm orv virus, virus-l. We do ask that people using the code help by reporting any odd behavior. You can call the DECUS office (508 480 3418 will get you into the office, though you'll need probably another extension to which you can be transferred) or me (215 354 7610) (me for sig tape info; the DECUS office for any, by preference) or Ted Nieland (513 427 6355) for SIG tape info also. To the extent we watch one another's backs, we're all the safer. Funny behavior in this case means suspected covert behavior by a program. If you have a systems program written, say, for VMS V4.7 and try running it on VMS 5.3-1 symmetric multiprocessors, you should expect it to fail in many cases. We're more interested thee there in what succeeds. However, timeouts, odd use of privs, writing files or modifying files that aren't documented, and the like are of interest. I understand the concerns about trojans or viruses, but these are probably more likely in commercial software than people realize. Your path from the submitter to you is as short dealing with the DECUS library as it is buying direct from a commercial vendor, and shorter than if the software passes through a store or distributor. The DECUS record of NOT concealing any problems is also public, and that policy will ultimately protect you further. Glenn Everhart VAX SIG librarian (DECUS) Everhart@Arisia.dnet.ge.com
-----------[000035][next][prev][last][first]----------------------------------------------------
Date: 19 Jun 90 17:41:22 GMT
From: TS0258@ohstvma.BITNET ("Chuck Sechler")
To: misc.security
Subject: Password CheckingSome 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.
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: 20 Jun 90 17:16:41 GMT From: mark%beowulf@UCSD.EDU (Mark Anderson) To: misc.security Subject: Re: Security and Masterkeys
>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
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 20 Jun 90 20:44:01 GMT From: levine@csd4.csd.uwm.edu (Leonard P Levine) To: misc.security Subject: Re: Security and Masterkeys
> 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
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: 21 Jun 90 07:33:36 GMT From: hobbit@PYRITE.RUTGERS.EDU (*Hobbit*) To: misc.security Subject: Failed: attempt #1 at securing the vehicle
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*
-----------[000039][next][prev][last][first]---------------------------------------------------- From: John Moore <anasaz!john@mcdphx.phx.mcd.mot.com> 22-JUN-1990 19:23:02 To: security@asuvax.eas.asu.edu
Yes... the same monthly master key is (or at least was) used for all channels.
Thus, if you can decrypt one, you can decrypt all. The VC-II uses
non-crypto means to decide whether you can watch a particular channel.
Thus, if you defeat this (by modifying the code), you can subscribe
to one channel (which makes all the crypto possible) and then receive all.
My understanding is that someone dissected the crypto chip, found a
way to reconnect a factory test lead, and was able to get intermediate
crypto products out that can be used to crack the key. This is from
a hazy memory.
[Disclaimer: I have a video-cipher II and haven't touched the insides.
I don't want to go to jail!]
--
John Moore HAM:NJ7E/CAP:T-Bird 381 {asuvax,mcdphx}!anasaz!john john@anasaz.UUCP
Voice: (602) 951-9326 (day or eve) FAX:602-861-7642 Advice: Long palladium,
USnail: 7525 Clearwater Pkwy, Scottsdale, AZ 85253 ......: Short petroleum
Opinion: Support ALL of the bill of rights, INCLUDING the 2nd amendment!
-----------[000040][next][prev][last][first]---------------------------------------------------- From: "Ned Freed, Postmaster" <NED@hmcvax.claremont.edu> 22-JUN-1990 19:50:37 To: security@pyrite.rutgers.edu
Don't expect the master to always be the lowest cut key. It is not in many cases, although the pins where it is the "high cut" tend to be ones reserved for zone master/grand master distinctions. However, I've never seen a system where the highest cut was used in more than a couple of pin positions, so the number of keys possible, even when working from a single lock as an information source, is not very large. Use of different grooves in the blank is the usual mechanism to differeniate grand masters from great grand masters. However, adding additional grooves to a key is pretty easy if you have access to a mill and a tool of the proper size. Making your own key from brass stock is also not too hard if you know what you're doing, and it makes complete hash out of all these foolish "registered blank" schemes. I mentioned making a key out of sheet metal in a previous posting. I once made one out of mild steel as a sort of joke for somebody; it wasn't even a master since that was not part of the joke (his key broke off in his lock on two different occasions and I thought I'd make one that would not suffer from this problem). Ned Freed
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 21 Jun 90 15:44:22 GMT From: jearly@LEHI3B15.CSEE.LEHIGH.EDU (John Early) To: misc.security Subject: SPARCstation security
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 |
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 22 Jun 90 14:32:19 GMT From: kuras@josef.enet.dec.com To: misc.security Subject: Re: workshop
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
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 24 Jun 90 06:01:57 GMT From: deronwal@TYBALT.CALTECH.EDU (Deron Walters) To: misc.security Subject: Medecos (was Re: Best Locks)
>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*]
-----------[000044][next][prev][last][first]---------------------------------------------------- From: Rick Schatzman <AURPS@asuacad.bitnet> 27-JUN-1990 23:21:03 To: security@pyrite.rutgers.edu
Does anyone know how to decrypt a Word Perfect 5.0 or 5.1 file when the key has been lost? I have heard that there is an article published that explains how to do this.
-----------[000045][next][prev][last][first]---------------------------------------------------- From: Richard Hintz <OPSRJH@uccvma.bitnet> 27-JUN-1990 23:56:00 To: security@ohstvma
We are interested in technology for authenticating electronic commercial documents, such as Purchase Orders. Can someone provide some pointers to references on this? Also, does it make sense to talk about using the RSA technology for this purpose? By the way, I'd like to get RSA's phone number,. if someone has it handy. Richard Hintz University of California (415) 987-0437 opsrjh@uccvma
-----------[000046][next][prev][last][first]---------------------------------------------------- From: zeleznik@cs.utah.edu (Mike Zeleznik) 28-JUN-1990 0:22:41 To: security@rutgers.edu
>You cannot, as a plain old, lowly American citizen, get anything from the
> NSA. All requests are declined.
But you CAN get all you want of their public info from their public arm,
the National Computer Seurity Center (NCSC) (I'm sure this has been
mentioned here before). You can also probably get an account on
dockmaster to keep up with what is available on-line (Project OPENAIR).
OPENAIR: NCSC
Attn: OPENAIR Accounts Administrator
9800 Savage Rd
Fort Meade, Maryland 20755-6000
(301) 850-4446 or maybe 859-4360
NCSC PUBS (single copies only): (301) 859-4450
And if you need other info, the people above will probably be more then
willing to help point you in the right direction.
Mike
Michael Zeleznik Computer Science Dept.
University of Utah
zeleznik@cs.utah.edu Salt Lake City, UT 84112
(801) 581-5617
-----------[000047][next][prev][last][first]----------------------------------------------------
Date: 26 Jun 90 15:24:00 GMT
From: DEGROOT@rcl.wau.nl ("Kees de Groot, Information Systems Security")
To: misc.security
Subject: Re: Off the wall...ROM security?
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 .. -
-----------[000048][next][prev][last][first]---------------------------------------------------- From: vancleef@fs01.nas.nasa.gov (Robert E. Van Cleef) 28-JUN-1990 0:54:44 To: security@pyrite.rutgers.edu
Oh - Cute! That means YOU, or one of your staff, know all of the
passwords. What we did is:
1 - Make the password program reject dumb passwords.
2 - Run a fast password cracker against all of our systems to insure
the "root" hasn't given someone a dumb password.
You are assuming that you and your staff will assign passwords that are
safe and memorable. My experience is that, under the pressure of
events, people will assign passwords to others that are as bad, or worse,
that those others would have picked for themselves.
Let your software do the work for you.
Of course, you did say a "medium sized system". The problem with most
solutions that I have seen, to all Unix system administration problems,
are that they are not scalable. As systems grow, things break! Can you
safely say that your current procedures would work if your system
doubled in size or the number of users?
Bob
__
Bob Van Cleef - vancleef@nas.nasa.gov
RNS Distributed Systems Team Leader
NASA Ames Research Center (415) 604-4366
Mail Stop 258-6 FTS 464-4366
Moffet Field, CA 94035-5000 FAX (415) 604-4377
__
"If you're not a liberal at 20, you have no heart, and
if you're not a conservative at 40, you have no head."
Winston Churchill
-----------[000049][next][prev][last][first]---------------------------------------------------- From: xrtnt@amarna.gsfc.nasa.gov (Nigel Tzeng) 28-JUN-1990 1:30:44 To: misc-security@ames.arc.nasa.gov
^ adminisister the password problem is to assign passwords and remove the
^ passwd program
>From the users point of view this gets annoying after a while. For longish
password of random variables they'll eventually just write them down. Now what
does that buy you? Same for the preemptive password lengthening system. If
they can't deal with a 8 char password limit in an intelligent sort of way how
do you think they'll deal with a ten char password limit?
This sort of behavior is a) confrontational b) non-productive. By doing this
sort of thing you'll piss off users who know better and lead to the situation
where they go out of their way to circumvent your protections leading to a
further unprotected system.
Of course I work in a development environment where most users here can be
considered "power-users". As software professionals we (or at least I) insist
on being treated as one and not as some hacker dude from the Chaos Klub. Users
are as much part of a secure system as the protection schemes built into the
native OS.
NT
--------------------------------------------------------------------------------
// | Nigel Tzeng - STX Inc - NASA/GSFC COBE Project
\X/ | xrtnt@amarna.gsfc.nasa.gov
|
Amiga | Standard Disclaimer Applies: The opinions expressed are my own.
-----------[000050][next][prev][last][first]---------------------------------------------------- From: Alex Kuhn <75016.1201@compuserve.com> 28-JUN-1990 22:09:53 To: <security@pyrite.rutgers.edu>
Hi. I'm new to this newsgroup, but I have a question I figure someone here can answer. How does someone become a locksmith? I've always had a great interest in keys and locks, and am interested in doing some locksmithing. Do you have to be licensed in the town/state? Or can you just set up shop with a key machine and call yourself a locksmith? Can someone order blanks from a distributor or manufacturer directly, or do you have to have a locksmith's license to get them? I'm interested in the whole field, but Best keys interest me particularly. Can these be gotten without a locksmith's license? Thanks for any help you can give- Alex Kuhn (75016.1201@compuserve.com)
-----------[000051][next][prev][last][first]---------------------------------------------------- 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.)
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 27 Jun 90 18:52:02 GMT From: security-request@PYRITE.RUTGERS.EDU (*Hobbit*) To: misc.security Subject: Collected replies re: IBM security
There were many of these; to save a little network bandwidth I've created
a small digest thereof. _H*
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 13 Jun 90 04:38:50 GMT
>From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: IBM security
>What I don't understand is that I have rarely
>encountered references to security breachs on IBM machines running VM or
>MVS. Why is this?
There are many possible reasons, among them:
UNIX and VMS are set up to facilitate sharing among users,
while IBM mainframes are set up to prevent sharing.
There are relatively few users of IBM mainframes, especially
hacker types, students, etc.
IBM mainframe security is such a joke that breaking it isn't
considered a challenge.
Technical information about the inner workings of IBM
mainframes is voluminous and hard to come by.
IBM mainframes don't provide direct access by ASCII terminals,
which are the only kind crackers are likely to have.
IBM users don't share information the way UNIX (and to some
extent VMS) users do.
I've heard of several security breaches on IBM mainframes, so I
wouldn't say that they're inherently more secure.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 13 Jun 90 09:19 EST
>From: EVERHART@arisia.dnet.ge.com
Subject: IBM security
I've heard of a number of cracks of IBM system programs in the past.
They're generally hushed up quickly at the local site. One was to
boot VM into a system too small to hold CMS; one gets into a VM nucleus
somehow and can issue commands which CMS would ordinarily filter as
privileged.
The ISAM access method for years used (maybe still uses?) self modifying
channel code which can be and has been used to get into supervisor state.
I recall stories of using SVC 15 to get to supervisor state, but that
was a long time back and I heard too little to get the details. There
was a hole in one of the IBM OSs that allowed nonpriv'd users to do
this though.
The hole in CMS security was patched at the site where the case I
heard of by having them hire the guy who did it (he was a high school
student at the time and used it to forge some mail and play a few
pranks but did no serious damage) and get him to plug them. Lord knows
what else was involved.
I've heard these stories about several sites where I've gotten to know
IBM systems people. They are NEVER discussed in the press, and the
systems are generally large computing centers that feel they would be
highly embarrassed (and lose business) if their vulnerabilities were
discussed openly. This of course leaves OTHER IBM sites still wide
open to the same hacks, apart from the (hopeful) reports to IBM
and (hopeful) IBM fixes. Since most of these sites don't seem to be
as pervasively networked as other systems, and since their internals
are often unfamiliar, reports don't seem to have leaked out as much
as in other systems. I presume that after this many years the problems
reported don't exist in current IBM OSs, but have little doubt that
others do.
Anyone have other more recent stories to tell?
Glenn Everhart
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Wed, 13 Jun 90 08:11:12 -0700
>From: vancleef@fs01.nas.nasa.gov (Robert E. Van Cleef)
Subject: Re: IBM security
Look for the novel "The Consultant", published in the late 60's.
It is about a computer security consultant that used his
knowledge to steal from his clients. As a novel it is
so-so, but it will give you some insight into the environment
of large, commercial systems.
Bob
__
Bob Van Cleef - vancleef@nas.nasa.gov
RNS Distributed Systems Team Leader
NASA Ames Research Center (415) 604-4366
Mail Stop 258-6 FTS 464-4366
Moffet Field, CA 94035-5000 FAX (415) 604-4377
__
"If you're not a liberal at 20, you have no heart, and
if you're not a conservative at 40, you have no head."
Winston Churchill
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Wed, 13 Jun 90 12:16:03 -0400
>From: wrf@ecse.rpi.edu (Wm. Randolph Franklin)
Subject: IBM OS security
Unix Today, Jan 23, 1989, page 10, had an article "Feds Insecure about
MVS too". It doesn't have too much technical info though. I think in
general IBM practices at least some security through obscurity.
In the 1960s and early 70s, OS had no protection whatsoever. Anyone
could read or write any disk data set (file). The IEHPROGM program
could delete any data set something like thus (my memory is
approximate):
SCRATCH VOL=USR001,DSN=MY.FTN
If you omitted the comma, the DSN=MY.FTN would be treated as a comment.
The remaining command caused the whole disk to be scratched. One day at
U of Toronto someone scratched all the online disks. I'm not even
certain it was malicious and not accidental. They restored from the
daily backup and deleted that function from the IEHPROGM program,
forcing any potential hacker to read the manual and write a program to
do the SVC call to scratch the whole disk himself.
Of course IBM is better now. It's harder to get the manual :-)
P.s. U of T 20 years ago did better backups than all the publicly
available computers here at RPI today, except the campus mainframe. So
IBMers do a few things right.
--------
Wm. Randolph Franklin
Internet: wrf@ecse.rpi.edu (or @cs.rpi.edu) Bitnet: Wrfrankl@Rpitsmts
Telephone: (518) 276-6077; Telex: 6716050 RPI TROU; Fax: (518) 276-6261
Paper: ECSE Dept., 6026 JEC, Rensselaer Polytechnic Inst, Troy NY, 12180
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 13 Jun 90 20:04:36 GMT
>From: esf00@uts.amdahl.com (Elliott S. Frank)
Subject: Re: IBM security
It's been a while since I last logged onto TSO (the interactive access
component of MVS), but I'll give it a whirl. [I'm not a lawyer, but
I occasionally wear a shirt and tie like one. If I actually knew
anything about anyone breaking MVS, I'd probably not disclose it in
this forum (see third paragraph, below.)]
The mechanisms required to break MVS security are "well known" -- all
you need to do is to place your program in an "authorized library"
[allowed to invoke restricted operating system functions] and off you go.
Consequently, there are tools from both IBM and from third parties
(Computer Associes has two **expensive** offerings) to restrict access
to such libraries. MVS also has extensive logging and tracing built
into the operating system. This logging covers *all* access to data.
This logging is the basis for most chargeback schemes, so it is kept
running most of the time. IBM will also accept **all** bug reports
that identify a security 'leak' in MVS and fix them. Security APARs
(bug fixes) are distributed with only the label 'SECURITY' -- with
the failure mechanism and bypass information that normally accompany
each MVS bug fix suppressed.
Most MVS shops run large configurations ( >>50 VUPS) and consequently
have the requisite administrators as part of the overhead of operating.
Finally, if you've got your corporate financials and other *extremely*
sensitive files running under MVS, you're not going to publicize the
fact that you have been attacked. The law that makes it criminal for
corporate officers to pay (or codone paying) bribes *anywhere in the
world* also makes corporate officers responsible for the security of the
computers that they manage. If you publicize an attack on your MVS
system, you lay yourself open to a stockholders suit. Far better to
defeat the attack, turn the miscreant over to your lawyers, and seal
the court records. Given the mechanisms described above, I suspect
that most attacks are 'semi-inside', rather than outside crackers.
--
Elliott Frank ...!{hplabs,ames,sun}!amdahl!esf00 (408) 746-6384
or ....!{bnrmtv,drivax,hoptoad}!amdahl!esf00
[the above opinions are strictly mine, if anyone's.]
[the above signature may or may not be repeated, depending upon some
inscrutable property of the mailer-of-the-week.]
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Wed, 13 Jun 1990 17:40:27 EDT
>From: Homer <CTM@cornellc.bitnet>
Subject: Re: IBM security
This is totally off the wall, but I proffer it anyhow. IBM systems
are often associated with higher echelon sort of people, professionals
doing serious work etc, people who have outgrown their 'criminal' years
of 18 to 25. IBM systems are also very expensive to access so young
student use is minimal, although at Cornell I must admit IBM mainframes
have served the student body for many years and still do.
Sun and Unix systems on the other hand proliferate widely,
are 'free' in that rarely do you hear of someone needing to put
money into an account so almost anyone can get an account who wants one
and they are not limited by small amounts of alloted computer time.
Thus the bigger more expensive to use systems are used more by serious well
funded, well checked out kinds of people,
and the smaller less expensive systems attract endless nuts. The
extreme of this are the PC's of course where viruses are a dime a dozen,
but so are the PC's. Anyone can own one and hack on it forever in the privacy
of his own home until he has developed a killer something or other.
Also the IBM environment of VM is much like solitary confinement,
it was designed this way on purpose. Writing a virus for this system
would infect you and thats it. That is the whole idea behind virtual
machines. Every time you are swapped out of core, your whole machine
is turned off and someone elses is turned on. Of course no virus
can survive a on/off cold boot.
IBM systems can be attacked, but it takes more system knowledge
than is available to your usual freshman hacker. Anyone can get
systems knowledge of a Sun or Unix system. That is part of their design
philosophy. You gotta have a real job to get it on the IBM systems,
and most of those people are trust worthy. Of course if any IBM
system were ever attacked by an inside job, the results would be
devastating at least to that one machine.
Pardon my display of ignorance.
Also I did not mean to insult anyone using non IBM systems.
Professionals use all sorts of non IBM systems all the time. My point
is merely that there are a higher number of NON professionals using
the non IBM systems too, and these systems are widely interconnected,
and are easy to learn the internals of. This is a recipe for trouble.
As the professionals who use the non IBM systems have found out.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: Wed, 13 Jun 90 18:32:00 EDT
>From: "Lee C. Varian" <LVARIAN@pucc.bitnet>
Subject: Re: IBM security
Craig, For the last seven years for VM (and I think about ten years
for MVS), IBM has made an "Integrity Statement" about these two operating
systems which basically says that they will fix security problems in
these systems. I'm enclosing a copy of the original Integrity Statement
for VM.
Our installation participated in uncovering a security problem in VM a
number of years ago (the "Hugo problem" in which it was possible to
alter a protected area of memory with a very bizarre and clever I/O
channel program). I can assure you that IBM took the problem very
seriously and we were testing a fix from them in a matter of days.
Lee Varian
Princeton University
IBM Programming Announcement dated June 21, 1983 (VM/SP integrity
announcement)
Statement of system integrity for
VM/System Product (VM/SP) and VM/SP
High Performance Option (VM/SP HPO)
5664-167
5664-173
System integrity is an important characteristic of VM/SP. This
announcement extends IBM's previous statements on system integrity to
the VM/SP environment. For VM/SP Release 3 and the associated VM/SP
High Performance Option, IBM will now accept APARs that describe
exposures to system integrity or that describe problems encountered
when a program running in a virtual machine not authorized by a
mechanism under the customer's control introduces an exposure to system
integrity.
IBM has performed an analysis of the VM/SP environment, which includes
the VM/SP control program and VM/SP HPO, to identify and correct
instances of potential system integrity exposure. As system integrity
problems have been investigated and corrected, understanding of VM/SP
integrity has increased and IBM has implemented specific design and
coding guidelines for maintaining system integrity in the development
of VM/SP. Procedures have also been established to make the application
of these design and coding guidelines a formal part of the
design/development process.
However, since it is not possible to certify that any system has
perfect integrity, additional exposure may come to light. Therefore,
IBM will accept APARs that describe exposures to system integrity of
VM/SP or that describe problems encountered when a program running in
a virtual machine not authorized by a mechanism under the customer's
control introduces an exposure to the system integrity of VM/SP, as
defined below.
IBM will continue its efforts to verify and enhance the integrity of
VM/SP and to respond promptly when exposures are identified. Except
as noted, this statement applies to:
o VM/SP Release 3 and subsequent releases
o The associated VM/System Product High Performance Option release
and subsequent releases.
VM/SP system integrity definition: VM/SP control program system
integrity is defined as the inability of any program running in a
virtual machine not authorized by a VM/SP control program mechanism
under the customer's control and/or guest operating system mechanism
under the customer's control to:
o Circumvent or disable the control program main or secondary
storage protection.
o Access a control program password-protected resource.
o Obtain control in real supervisor state or with privilege class
authority or directory capabilities greater than those it was
assigned.
o Circumvent the system integrity of any guest operating system
which itself has system integrity (such as MVS or VM/SP as a
result of an operation by any VM/SP control program facility.
VM/SP control program system integrity does not specifically
include the protection of data between multiple users of a single
CMS batch system. It also does not apply to virtual machines using
Non-Disruptive Transition (NDT) support.
The following environments are supported for MVS machines only:
o V=R with the NOTRANS option
o V=R with the Shadow-Table-Bypass SET command option
o The preferred machine assist
o The single processor mode
However, when any of these facilities are used within an MVS guest
machine, an MVS user or program that has been given authority to
bypass MVS system integrity control may also be able to bypass the
system integrity controls built into VM/SP. In these circumstances
it is a customer responsibility to assure that the required MVS
system integrity controls are installed and that MVS-authorized
programs and users are properly controlled. (See the programming
announcement dated October 21, 1981 for the definition of MVS
system integrity.)
Main storage protection refers to the isolation of one virtual
machine from another. The control program accomplishes this by the
use of hardware dynamic address translation.
Secondary storage protection refers to the disk extent isolation
implemented for minidisks/virtual disk through channel program
translation.
Password-protected resource refers to resources protected by control
program logon passwords and minidisk passwords.
Guest operating system refers to a system control program that operates
under the VM/SP control program.
Directory capabilities refers to those directory options which control
the use of functions intended to be restricted by specific assignment,
such as those which permit system integrity controls to be bypassed
or those not intended to be generally granted to users.
Customer responsibilities: While protection of the customer's data
remains the customer's responsibility, data security continues to
be an area of vital importance to IBM. IBM's commitment to the
system integrity of the VM/SP environment, as described in this
announcement, represents a major step to help customers protect their
data.
Product documentation, subject to change, will describe what action
must be taken and which facilities must be restricted to complement
the system integrity support provided by VM/SP. Such actions and
restrictions may vary depending on the system, configuration, or
environment. The customer is responsible for the selection,
application, adequacy, and implementation of these actions and
restrictions, and for appropriate application controls.
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Date: 17 Jun 90 15:38:10 GMT
>From: hwt@x.bnr.ca (Henry Troup)
Subject: Re: IBM security
My experience as a VM system programmer was that IBM was reasonably 'tight'
with regards to bypassing the protection mechanism. There were occasional
RAS (Reliability, Availability, Security) announcements and fixes from IBM,
but most of the holes in the system would simply cause a crash, rather than
allowing unauthorized access.
One of the biggest (and classic) VM/SP holes is the installation guide, which
has the listing of the starter system directory as the back 20 pages - passwords
and all. Many small packaged systems never changed those passwords, and some
people even thought that those accounts and passwords were essential.
I suspect, however, that the security of most mainframes lies in the fact that
you can't break a system from a card reader with any ease. There's still an
immense amount of non-interactive computing done on MVS, for example. Physical
terminals may be few and far between.
At U of Toronto, when I was there, there were complete separated academic
and administrative systems - duplicated, non-cross connected IBM 3033N8s.
It was well known that a student caught doing anything with the admin system
would be expelled. All terminals were keylocked, and behind locked doors.
Students were not allowed in the machine room.
Final note: VM has several privilege classes - the most useful to the hacker
being the one that allows you to write to system memory - and change your
privilege class.
--
Henry Troup - BNR owns but does not share my opinions
..uunet!bnrgate!hwt%bwdlh490 or HWT@BNR.CA
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 27 Jun 90 19:38:00 GMT From: CSMSPCN@OAC.UCLA.EDU (Pete Nielsen) To: misc.security Subject: Re: Authentication of electronic commercial documents
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.
-----------[000054][next][prev][last][first]---------------------------------------------------- From: Bob Dixon <DIXON@ohstvma.ircc.ohio_state.edu> 29-JUN-1990 12:04:03 To: security@pyrite.rutgers.edu
We have DES software which is compatible across all common operating systems,
including VMS. It is available to non-profit organizations for free.
Bob Dixon
Ohio State University
-----------[000055][next][prev][last][first]---------------------------------------------------- From: "Howie McCausland (802)388_3711x5754" <HOWIE@midd.cc.middlebury.edu> 29-JUN-1990 12:37:05 To: security@pyrite.rutgers.edu
I have heard the argument made that forcing frequent password changes is
counterproductive--particularly in those systems where the user logs in,
learns that her/his password has expired, and has to choose a new one
IMMEDIATELY. The supposed flaw is that the user will pick a poor password,
because there isn't enough time to think up a good one. Similarly, those
password generator programs that impose a non-english password on the user
are said to cause passwords to be written down.
I'm not sure I subscribe to either argument, but wondered what others in
the network thought...
Howie McCausland (Middlebury College)
-----------[000056][next][prev][last][first]---------------------------------------------------- From: EVERHART@arisia.dnet.ge.com 29-JUN-1990 13:11:40 To: security@pyrite.rutgers.edu
Re Kees deGroot's posting. The DECUS library sells to anyone (membership in DECUS is free and nobody is that concerned whether you are or are not a member.) The software in it (multiple gigabytes of software) covers a great many machines, and is NOT, repeat NOT, limited to boxes DEC makes. You won't find much systems code for, say, Unisys boxes in the DECUS library, but applications that will run on Unisys boxes certainly abound. The library is run by a staff, who are DEC employees. It has two basic virus/trojan resistant attributes. First, the submitter is ALWAYS known and recorded, and everyone who gets software from the library (for which a production fee is charged; the cost is NOT paying for the software, but is covering part of the cost of running a fulltime library) has that name. What you get is a copy of what the submitter sent in. The production machines aren't on any nets or outside hookups; this makes them fairly resistant to penetration by ill-doers. Further, there's a central office with people who answer the phone. When covert behavior of a program is detected, here's what happens: 1. The program is pulled from further distribution. 2. People are notified by whatever means are available (which these days will include the net) about the nature of the problem and all specifics that are known. 3. Efforts are made if the program was otherwise useful to reset the covert behavior and distribute the cleaned-up one together with a complete analysis of what happened. Source code is usually available also. This happened only once so far where a program had a covert time-out. The damage to someone's reputation when he submits a program and suffers all the adverse publicity which we can and WILL produce is such that there's not much incentive to try putting covert behavior into programs going into the DECUS library. Besides this, a good many of us use the code and look for "funny" stuff. It's not organized so that there's 100% coverage, and we don't want to say there is coverage even where it exists in too strong a form; we are after all human and don't want lawsuits by someone who says we should have tested more. But there are paths for reporting odd behavior and reacting to it. This applies to the sig tapes also, which are produced and distributed outside the DECUS library as well as contributed to it. Most funny behavior that's been reported are version or site dependencies (which can be quite hard for an author to detect) and we try to tell what we find. In all, the path from author to recipient is probably shorter dealing with DECUS library stuff or SIG tape stuff than it is for most commercial software, and we won't and haven't concealed any reported covert behavior; we are best protected by publicizing any such as quickly and widely as possible. Be sure this list will get such reports, as well as info-vax/comp.os.vms and, if we find a worm orv virus, virus-l. We do ask that people using the code help by reporting any odd behavior. You can call the DECUS office (508 480 3418 will get you into the office, though you'll need probably another extension to which you can be transferred) or me (215 354 7610) (me for sig tape info; the DECUS office for any, by preference) or Ted Nieland (513 427 6355) for SIG tape info also. To the extent we watch one another's backs, we're all the safer. Funny behavior in this case means suspected covert behavior by a program. If you have a systems program written, say, for VMS V4.7 and try running it on VMS 5.3-1 symmetric multiprocessors, you should expect it to fail in many cases. We're more interested thee there in what succeeds. However, timeouts, odd use of privs, writing files or modifying files that aren't documented, and the like are of interest. I understand the concerns about trojans or viruses, but these are probably more likely in commercial software than people realize. Your path from the submitter to you is as short dealing with the DECUS library as it is buying direct from a commercial vendor, and shorter than if the software passes through a store or distributor. The DECUS record of NOT concealing any problems is also public, and that policy will ultimately protect you further. Glenn Everhart VAX SIG librarian (DECUS) Everhart@Arisia.dnet.ge.com
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 28 Jun 90 18:18:42 GMT From: sson%remus.Berkeley.EDU%@RUTGERS.EDU (Stacey Son 377-4965) To: misc.security Subject: Re: Word Perfect Decryption
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 -----------------------------------------------------------------------------
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |