|
|
ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1990)
DOCUMENT: Rutgers 'Security List' for August 1990 (53 messages, 21388 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/08.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 Aug 90 03:00:00 GMT From: WHMurray@DOCKMASTER.NCSC.MIL To: misc.security Subject: ITSEC
Observations and Comments on the ITSEC
The ITSEC, Information Technology Security Evaluation
Criteria, represents the harmonization of the evaluation
criteria work done by the UK, Germany, France, and the
Netherlands. The work is in part a response to the Trusted
Computer Security Evaluation Criteria of the US Department
of Defense, in part an attempt to update that work. For
example, the use of the term "Information Technololgy" in
place of computer recognizes that the issue is now broader
than it was when the TCSEC was written. It is also a
response to a concern on the part of these governments that
the TCSEC was part of a DoD plot to exclude their products
from the US market, a concern aggravated by the DoD's
refusal, on national security grounds, to evaluate foreign
built products. (I have never been certain whether the
Europeans really believed in this conspiracy, or simply
asserted it to get funding for what they intended to do
anyway.)
The ITSEC describes language and criteria to be used in the
evaluation of security features, functions, and properties
of computer products. It is independent of any program,
commitment, or intent to do such evaluations.
The use of the English language is excellent. The text is
clear, precise, and well ordered. With a few exceptions
English language words retain their normal meaning. (There
do not appear to be any secret code words here; trusted
means trusted, and secure means secure (rather than the
reliable enforcement of the author's favorite policy).
Likewise there are no reserved words; classified means
classified, not CLASSIFIED.)
It would be naive to believe that there are no politics or
arguments reflected in a document that represents the
"harmonisation" of the efforts of four nation states.
However, the ones here are sufficiently subtle as to escape
the notice of this practiced observer. The document is
almost totally free of rhetoric.
Important and useful distinctions are drawn, for example
between product (that which a vendor offers), system (a
product instance which someone uses), and target of
evaluation (TOE) (that which is offered or sponsored for
evaluation). Also, between assurance, correctness, and
effectiveness.
In drawing the distinction between product and system, the
document acknowledges Courtney's first law, i.e. "Nothing
useful can be said about the security of a product/system
except in the context of a particular application and
environment." (Courtney was never able to get the authors
of the TCSEC to acknowledge the distinction.) It notes that
a principal difference between products and systems is what
is known about their environments (and applications); that
one may only assume about products what one can know about
systems. Having said that, the authors argue that for sake
of consistency, the same evaluation criteria should be used
for both.
Perhaps the most important distinction that the ITSEC offers
is that between functionality and assurance. Indeed, they
employ separate scales for the evaluation of these. This is
a concession to those of us who have complained about the
lumping of these in the TCSEC. This results in a more
granular set of criteria which permits a fairer comparison
of products. It does so at the expense of a larger number
of points on the scale. On the other hand, it does away
with the need for the infamous digraph.
As in the TCSEC, assurance levels are based upon the rigor
of the applicable and applied methodology, rather than upon
the requirements of the application and environment. The
descriptions of the levels appears to be simpler and more
granular than those in the TCSEC. However, the highest
defined level, E6, does not seem to be as rigorous as that
required for A1. Nonetheless, the scale is open at the top
end; more rigorous methods could be specified as required.
There is something to be said for resticting oneself to
methods that are employed in the real world, rather than
arguing for arbitrary rigor that has not ever before been
employed.
Another important distinction that the ITSEC draws is
between the Corporate (institutional?) Security Policy and
the System Security Policy. It is well known that the both
the British and the Germans feel that the application of the
DoD Mandatory Policy results in a tendency for data to
migrate toward the highest classification. They were
anxious to have criteria that were independent of this
policy.
Identification is lumped with Authentication and is applied
only to users. No consideration is given to the
identification of objects or other subjects such as
processes.
Likewise the term "attributes" is used for both object
sensitivity labels and user credentials. While this is
likely to be confusing to someone that does not already know
what is intended, it is still better that using
"classification" for both objects and subjects.
Because the ITSEC is marginally more granular than the
TCSEC, the classes of the TCSEC may be mapped on to the
ITSEC. This is done and provided in an appendix. However,
the converse is not true; that is, it is not possible to
express the evaluation classes of the ITSEC in terms of the
TCSEC.
Security functionality for a product is expressed in claims.
There are no requirements or design points set forth as in
the TCSEC. However, the claims may be made by reference to
a pre-defined set of functionality classes. The criteria
define ten such classes. While the first five are derived
from the functionality of the TCSEC classes C1 thru B3/A1,
they are essentially arbitrary. Sub-classes, super-classes
or alternate sets could be defined without doing damage to
the structure. (For example, I have longed claimed that the
commercial requirement looked something like C2 plus ACLs
plus named transaction types. Since functionality classes
in the ITSEC are arbitrary, not hierarchical, and not bound
to assurance, it would be correct and proper to define a
class that looked like that.)
The more I read it, the better I like it.
William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: 2 Aug 90 13:55:54 GMT From: PGOODWIN@GTRI01.GATECH.EDU (Paul Goodwin) To: misc.security Subject: break-in detection
The point at which you are most likely to identify that someone is breaking into a system is while that person is attempting to gain access to an account. Once he has an account USERID and PASSWORD, detection becomes much more difficult. Making the authorized users of a system periodically change their passwords may suddenly deny access to an unauthorized user, causing him to once again 'hack' at the system until he gains entry. This will make him much more visible, and much more likely to be caught. Disclaimer: I am, of course, speaking solely for myself. Paul Goodwin Office of Computing Services Ga. Inst. of Technology
-----------[000002][next][prev][last][first]---------------------------------------------------- From: barmar@think.com (Barry Margolin) 5-AUG-1990 0:33:10 To: misc-security@husc6.harvard.edu
It's described pretty well in the SunOS 4.1 documentation. There's a decent overview of it in one of the administration manuals (named something like "System & Network Administration". And there's a more precise description starting on p.156 of "Network Programming" (the chapter claims to be a copy of RFC-1050). Sun's secure RPC makes use of Diffie-Hellman public-key encryption and DES encryption. -- Barry Margolin, Thinking Machines Corp.
-----------[000003][next][prev][last][first]---------------------------------------------------- From: EVERHART@arisia.dnet.ge.com 5-AUG-1990 0:51:24 To: security@pyrite.rutgers.edu
If looking for a secure distributed file system, I'd suggest checking out AFS, from Transarc. It uses Kerebros authentication, and supplies tools for maintenance of large networks. It was designed for 10,000+ workstation environments and scales much better than NFS; also tends to avoid eating networks for lunch as NFS can and does. Transarc is in Pittsburgh; 412 338 4400; their domain name is transarc.com. Glenn
-----------[000004][next][prev][last][first]---------------------------------------------------- From: DANCC@cunyvm.cuny.edu 5-AUG-1990 1:09:19 To: SECURITY@rutgers.edu
Sorry if this is too elementary for the group, but I'm at sea. I've seen what I want, but can't find it in any catalog. It's sheetmetal cage, open only on front. You bolt or glue it to a table, attach the CPU to a sliding deal which locks into the cage, and there you are. Thief can't walk away with the whole thing, and can't open cover to steal cards. With time, tools, knowledge, and some assurance the guard won't be by for 20 minutes . . . but it raises the threshhold. Saw one at a school in California, but my host didn't know the source. He had been using them for some kind of PC clone, but they fit his new Mac IIs also. I assume they come in different sizes. Much appreciate any pointers.
-----------[000005][next][prev][last][first]---------------------------------------------------- From: de5@stc06.ctd.ornl.gov (SILL D E) 5-AUG-1990 1:25:38 To: misc-security@ucbvax.berkeley.edu
>Now the REAL story: the number factored was of a very special form, AARRGGHH!! Apparently you missed the recently posted article (comp.risks?) by Ron Rivest (the `R' in RSA) that gave the REAL story. Actually, both of the above posters are (in)correct. The number factored was of the form 10000...00001 (binary). Such numbers are used by RSA only by coincidence, that is to say very rarely. Rivest further conjectured that that and other developments in factoring would lead to the breaking of some short-key RSA within a couple years, I believe (this is from memory, I forget the numbers). He also said they were recommending longer keys for paranoids...er... folks wanting utmost security. Anybody save that article? How 'bout posting it or sending me a copy? -- -- Dave Sill (de5@ornl.gov) These are my opinions. Martin Marietta Energy Systems Workstation Support
-----------[000006][next][prev][last][first]---------------------------------------------------- From: GREENY <MISS026@ecncdc.bitnet> 5-AUG-1990 22:37:00 To: <security@pyrite.rutgers.edu>
A lot of people have been asking me for the Oregon Sci. #, so I did some digging, and found it! Here it is: Oregon Scientific, Inc. 10950 S.W. 5th Street, Suite #275 Beaverton, OR 97005 1-503-646-9806 1-503-641-8015 FAX 1-800-869-7779 (according to a friend of mine....) Hiope this helps, and hope your cars, offices, boats, and homes are yelling soon! :-> Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU GEnie: GREENY AOL: GREENY1 Compu$erve: 72567,457
-----------[000007][next][prev][last][first]---------------------------------------------------- From: pyron@skvax1.csc.ti.com (If Clayton's an Aggie, I'm not!) 5-AUG-1990 23:06:21 To: "CSMSPCN@oac.ucla.edu"@skvax1.csc.ti.com Cc: "security@pyrite.rutgers.edu"@skvax1.csc.ti.com, PYRON@skvax1.csc.ti.com
>recently factored a 155 digit number, and that they are consequently
>recommending at least 200 digit primes for the RSA stuff.
The original article in CACM recommended 200 digit numbers, but made note of
the fact that factor these larges numbers was difficult, which is both a
blessing and a curse. Of course, difficult in 1977 is a breeze in 1991?
Dillon Pyron | The opinions are mine, the facts
TI/DSEG VAX Systems Support | probably belong to the company.
pyron@skvax1.ti.com |
(214)575-3087 | Jim Henson - Now that was talent
|
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 4 Aug 90 18:48:00 GMT From: JUTBAAA@iup.BITNET (Abhik Biswas) To: misc.security Subject: Papers on computer security....
Are there any archives of papers related to computer security either at sites on Internet or Bitnet? Any information will be appreciated.
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 5 Aug 90 05:14:07 GMT From: krfall@UCSD.EDU To: misc.security Subject: Re: "secure nfs"
> If looking for a secure distributed file system, I'd suggest checking > out AFS, from Transarc. It uses Kerebros authentication The currently released version (3.0) does not yet use Kerberos (at least so I have been told). That would be the case for the AFS being released through Mt. Xinu as well. Project Athena has modified the authentication program (klog?) to produce one which scrawls a v4 Kerberos ticket inside the AFS tokens (aklog), and made corresponding changes for their server software. AFS 4 is evidently on the way from Transarc, as is v5 Kerberos from Athena. One might expect a merger of these systems in the future. These ideas are also being monitored by the Distributed File Systems working group of the IETF (dfs-wg-request@citi.umich.edu). - Kevin
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 7 Aug 90 01:23:27 GMT From: jpc@fctunl.rccn.pt (Jose Pina Coelho) To: misc.security Subject: Re: criminal record
> It is possible to write to the FBI and ask them if they have a folder on I doubt they would send you more than 10% of the folder. [Moderator tack-on: Speculation is fine, but that's all anyone has sent in so far. Does anyone have *FACTS* about this? _H*]
-----------[000011][next][prev][last][first]---------------------------------------------------- From: annala@neuro.usc.edu (A J Annala) 12-AUG-1990 0:31:18 To: misc-security@ucbvax.berkeley.edu
I do some data communications technician type contracting work from time to time (e.g. installing modems, analog line testing, protocol analysis, etc). There have been notes on the network about police confiscating equipment of the type I often use in my work. The police claim is that such devices are telephone access devices which should not be in the hands of the public. I am curious about whether any other technical people have been challenged by the police and what answer has satisfied them to go away without hassle. AJ
-----------[000012][next][prev][last][first]---------------------------------------------------- From: WHMurray@dockmaster.ncsc.mil 12-AUG-1990 0:48:18 To: security@rutgers.edu
Observations and Comments on the ITSEC
The ITSEC, Information Technology Security Evaluation
Criteria, represents the harmonization of the evaluation
criteria work done by the UK, Germany, France, and the
Netherlands. The work is in part a response to the Trusted
Computer Security Evaluation Criteria of the US Department
of Defense, in part an attempt to update that work. For
example, the use of the term "Information Technololgy" in
place of computer recognizes that the issue is now broader
than it was when the TCSEC was written. It is also a
response to a concern on the part of these governments that
the TCSEC was part of a DoD plot to exclude their products
from the US market, a concern aggravated by the DoD's
refusal, on national security grounds, to evaluate foreign
built products. (I have never been certain whether the
Europeans really believed in this conspiracy, or simply
asserted it to get funding for what they intended to do
anyway.)
The ITSEC describes language and criteria to be used in the
evaluation of security features, functions, and properties
of computer products. It is independent of any program,
commitment, or intent to do such evaluations.
The use of the English language is excellent. The text is
clear, precise, and well ordered. With a few exceptions
English language words retain their normal meaning. (There
do not appear to be any secret code words here; trusted
means trusted, and secure means secure (rather than the
reliable enforcement of the author's favorite policy).
Likewise there are no reserved words; classified means
classified, not CLASSIFIED.)
It would be naive to believe that there are no politics or
arguments reflected in a document that represents the
"harmonisation" of the efforts of four nation states.
However, the ones here are sufficiently subtle as to escape
the notice of this practiced observer. The document is
almost totally free of rhetoric.
Important and useful distinctions are drawn, for example
between product (that which a vendor offers), system (a
product instance which someone uses), and target of
evaluation (TOE) (that which is offered or sponsored for
evaluation). Also, between assurance, correctness, and
effectiveness.
In drawing the distinction between product and system, the
document acknowledges Courtney's first law, i.e. "Nothing
useful can be said about the security of a product/system
except in the context of a particular application and
environment." (Courtney was never able to get the authors
of the TCSEC to acknowledge the distinction.) It notes that
a principal difference between products and systems is what
is known about their environments (and applications); that
one may only assume about products what one can know about
systems. Having said that, the authors argue that for sake
of consistency, the same evaluation criteria should be used
for both.
Perhaps the most important distinction that the ITSEC offers
is that between functionality and assurance. Indeed, they
employ separate scales for the evaluation of these. This is
a concession to those of us who have complained about the
lumping of these in the TCSEC. This results in a more
granular set of criteria which permits a fairer comparison
of products. It does so at the expense of a larger number
of points on the scale. On the other hand, it does away
with the need for the infamous digraph.
As in the TCSEC, assurance levels are based upon the rigor
of the applicable and applied methodology, rather than upon
the requirements of the application and environment. The
descriptions of the levels appears to be simpler and more
granular than those in the TCSEC. However, the highest
defined level, E6, does not seem to be as rigorous as that
required for A1. Nonetheless, the scale is open at the top
end; more rigorous methods could be specified as required.
There is something to be said for resticting oneself to
methods that are employed in the real world, rather than
arguing for arbitrary rigor that has not ever before been
employed.
Another important distinction that the ITSEC draws is
between the Corporate (institutional?) Security Policy and
the System Security Policy. It is well known that the both
the British and the Germans feel that the application of the
DoD Mandatory Policy results in a tendency for data to
migrate toward the highest classification. They were
anxious to have criteria that were independent of this
policy.
Identification is lumped with Authentication and is applied
only to users. No consideration is given to the
identification of objects or other subjects such as
processes.
Likewise the term "attributes" is used for both object
sensitivity labels and user credentials. While this is
likely to be confusing to someone that does not already know
what is intended, it is still better that using
"classification" for both objects and subjects.
Because the ITSEC is marginally more granular than the
TCSEC, the classes of the TCSEC may be mapped on to the
ITSEC. This is done and provided in an appendix. However,
the converse is not true; that is, it is not possible to
express the evaluation classes of the ITSEC in terms of the
TCSEC.
Security functionality for a product is expressed in claims.
There are no requirements or design points set forth as in
the TCSEC. However, the claims may be made by reference to
a pre-defined set of functionality classes. The criteria
define ten such classes. While the first five are derived
from the functionality of the TCSEC classes C1 thru B3/A1,
they are essentially arbitrary. Sub-classes, super-classes
or alternate sets could be defined without doing damage to
the structure. (For example, I have longed claimed that the
commercial requirement looked something like C2 plus ACLs
plus named transaction types. Since functionality classes
in the ITSEC are arbitrary, not hierarchical, and not bound
to assurance, it would be correct and proper to define a
class that looked like that.)
The more I read it, the better I like it.
William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL
-----------[000013][next][prev][last][first]---------------------------------------------------- From: Jim Pinson <JPINSON@uga.cc.uga.edu> 15-AUG-1990 12:16:04 To: security@pyrite.rutgers.edu
I make up my passwords based on the first letters of a phrase which has meaning only to me. Examples: My First Grade Teacher Was Miss Jones = MFGTWMJ I Hate Boiled Okra With A Passion = IHBOWAP These passwords are easy to remember, fairly random in nature, and very hard to guess. Jim Pinson University of Georgia.
-----------[000014][next][prev][last][first]---------------------------------------------------- From: jpc@fctunl.rccn.pt (Jose Pina Coelho) 15-AUG-1990 12:36:50 To: security@pyrite.rutgers.edu
> It is possible to write to the FBI and ask them if they have a folder on I doubt they would send you more than 10% of the folder. [Moderator tack-on: Speculation is fine, but that's all anyone has sent in so far. Does anyone have *FACTS* about this? _H*]
-----------[000015][next][prev][last][first]---------------------------------------------------- From: jik@athena.mit.edu (Jonathan I. Kamens) 15-AUG-1990 12:53:24 To: security@pyrite.rutgers.edu
|> It is possible to write to the FBI and ask them if they have a folder on |> you and to send you a copy of the contents of the folder if the folder does |> exist. And, of course, if they don't have a folder on you, then the fact that you wrote to them and asked if they did would most assuredly prompt them to open a new one. (1/2 :-) Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
-----------[000016][next][prev][last][first]---------------------------------------------------- From: krfall@ucsd.edu 15-AUG-1990 13:10:53 To: EVERHART@arisia.dnet.ge.com Cc: security@pyrite.rutgers.edu
> If looking for a secure distributed file system, I'd suggest checking > out AFS, from Transarc. It uses Kerebros authentication The currently released version (3.0) does not yet use Kerberos (at least so I have been told). That would be the case for the AFS being released through Mt. Xinu as well. Project Athena has modified the authentication program (klog?) to produce one which scrawls a v4 Kerberos ticket inside the AFS tokens (aklog), and made corresponding changes for their server software. AFS 4 is evidently on the way from Transarc, as is v5 Kerberos from Athena. One might expect a merger of these systems in the future. These ideas are also being monitored by the Distributed File Systems working group of the IETF (dfs-wg-request@citi.umich.edu). - Kevin
-----------[000017][next][prev][last][first]---------------------------------------------------- From: Harry Flowers <FLOWERS@memstvx1.bitnet> 15-AUG-1990 13:26:18 To: security@pyrite.rutgers.edu
It seems that most of the replies to requiring password changes came back
against them, and some wondered why, if you have a good password, you should
be required to change it.
One of the computer operating systems here (not a VAX/VMS system) has recently
added a password expiration feature. Because "the auditors" (cringe) wanted
this, it was implemented. One surprising thing it turned up was there were a
number of people who had been sharing accounts for years who were not aware of
all the others using the same account... once the password changed, the others
couldn't get in. These "good" passwords had been shared over time, and rather
than go to the trouble of requesting another account (not much trouble), they
shared accounts.
This, of course, was a problem caused by bad password practices, not bad
passwords. And, if someone should happen to learn a password by whatever
means, be it a "good" or "bad" one, users may not notice that others are
using their account (how many of us look carefully at the last login date?).
The main advantage of frequent password changes is that if someone does happen
to see you type in your password or learn it by capturing network traffic, etc.,
no matter how careful they are to work undetected, they will eventually be shut
out of your account when you change the password. Those of us with privileged
accounts have to be extra-careful, as other means of getting in can be set-up
from privileged accounts. But your users are the ones least likely to realize
that their accounts have been compromised.
"A password is like a toothbrush: you never share it and you get
a new one every three months."
._ _. .___. ._. ._. v------------------------------------------------+
| \ / | / ____\ | | | | | Harry Flowers Phone: (901)678-2663 |
||\v/|| \____ \ | |_| | | Bitnet: FLOWERS@MEMSTVX1 Systems Programmer |
|| v || \_____/ \_____/ | Internet: not yet :-(, but soon :-) VAX/VMS |
Memphis State University | USmail: 112 Admin Bldg, MSU, Memphis, TN 38152 |
^------------------------------------------------+
P.S. We are going on the Internet soon using WIN TCP/IP. I'd appreciate any
information as to security problems we might encounter. Thanks.
-----------[000018][next][prev][last][first]---------------------------------------------------- From: "Andrew A. Houghton" <ah0i+@andrew.cmu.edu> 17-AUG-1990 2:25:15 To: security@rutgers.edu
I know this subject has probably been run into the ground, but could people please send me the addresses for good locksmithing schools, along with any thoughts they have about them (like relative merits, etcetera) Please e-mail, no need to post on the net. Andrew Houghton (ah0i@andrew.cmu.edu)
-----------[000019][next][prev][last][first]---------------------------------------------------- From: ctdonath@rodan.acs.syr.edu (Carl T. Donath) 17-AUG-1990 2:42:54 To: security@pyrite.rutgers.edu
Does anyone know where I could buy a simple alarm like this: a small box is attached onto/inside some hardware (a computer, VCR, whatever) that will sound an alarm when it detects motion (by tilting, acceleration, whatever). It must run off a battery and be quite hard to disable. Where can I buy one? - Carl
-----------[000020][next][prev][last][first]---------------------------------------------------- From: tep@tots.logicon.com (Tom Perrine) 17-AUG-1990 3:13:15 To: security@pyrite.rutgers.edu
I have one of those cheap Master combination locks that I need to remove, and the combination is long gone. The options I can think of are (in order of preference): get combination from Master (from serial number) bolt cutters hacksaw Of course, the cheaper the better, so a locksmith is out. I'm not in any hurry, can I just call (or write) to Master and get the combination? I really don't care about the lock, but if I can get the combo, thats easier than finding some bolt cutters or spending an hour? with a hacksaw.... Any recommendations? Tom Perrine (tep)
-----------[000021][next][prev][last][first]---------------------------------------------------- From: Paul V Hardiman <hardiman@csd4.csd.uwm.edu> 18-AUG-1990 0:45:31 To: security-request@pyrite.rutgers.edu
I need to get information on the Kerberos security system. Can you give me the Internet address of a group or individual who can send me this information? Thank you
-----------[000022][next][prev][last][first]---------------------------------------------------- From: Abhik Biswas <JUTBAAA@iup.bitnet> 18-AUG-1990 1:07:06 To: security@ohstvma.bitnet
Are there any archives of papers related to computer security either at sites on Internet or Bitnet? Any information will be appreciated.
-----------[000023][next][prev][last][first]---------------------------------------------------- From: brendan@world.std.com (Brendan P Kehoe) 18-AUG-1990 1:26:06 To: security@rutgers.edu
You can get a copy of it (the "Orange Book") from gatekeeper.dec.com via anon ftp in the directory pub/misc (if I remember right). -- Brendan Kehoe | Soon: brendan@cs.widener.edu | temp: brendan@world.std.com Also: brendan@chinet.chi.il.us | Preferred: bkehoe@widener.bitnet
-----------[000024][next][prev][last][first]---------------------------------------------------- From: Paul Goodwin <PGOODWIN@gtri01.gatech.edu> 18-AUG-1990 1:46:50 To: MISC-SECURITY%LOCAL@gatech.edu
The point at which you are most likely to identify that someone is breaking into a system is while that person is attempting to gain access to an account. Once he has an account USERID and PASSWORD, detection becomes much more difficult. Making the authorized users of a system periodically change their passwords may suddenly deny access to an unauthorized user, causing him to once again 'hack' at the system until he gains entry. This will make him much more visible, and much more likely to be caught. Disclaimer: I am, of course, speaking solely for myself. Paul Goodwin Office of Computing Services Ga. Inst. of Technology
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 16 Aug 90 19:34:55 GMT From: cb2s+@ANDREW.CMU.EDU (Christopher Gene BeHanna) To: misc.security Subject: Re: "secure nfs"
Someone suggested AFS from Transarc. AFS has all the production capability of beta-test software. Being an administrator for it is a hell of a headache because AFS loses track of the different states of volumes in memory and in the vldb and they frequently get out of synch. The backup program is trash. I'd suggest holding out until several sites get 4.0 and see how things work out. Chris BeHanna These opinions are my own, not those of Carnegie Mellon or Pittsburgh Supercomputing Center, formulated by administering AFS this summer on pmaxen.
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 90 19:13:56 GMT From: denbeste@bgsuvax.UUCP (William C. DenBesten) To: misc.security Subject: Re: cheap Master combo lock
There exists a book that lists all of the combinations by serial number. Many locksmiths have this book. If you can demonstrate that you own the lock, they may look it up for you. I find it scary that the relationship exists. Personally, I prefer to use key locks with the serial/key number written in ink (I erase the number) or to use locks for which I set the combination. At least someone can't look up the number in a handy book. -- William C. DenBesten is denbeste@bgsu.edu or denbesten@bgsuopie.bitnet
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 17 Aug 90 20:46:39 GMT From: truel@IUVAX.CS.INDIANA.EDU (Bob Truel) To: misc.security Subject: Re: cheap Master combo lock
Have you tried taking a shoe with a good hard rubber sole to it? Back in high school, I saw someone open a master lock like this. I never tried it on my own, nor anyone elses, and can't guarantee that it will still work, but I never lock anything valuable with one.
-----------[000028][next][prev][last][first]----------------------------------------------------
Date: 17 Aug 90 20:55:00 GMT
From: WURZBACH@OSHKOSH.WISC.EDU ("William F. Wurzbach")
To: misc.security
Subject: RE: cheap Master combo lock
I had the same problem about a year ago and the solution was painless.
Go to the nearest hardware store that handles MasterLock locks. Explain to
someone there ( I approached the key-making department ) what the problem is,
get the address of the nearest MasterLock outlet or corporate headquarters,
and write a letter to them, explaining who you are, what the serial number of
the combination lock is, and giving the full address of the hardware store
you have made accommodations with. MasterLock will send the combination to
the hardware store ( authorized dealer ), where you can have them call you
or stop in periodically to check if it's arrived. No problem if you've got
the time.
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 90 17:44:58 GMT From: jkp@SAUNA.HUT.FI (Jyrki Kuoppala) To: misc.security Subject: Re: Papers on computer security....
I have put some security articles I have for anonymous ftp in nic.funet.fi [128.214.6.100] directory pub/doc/security. //Jyrki
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 18 Aug 90 19:24:57 GMT From: black@darkside.com (Black Death) To: misc.security Subject: (none)
Yes, but if the users choose good passwords, there won't be much
chance of anyone getting in at all. One good method is using a variety of
upper & lower case (ie pAsSwOrD) on UNIXs that will alow you to do that.
Another system which would make it nearly impossible to hack (beleive me, I
know) would be to take two words, combine them together and add a two-digit
number to the end (ie RUNWALK23)..If password security is not enough for
your system you may wish to invest in a filter
device, which will dramaticly reduce the numbe of people who even make it to
the "password:" prompt. It is important, however, that even when you get one
of these, you must still use good passwords. That should drasticly reduce
the amount of unwanted visitors on your system.
-----------[000031][next][prev][last][first]---------------------------------------------------- From: black@darkside.com (Black Death) 21-AUG-1990 15:44:53 To: misc-security@ucbvax.berkeley.edu
The only instance in which I have seen computer equipment confiscated is when the person in question is suspected of commiting some computer related crime. The situation you are talking about where your equipment was confiscated because it "should not be in the hands of the general public" is totaly disgusting. I do not know what it could be that you have that could pose such a huge threat to the telecommunications industry. What is it? bd/pha
-----------[000032][next][prev][last][first]---------------------------------------------------- From: pmorriso@gara.une.oz.au (Perry Morrison MATH) 21-AUG-1990 16:12:24 To: misc-security%munnari.mu.oz@munnari.oz.au
I'm interested in researching the nature, history, extent and motivations behind computer "crime". I'm not sure how to define it at this stage (that should happen after I've digested a much larger range of views), however I'm interested in researching system break-ins, computer based fraud and monetary or property theft, the history and alternative viewpoints behind hacking, unauthorised copying of software, viruses and any other topic that (at least in the eyes of some) verges on criminality. Pointers to key articles, journals, summaries of the literature or even isolated opinions would be greatly appreciated. Please don't flame this rather naive request. My opinions are pretty much unformed (and uninformed) at the moment, so any information can only help. I'd be happy to post a summary of what I get. Pointers to key personalities or researchers would also be extremely useful. Perry Morrison
-----------[000033][next][prev][last][first]---------------------------------------------------- From: <BRUGGMNJ@xavier.bitnet> 21-AUG-1990 16:40:56 To: security@pyrite.rutgers.edu
Actually I do know of a professor here at Xavier University that did
request his FBI folder. As I recall he had the assistance of a lawyer and
it took several weeks. What he got was a folder with newspaper clippings about
him and things his is involved with, plus what looked liked memos and notes.
Now not all of this was readable, somethings the FBI deemed 'classified' and
had blackened out words or phrases or sometimes the whole document. So you
could say he got the full folder, you just couldn't *read* it all.
There was a funny side to some of this, it seemed the FBI was very curious
about this 'women' that traveled with him. They said 'women' because while
they are married, she did not take his name. They thought it might
be worth noting that he traveled with 'another' women. That's about all I
have.
John
John Bruggeman Programmer/Analyst
bruggmnj@xavier.bitnet
Xavier University Cincinnati, OH
'Cincinnati, the only city where the only sin allowed is in the name!'
J.B.
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 20 Aug 90 23:23:06 GMT From: hollombe@ttidca.tti.com (The Polymath) To: misc.security Subject: Re: cheap Master combo lock
Use the hacksaw. If it's a cheap Master lock you should be able to cut
through it in under five minutes.
--
The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: hollombe@ttidca.tti.com)
Head Robot Wrangler at Citicorp(+)TTI Illegitimis non
3100 Ocean Park Blvd. (213) 450-9111, x2483 Carborundum
Santa Monica, CA 90405 {csun | philabs | psivax}!ttidca!hollombe
-----------[000035][next][prev][last][first]---------------------------------------------------- From: smb@ulysses.att.com (Steven Bellovin) 23-AUG-1990 10:18:01 To: misc-security@att.att.com
> ... would most assuredly prompt them to open a > new one. (1/2 :-) It should be a zero smiley; the statement is quite literally and definitely true. They have a special category for Freedom of Information Act requests in their filing system. (Source: the ACLU.)
-----------[000036][next][prev][last][first]---------------------------------------------------- From: dee@xait.xerox.com (Donald Eastlake) 23-AUG-1990 10:32:07 To: misc-security@linus.mitre.org
I have not actually done this but, as I recall, there is a way to send
a set of your own fingerprints along with a small fee to the FBI and have
them send you back a listing of all the times your fingerprints have been
filed/looked up through them. This document is traditinally called a "rap
sheet" because for someone who has been frequently arrested it would mostly
be a list of the arrests since you are usually fingerprinted when arrested.
The info is sent back by Registered Mail, deliver to addressee only, so you
have to show ID when the post office delivers it. I don't know if the last
entry will be your query or if that's added after the query is processed.
--
+1 617-969-9570 Donald E. Eastlake, III
ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee
AppleLink: D2002 Box N, MIT Branch PO, Cambridge, MA 02139 USA
-----------[000037][next][prev][last][first]---------------------------------------------------- From: edelheit@smiley.mitre.org (Jeff Edelheit) 23-AUG-1990 10:51:06 To: don@delta.com Cc: security@pyrite.rutgers.edu
Gould's UNIX was evaluated and certified at the C2 level a long time ago. AT&T's System V/MLS was evaluated and certified at the B1 level last September. There are several other vendor's versions of UNIX that are in evaluation at the B1 level. I would not associate a C2 as a "poor" rating. Rather, C2 provides discretionary access control, audit and several other security services. The significance of B1 and above is that B1 systems provide mandatory access control. In most systems, mandatory access control is implemented on a label-based mechanism. This means if the user has a label attached to him/her at the "Unclassified" level, there are sufficient mechanisms and assurances that the user cannot access information (e.g., files, directories) at the "Secret" level. Honeywell's SCOMP was evaluated and certified at the A1 level and Honeywell's XTS-200 is under evaluation at the B3 level. Regards, Jeff Edelheit (edelheit@mitre.org) The MITRE Corporation 7525 Colshire Drive McLean, VA 22102
-----------[000038][next][prev][last][first]---------------------------------------------------- From: smb@ulysses.att.com 23-AUG-1990 11:03:53 To: security@rutgers.edu
Anyone can write to the FBI requesting a copy of their files under provisions of the Freedom of Information Act. With some exceptions, they are obligated to send the files to you. If they don't have a file on you when you send in your request, they'll open one, in the FOIA section. There's some mumbo-jumbo you're supposed to include to make sure they check all of the categories, but I don't recall what that is. They will delete names of other people if mention would violate their privacy. They're also entitled to delete material pertaining to active criminal investigations, or ``national security'' information. This info is from memory, but taken from a ACLU newsletter. As I recall, they also publish a booklet on the FOIA; if you're serious about getting your FBI files, I'd try to get the booklet first. In general, the government is entitled to collect a modest per-page charge for FOIA requests, but I'm not sure if that applies to requests of this nature. --Steve Bellovin P.S. No, I've never gotten around to asking for my own files, though I keep meaning to. I'm not even sure what I want to find out -- if there's no file on me, it would indicate that I didn't speak up loudly enough or forcefully enough during my activist days 20 years ago....
-----------[000039][next][prev][last][first]---------------------------------------------------- From: faigin@aerospace.aero.org 23-AUG-1990 11:17:32 To: security@rutgers.edu Cc: don@delta.com
Generic Unix has no rating, only specific implementations. The only UNIX systems on the evaluated products list are: System Evaluation Date Rating Gould UTX/32S rel 1.0 31 Dec 86 C2 AT&T System V/MLS v1.1.2 on UNIX SVR3.1.1 running on 3B2/500 or 3B2/600 07 Sep 89 B1 Standard UNIX System V has no rating. Also, C2 is not a "poor" rating by any means. C2 is the best rating that a UNIX system can get without adding support for Mandatory Access Control. Assuming an evaluation, operating system extensions can easily extend Unix to C2, by adding appropriate support for auditing, identification and authentication, and assurances such as documentation, and testing. B1 can also be reached easily by adding MAC support. B2 is much harder, because the assurance requirements state: The TCB shall be internally structured into well-defined largely independent modules. It shall make effective use of available hardware to separate those elements that are protection-critical from those that are not. The TCB modules shall be designed such that the principle of least privilege is enforced. Features in hardware, such as segmentation, shall be used to support logically distinct storage objects with separate attributes (namely: readable, writeable). The user interface to the TCB shall be completely defined and all elements of the TCB identified. UNIX is not well structured internally; reworking a UNIX implementation to B2 would require rewriting major chunks of the kernel. >I've not heard of an out-of-the-box implementation in the A classification... First of all, there is only one A classification. On the EPL, there is only one A1 system, which was the first evaluated system, which is no longer marketed. If there were more A1 systems on the EPL, they would certainly be "out of the box" systems. Daniel
-----------[000040][next][prev][last][first]---------------------------------------------------- From: guhsd000@crash.cts.com (Paula Ferris) 24-AUG-1990 0:02:01 To: misc-security@ucsd.edu
Someone stole my book on the subject, but under the Freedom of Information Act, federal agencys are required to release information gathered by the agency in anyform, in most circumstances. There are set time limits on when the information is released, (I think the time is started when you make a formal request for the documentation) and can take a long time to clean, and clear the red tape. I belive CBS just recived some information pertaininto Vietnam requested in the 70's only this year. I'm sorry I can't be more help, but basically, as I recall, you make a formal request on paper (Keep a copy) to the records center of the department, and demand the information, (this is important) including all pages, title pages, blank pages, markers, notes and tabs, fron and back. They do have a few exclusions they can hide behind, the FBI is the most frequent user of these. They are allowed to edit out any information that they deem may demonstrate internal workings or investigative operations of their department. Besure to request edited pages, and again, demand, an explanation of EACH edit. You can also ask that fees be waived, they usally are if the file is small. I don't recall the time limits and formalities of processing, but sooner or later it has to come out, but they are great at stalling, and don't expect much, in FOIA's from the FBI I've examined, they have often taken a page, Photocopied it, go over each line with a black marker, and re-copied it, and included it in the requested document as edited. Explanation and Justification of each edit can help you piece together what they edited out by looking up the section numbers under which they will give as justification, usally the one pertaining to the protection of information gathering techniques. Hale Telecommunications Incorperated - KKLR & KALE
-----------[000041][next][prev][last][first]---------------------------------------------------- From: "Michael J. Chinni, SMCAR_CCS_E" <mchinni@pica.army.mil> 24-AUG-1990 0:24:27 To: security@pyrite.rutgers.edu
-------------
To: cert-tools@cert.sei.cmu.edu
Subject: Sun Microsystem's Warning System
Date: Wed, 15 Aug 90 15:01:04 EDT
From: Richard Pethia <rdp@cert.sei.cmu.edu>
CERT Tools members,
At the June 1990 Workshop on Computer Security Incident Handling, Sun
Microsystems announced their intent to implement a Customer Warning
System and described several of its characteristics.
Yesterday, the CERT/CC at the SEI received the announcement below.
The announcement, distributed internally to Sun employees, provides
more information on the characteristics of the warning system, and,
more importantly, describes the methods Sun Microsystem's customers
should use to report problems and to sign up to receive warnings from
Sun Microsystems.
Beverly Ulbrich, Sun Product Manager, Software Security, has told us
that a formal press release will probably be released by Sun, but has
asked us to redistribute this announcement to the lists we maintain.
We are doing so to provide people with information on Sun's action.
Sun's Customer Warning System promises to be a significant step
forward in dealing with computer security incidents and their
prevention, and represents the type of action I would like to see
other vendors take.
Since the CERT/CC will be actively working with other vendors this
fall and encouraging them to take similar steps, please let me know
about any opinions you have regarding this type of vendor mechanism.
Please direct any questions you have about the specifics of Sun's
mechanism to one of the Sun employees listed below.
Sincerely,
Rich Pethia
CERT Coordinator
---------------------------------------------------------------------
To: All Sun Employees
From: Beverly Ulbrich - Product Manager, Software Security
Jack Collins - Director, Technical Support Services
Subject: Announcing Sun Microsystem's Customer Warning System
for Security Incident Handling
Date: August 14, 1990
In order to best serve our customers' service needs, Sun has established a
Customer Warning System (CWS) for handling security incidents. This is a
formal process which includes:
- Having a well advertised point of contact in Sun for reporting
security problems.
- Pro-actively alerting customers of worms, viruses or other security
holes that could affect their systems.
- Distributing the patch (and/or work-around) to our customers as
quickly as possible.
More specifically, the CWS is being set up as follows:
We have created an email address ( security-alert@sun ) which will enable
both internal and external people to have a single place to report security
problems. We have provided a voice-mail back-up ( (415)-336-7205 ) for the
cases where sending email is not possible. *ALL* SECURITY HOLES SHOULD BE
REPORTED TO THIS ALIAS.
We have filled the position of "Security Coordinator" in our Customer Service
Organization. The Security Coordinator is responsible for manning the email
and voice mail hotlines and evaluating the security problems. We have a
Customer Warning System "SWAT Team" in place to address severe security
incidents. The CWS SWAT Team consists of knowledgeable senior people within
Sun Corporate who are committed to being available to meet whenever required
and who are empowered to make all necessary decisions.
We plan on publicizing the CWS bi-monthly to the allsun alias. It will
also be announced (and supported) by the various Computer Emergency Response
Teams Sun works with. Please pass this information along to whoever you
feel is appropriate. Sales Representatives should be certain to send this
information to all their security-conscious customers!
Customers and Sun Field Offices may send us a "Security Contact" from their
organizations. This is the person Sun should contact in the case of any
new security problems. He or she will be sent information on the problem at
hand, including work-arounds and how and when to obtain fixes. Preferably,
your Security Contact should be technical. He or she should be your site's
System Administrator (or System Security Administrator). The information we
need for the Security Contact from the three geographies for customers is as
follows:
---------------------- U.S. Security Contact Information --------------------
Company Name:
Security Contact's Name:
Customer Number (from Cullinet):
Address ID (from Cullinet)*:
Postal address:
Email address:
Phone number:
Fax number:
Preferred method of contact (from above: 1st, 2nd and 3rd choice):
* If there is not an existing Address ID, we need the full address for
the security contact.
----------------- Europe and ICON Security Contact Information ---------
Company Name:
Security Contact's Name:
Customer Number:
Address Id:
If there is no customer number or Address ID, then we need the following
information for each customer:
Postal Address:
Email Address:
Phone Number:
Fax Number:
Preferred method of contact (from above: 1st, 2nd and 3rd choice):
--------------- Sun Field Office Security Contact Information ---------------
Office Location:
Security Contact's Name*:
Email address:
*One per office
----------------------------------------------------------------------------
***** PLEASE SEND THIS INFORMATION TO: *****
security-alert@sun.com
or, if you prefer postal mail:
Brad Powell
c/o Sun Microsystems
MTV18-04
2550 Garcia Ave.
Mt. View, CA 94043
All questions should be sent to bju@sun.com.
**CERT-Tools Information:****************************************************
* Submissions : cert-tools@cert.sei.cmu.edu *
* Address additions/deletions/changes : cert-tools-request@cert.sei.cmu.edu *
* Moderator : tools@cert.sei.cmu.edu *
*****************************************************************************
-----------[000042][next][prev][last][first]---------------------------------------------------- From: Simon Travaglia <CCC_SIMON@waikato.ac.nz> 24-AUG-1990 14:57:43 To: security@rutgers.edu
Hi There. We use a Chubb 8108 system controlling 3 Chub 8100 door controllers, and here's our problem. Every now and then (we've had them since December 1989) one of the 8100s will go haywire and start running (on the two doors it controls) through a cycle of <Locked>,<Enter PIN>,<Unlocked>. During the unlock part, the door will be unlocked for about half a second. The cycling will continue until the unit has been reset. We would like to know if anyone else has had this problem, as it can be a real pain. The Chubb guys said it was bad earthing, then 2 months later it was back again, after the problem had apparently been fixed. Anyone got any ideas.
-----------[000043][next][prev][last][first]---------------------------------------------------- From: "Larry Margolis" <MARGOLI@ibm.com> 24-AUG-1990 15:20:57 To: security@pyrite.rutgers.edu
When I had to do something similar a few years ago, (we had students
coming in for 1 to 3 month classes; we'd have to create a block of
between 20 and 300 userids before the class, and delete them afterwards),
I wrote an exec that would be given the class number (which determined
the student prefix), and the number of IDs needed, and it would
(1) Create that number of userids, from XYZ001 to XYZnnn;
(2) Create a SCRIPT file that printed off a Welcome to the Computer
letter, specifying their userid and randomly generated password; and
(3) Printed out mailing labels for these letters.
It could also be called to delete the userids en mass after the class
was over.
It's all pretty easy. The only time-consuming thing was tracing through
DIRMAINT and all the stuff it calls until I located the DVH module that
actually sent the DIRM ADD request to the DIRMAINT machine. I then
called that routine directly. That way, my exec could ask for the
privileged user's password once, and use it for all the calls to the
lower-level module.
(Eventually, I got fancy, and had the exec pass the arguments to a
privileged service machine, which would do all the DIRM requests, and
interpret the output and only bother me if anything went wrong. It would
also by default (could be overridden) wait until 2:00 AM to issue the
request, so that the DIRMAINT service machines wouldn't be tied up
adding hundreds of users during prime shift.)
Larry Margolis, MARGOLI@YKTVMV (bitnet), MARGOLI@IBM.COM (csnet)
-----------[000044][next][prev][last][first]---------------------------------------------------- From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) 28-AUG-1990 4:31:20 To: hardiman@csd4.csd.uwm.edu Cc: security-request@pyrite.rutgers.edu
You can FTP papers on Kerberos from athena-dist.mit.edu
-----------[000045][next][prev][last][first]---------------------------------------------------- From: Christopher Gene BeHanna <cb2s+@andrew.cmu.edu> 28-AUG-1990 5:04:08 To: security@pyrite.rutgers.edu
Someone suggested AFS from Transarc. AFS has all the production capability of beta-test software. Being an administrator for it is a hell of a headache because AFS loses track of the different states of volumes in memory and in the vldb and they frequently get out of synch. The backup program is trash. I'd suggest holding out until several sites get 4.0 and see how things work out. Chris BeHanna These opinions are my own, not those of Carnegie Mellon or Pittsburgh Supercomputing Center, formulated by administering AFS this summer on pmaxen.
-----------[000046][next][prev][last][first]---------------------------------------------------- From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) 28-AUG-1990 5:23:54 To: jpc@fctunl.rccn.pt Cc: security@pyrite.rutgers.edu
Under the Freedom of Information Act and the Privacy Act, they are required to send you the entire folder, with a few exceptions: 1. Ongoing investigations are exempt. 2. Information that could endanger field operatives may be censored. 3. Other "classified" information can be removed. Most people, turns out, don't have FBI folders on them. Unless you lived in the 1950s and 1960s and were an activist, that is. If you did, you can get your folder by contacting your local FBI office; they have an address that you can send a notorized letter to asking for your folder. You have to provide some personal information, but not a whole lot. I did it; I didn't have a folder (at the time), disproving the assertion that all MIT students automatically get FBI folders when they register.
-----------[000047][next][prev][last][first]---------------------------------------------------- From: Bob Truel <truel@iuvax.cs.indiana.edu> 29-AUG-1990 6:11:17 To: misc-security@rutgers.edu
Have you tried taking a shoe with a good hard rubber sole to it? Back in high school, I saw someone open a master lock like this. I never tried it on my own, nor anyone elses, and can't guarantee that it will still work, but I never lock anything valuable with one.
-----------[000048][next][prev][last][first]---------------------------------------------------- From: pmartin@mcc.com 29-AUG-1990 6:32:27 To: tep@tots.logicon.com, security@pyrite.rutgers.edu
For "locker" style Master combo locks, you can probably doe the combinatorics of the "soft spots" on it in under 10 minutes. Some of the newer ones seem to have an extra mechanism to make it harder to detect these points.... I've taken to actually writing down my combo with these as it is such a pain to discover the combo from experimentation... Even so, the right answer is to figure out the combo rather than use any of the cruder methods you listed. Paul
-----------[000049][next][prev][last][first]---------------------------------------------------- From: joe jesson <jej@chinet.chi.il.us> 29-AUG-1990 6:54:50 To: misc-security@uunet.uu.net
I need to connect a large network to annother very large network through RSCS-to-RSCS and would like (no must) look at the exposure (read potential hackers sending worms, virus, etc.) of our network and business files (CMS). The infamous "Christmas Card" fiasco on the IBM network make me nervous. The overall intent of hooking-up the networks is to send mail (Interenterprise electronic mail project). Any ideas on how the system may be compromised? Risk Level???? -joe
-----------[000050][next][prev][last][first]---------------------------------------------------- From: bgsuvax!denbeste@cis.ohio_state.edu (William C. DenBesten) 29-AUG-1990 7:17:50 To: osu-cis!misc-security@cis.ohio-state.edu
There exists a book that lists all of the combinations by serial number. Many locksmiths have this book. If you can demonstrate that you own the lock, they may look it up for you. I find it scary that the relationship exists. Personally, I prefer to use key locks with the serial/key number written in ink (I erase the number) or to use locks for which I set the combination. At least someone can't look up the number in a handy book. -- William C. DenBesten is denbeste@bgsu.edu or denbesten@bgsuopie.bitnet
-----------[000051][next][prev][last][first]---------------------------------------------------- From: Homer <CTM@cornellc.bitnet> 29-AUG-1990 7:41:24 To: "Security List." <security@pyrite.rutgers.edu>
When I was a kid, a fellow camper showed me how to crack the
standard everywhere present master combo lock.
Basically the idea was to find the first number by pulling
the shank out and turning the knob. It would click or stick or
feel different at the place that corresponded to the first
number.
The third number was easy to find, assuming you had the first and
second number, all you had to do was turn the dial until the shank pulled
open.
Finding the second number was a matter of trying each one, not
that many. It made it even easier in that the second number was
'accurate' only to 2 digits, so you only had to try every other
position to get the right one.
I opened many a master lock this way.
-----------[000052][next][prev][last][first]---------------------------------------------------- From: "William F. Wurzbach" <WURZBACH@oshkosh.wisc.edu> 29-AUG-1990 14:46:35 To: security@pyrite.rutgers.edu
I had the same problem about a year ago and the solution was painless.
Go to the nearest hardware store that handles MasterLock locks. Explain to
someone there ( I approached the key-making department ) what the problem is,
get the address of the nearest MasterLock outlet or corporate headquarters,
and write a letter to them, explaining who you are, what the serial number of
the combination lock is, and giving the full address of the hardware store
you have made accommodations with. MasterLock will send the combination to
the hardware store ( authorized dealer ), where you can have them call you
or stop in periodically to check if it's arrived. No problem if you've got
the time.
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |