Crack, Cops, and The Intregity of My System
Edward C. Otto III
from my first hack job (~4 weeks ago), I have several questions for the
net as a whole, and for the writers of password crackers in particular:
Sirs:
What is the extent of your liability if one of your programs is
used to destroy my system? Do you wave your hands and cry "Not it's
intended use; not it's intended audience..."?
I think not. Reasonable methods could have been taken to insure
that utilities like this do NOT get out to those not in a position of
authority over the hardware it's to be run on.
Shareware and releasing something into the public domain is
fine. HOWEVER, in the case of Crack, COPS, et. al., you could have at
least ATTEMPTED to see to it that the hackers on the net have a hard
time getting to it.
Now that you have let the djinni out of the bottle, so to speak,
now come up with some ways that I can protect my system from the
unauthorized usage of this program. My system runs 24 hours/day, and I
close holes as soon as I can find them - but this one is over my head!
Help!
--
Email flames to: edo...@uipsuxb.ps.uiuc.edu or call 217/333-9422 to talk
Ed Otto : University of Illinois : Printing Services Office
54A E. Gregory Drive : Champaign, IL : 61820
/std/disclaimer | more >/dev/null
n liu
>Being a new (~1 yr.) system manager on an Ultrix system, and recovering
>from my first hack job (~4 weeks ago), I have several questions for the
>net as a whole, and for the writers of password crackers in particular:
>Sirs:
>[snip]
> Shareware and releasing something into the public domain is
>fine. HOWEVER, in the case of Crack, COPS, et. al., you could have at
>least ATTEMPTED to see to it that the hackers on the net have a hard
>time getting to it.
This has already been beaten to death. Here's a recap:
If you look carefully at the code, you might notice that any "hacker"
with a moderate amount uf UNIX experience could write the code in
a couple of hours. In addition, fcrypt() and crypt() and various
other similar library routines are publicly available for a wide
variety of platforms. In short, this program is for "less experienced"
sysadmins or sysadmins who don't have a lot of time on their hands
to write such code. The intention is to make it easier for YOU, as
sysadmin, to find weaknesses in your own system's integrity. Clearly,
if your system falls to an attack similar to the one taken by CRACK,
it could have easily been avoided had you run CRACK on your system
to make sure those weaknesses were not present.
In addition, there is no distinguishing the "user" from the "sysadmin."
Users are sysadmins elsewhere. Sysadmins are users elsewhere.
Giving a Sysadmin CRACK to run on his own system does not prevent him
from maliciously running it elsewhere. Preventing a user from
having CRACK prevents him from checking out his own system and verifying
its security.
Now for a few additional comments and observations.
Traditionally, there has always been a tradeoff between convenience and
security. There is no way around it. Anyone who has worked for the
Goverment/DoD, or any other business where information is deemed valuable
and/or dangerous can tell you a high level of security is a MAJOR pain
in the ass. Getting things done is well nigh impossible considering the
huge amount of red tape involved in getting clearance, declassifying
materials, etc. However, it is generally seen as a necessary "evil"
and people learn to make do. Most of the systems involved in this work
will NEVER be connected to Internet. Internet was designed as a
convenient way of moving large amounts of data back and forth. It is
automatically assumed that merely being connected to Internet is a
security risk; not necessarily because Internet is inherently insecure,
but rather because of the sheer number of users who have "equal" access.
So conseqently, there are more "dark hats,~ commie spies, etc. that
have the ability to stage an attack.
Other comments, flames, etc. welcome.
Rich Kaul
Being a new (~1 yr.) system manager on an Ultrix system, and recovering
from my first hack job (~4 weeks ago),
The joys of inexperience! How nice to not have had that happen
before. Just wait, it will happen again.
What is the extent of your liability if one of your programs is
used to destroy my system?
[...]
I think not. Reasonable methods could have been taken to insure
that utilities like this do NOT get out to those not in a position of
authority over the hardware it's to be run on.
First, how do you make sure that those "in a position of authority"
can get it and users can't? Most attempts at that kind of restriction
fail even when legal penalties are in effect, or perhaps you've never
heard of software piracy? Secondly, there's absolutely no way to
determine if someone is in such a "position of authority" remotely.
There's no way you could convince me that you were the system manager
of your system.
Shareware and releasing something into the public domain is
fine. HOWEVER, in the case of Crack, COPS, et. al., you could have at
least ATTEMPTED to see to it that the hackers on the net have a hard
time getting to it.
Most of the hackers I know have far superior tools to those you have
mentioned. These tools are nice and they're designed to be
prepackaged toolsets for administrators, since most administrators
have other things to do than try and crack into their system.
However, these tools are only a beginning. If you take a look at the
code, the programs are quite short and easy to write. Consider what a
more determined cracker could do with a network of Sparc 2s, plenty of
time, a highly tuned crypt(3) and the serious desire to crack the
system. An exhaustive search is possible, although computationally
expensive.
Now that you have let the djinni out of the bottle, so to speak,
now come up with some ways that I can protect my system from the
unauthorized usage of this program. My system runs 24 hours/day, and I
close holes as soon as I can find them - but this one is over my head!
They haven't let the djinni out of the bottle. They've merely opened
your eyes to what someone with even a moderate interest in cracking
would write as a start.
As to how to protect your system, there are several minimal steps that
are easily taken. The best thing you should do is install a smarter
version of passwd(1) to prevent your users from picking stupid
passwords. There's a perl version sitting on ftp.uu.net that's a good
start. If you don't want to do that, you could try running a cracker
on your password database. Run it once, then daily check the just the
passwords that change. With a faster crypt(3) that should be doable
for most systems. Of course, shadow password files would certainly be
a nice addition to these suggestions, but not all systems support
those.
--
Rich Kaul | "Giving power and money to government is like
ka...@ee.eng.ohio-state.edu | giving whiskey and car keys to teen age boys."
Christopher Davis
Ed> == Edward C. Otto III <edo...@uipsuxb.ps.uiuc.edu>
Ed> [...] Reasonable methods could have been taken to insure that
Ed> utilities like this do NOT get out to those not in a position of
Ed> authority over the hardware it's to be run on.
Like what? Burning all copies of K&R2 and the Camel Book? Hunting down
and killing every person who knows how to write a simple program in C or
perl, who doesn't at that moment manage or own a machine?
Ed> Shareware and releasing something into the public domain is
Ed> fine. HOWEVER, in the case of Crack, COPS, et. al., you could have
Ed> at least ATTEMPTED to see to it that the hackers on the net have a
Ed> hard time getting to it.
The *crackers* (thankyewverymuch) already HAVE them, or something like
them. That's the *point*. If they didn't have them, they could write
them in very little time.
Ed> Now that you have let the djinni out of the bottle, so to speak,
Ed> now come up with some ways that I can protect my system from the
Ed> unauthorized usage of this program. My system runs 24 hours/day, and I
Ed> close holes as soon as I can find them - but this one is over my head!
The djinni's been out of the bottle for YEARS. Dan and Alec didn't let
him out.
Here are some ideas:
- Look into shadow passwords. Your vendor may allow some way to do it.
If not, John Haugh's written a complete suite of programs for it. This
will help, but require the following two items to be really secure.
- Run this yourself, and make people choose good passwords. This works
best when combined with the following item.
- A FASCIST PASSWD PROGRAM. Get a BIIIIG dictionary. Get a passwd
program that forces people to choose things *not* in said dictionary.
Add words to taste (SF authors and first names especially :-).
--C
--
Christopher Davis <c...@eff.org> | ELECTRONIC MAIL WORDS OF WISDOM #5:
System Manager & Postmaster | "Internet mail headers are
Electronic Frontier Foundation | not unlike giblets."
+1 617 864 0665 NIC: [CKD1] | -- Brian Reid <re...@decwrl.dec.com>
Mike Tighe
> Shareware and releasing something into the public domain is fine. HOWEVER,
> in the case of Crack, COPS, et. al., you could have at least ATTEMPTED to
> see to it that the hackers on the net have a hard time getting to it.
Of course. What we need is a 5 day Waiting Period for the purchase of
computer software. This way the Software Police could have time to check
out the buyers background, and ascertain that they are not criminals.
Perhaps you can get some 'useful idiot' whose system was attacked by a
'hacker' (whatever that is) to testfiy before Congress about how necessary
this legislation is.
> Now that you have let the djinni out of the bottle, so to speak, now come
> up with some ways that I can protect my system from the unauthorized usage
> of this program. My system runs 24 hours/day, and I close holes as soon as
> I can find them - but this one is over my head!
Here is a silly idea. Why don't you try running those programs and
plugging all the holes in your system that it finds?
--
+--------------------------------------------+
|Mike Tighe, ti...@convex.com, (214) 497-4206|
+--------------------------------------------+
Brian Fitzgerald
The whole world is not going to try to break in to your system today.
Meanwhile, run crack on your own passwd file, and if you get a hit, ask
the person to change the password.
Also, get what security patches you can from your vendor, follow
alt.security and comp.security.announce, look over back issues of the
CERT bulletins and "Improving the Security of Your Unix System"
(security.doc.tar.Z from uxc.cso.uiuc.edu and many other places), and
try to do what your OS manual says about security.
A bit time consuming, if you try "do security" all at once starting
right now, but it won't take forever, either.
When someone posts something a bit too exploitative for your tastes,
well, roll with the punches for a while. Rumor has it that password
crackers have been available on bulletin boards for some time now.
In the end, the internet will be a better place if a few more sysadmins
enforce better passwords. The fix is probably not really "over your
head" after all.
One more thing. Smile :-)
Brian
J. Adams - SunOS Wizard
>[...]
>code, the programs are quite short and easy to write. Consider what a
>more determined cracker could do with a network of Sparc 2s, plenty of
>time, a highly tuned crypt(3) and the serious desire to crack the
>system. An exhaustive search is possible, although computationally
>expensive.
Nope, not for any network of workstations. Dubiously possible for the
NSA with their hundreds of Crays, Butterflies, etc. (Faster if they
built a heuristic into the DES algorithm.) If you look at the numbers,
an exhaustive search on a dedicated net of SPARC 2's would still
require a significant number of years. Powers of two are easy to
express... they're harder to deal with if you have to take one at a
time.
--
Jim Adams Department of Physiology and Biophysics
ad...@ucunix.san.uc.edu University of Cincinnati College of Medicine
"I like the symbol visually, plus it will confuse people."
... Jim Morrison
Neil Rickert
>from my first hack job (~4 weeks ago), I have several questions for the
>net as a whole, and for the writers of password crackers in particular:
Start by complaining to your vendor for supplying an insecure system.
Not that it will do much good. But if enough people complain often
enough, ...
> What is the extent of your liability if one of your programs is
>used to destroy my system? Do you wave your hands and cry "Not it's
>intended use; not it's intended audience..."?
If a hacker breaks into your system and does 'rm -rf /' I suppose you
are going to sue your vendor for providing the 'rm' program! And, if
truth be known, there has probably been far more damage done by 'rm'
and equivalent deletion commands, executed by 'trusted' people, than
has ever been done by hackers. That's why people keep looking for
'undelete' programs.
> I think not. Reasonable methods could have been taken to insure
>that utilities like this do NOT get out to those not in a position of
>authority over the hardware it's to be run on.
Sure. Go bury your head in sand. Spend your time searching for 'crack'
and similar software, bearing in mind that someone may have given it a
different name. The 'hackers' will applaud. They will consider it a
challenge to break into your system. And they will know it is easy, for
you have been wasting your time on wild goose chases when you could have
been doing something positive to tighten security.
> Shareware and releasing something into the public domain is
>fine. HOWEVER, in the case of Crack, COPS, et. al., you could have at
>least ATTEMPTED to see to it that the hackers on the net have a hard
>time getting to it.
How. There was enough information in the newspaper articles about the
Internet worm that any halfway competent hacker could pick up the hint
and write his own. You will have to throw the whole world into your
thought reform program to erase these ideas from their minds.
> Now that you have let the djinni out of the bottle, so to speak,
>now come up with some ways that I can protect my system from the
>unauthorized usage of this program. My system runs 24 hours/day, and I
>close holes as soon as I can find them - but this one is over my head!
>
> Help!
What is that old saying - "fool my once, shame on you; fool me twice, shame
on me." The "once" was the Internet worm. If it happened to you since then,
it's your failure.
--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Neil W. Rickert, Computer Science <ric...@cs.niu.edu>
Northern Illinois Univ.
DeKalb, IL 60115 +1-815-753-6940
Ed Mooring
>In article <KAUL.91Au...@icarus.ee.eng.ohio-state.edu> ka...@ee.eng.ohio-state.edu (Rich Kaul) writes:
>>[...]
>>system. An exhaustive search is possible, although computationally
>>expensive.
>
>Nope, not for any network of workstations. Dubiously possible for the
>NSA with their hundreds of Crays, Butterflies, etc. (Faster if they
>built a heuristic into the DES algorithm.) If you look at the numbers,
>an exhaustive search on a dedicated net of SPARC 2's would still
>require a significant number of years. Powers of two are easy to
>express... they're harder to deal with if you have to take one at a
>time.
Hmm, exhaustive search.. I get 560 encryptions/second on a Sparc II, with an
implementation of fcrypt() I got off sci.crypt recently. Let's call that
2^9. One calendar year is ~ 2^25 seconds. That's 2^34 encryptions per
machine/year. So, if you had 2^22 Sparc II's (4 million), you could do
an exhaustive search in one year. Not likely.
Faster machines aren't enough faster to make a significant difference for
an exhaustive search. Using 1/2 million machines for a year would still
be sort of obvious.
On the other hand that 2^34 for one machine/year could get a significant
chunk of the likely passwords using some sensible heuristics. Another
good argument for shadow password files.
Regards,
Ed Mooring (moo...@tymix.tymnet.com 408-922-7504)
Geoff Loker
> - A FASCIST PASSWD PROGRAM. Get a BIIIIG dictionary. Get a passwd
>program that forces people to choose things *not* in said dictionary.
>Add words to taste (SF authors and first names especially :-).
As a side note, if you have Perl and the Camel Book, there is such a
passwd replacement program in there. It handles shadow password files,
multiple dictionaries (if you have them), sysadmin-definable bad patterns,
etc. Works real nice, too. Before installing it, cops managed to crack
quite a number of passwords here -- now, cops hasn't had much luck there.
It even has hooks for you to set up password expiry.
--
-----
Geoff Loker, SysAdmin USENET: ge...@mdms.moore.com
Moore Data Mgnt Services,
801 Milner Ave, Scarborough, Ontario, CANADA M1B 3C3
"Don't let's go to the dogs tonight / For mother will be there."
- A.P.Herbert
Cliff Stoll
>Relax.
>The whole world is not going to try to break in to your system today.
> Rumor has it that password
>crackers have been available on bulletin boards for some time now.
Hey - I agree with Brian.
I seem to remember someone cracking passwords in 1986. Why all the fuss now?
-Cliff Stoll
Roving Bithead
>In article <edotto.6...@uipsuxb.ps.uiuc.edu> edo...@uipsuxb.ps.uiuc.edu (Edward C. Otto III) writes:
>>Being a new (~1 yr.) system manager on an Ultrix system, and recovering
>>from my first hack job (~4 weeks ago), I have several questions for the
>>net as a whole, and for the writers of password crackers in particular:
>
> Start by complaining to your vendor for supplying an insecure system.
>Not that it will do much good. But if enough people complain often
>enough, ...
>
Excellent!
Although I am not sure you were being flip, that is one thing that has to be
done. Our vendors priorities are survival and they are waging wars on the
consortium and MIPS fronts. Unfortunately, they are not delivering strong
enough products (or default configuration) to meet the needs of the current
environment.
The networked computer environment is growing at a phenomenal rate. There
is no better problem than success. And we are all feeling it.
However, please do not downplay the problems of the novice site. Keeping
track of the latest patches on the net is difficult - and difficult to
explain to management not used to relying on other sources than the vendor.
Managment generally does not understand the gravity of the situation, nor
the costs associated with maintaining a clean site.
Although we fight the fight of reality, it is a shame that we must accept
the sysadmin help to the degree that we do. And I argue, as long as we
tollerate the situation, the vendor will not address it. After all, many
of us pay hefty support fees.
I am willing to be that the number of novice sites greatly outnumber the
number of experienced sites judging by the growth in the industry.
We have to make the vendor more responsible for education, configuration
sound products, and timely patches/workarounds. From the user, out of
self defense. For the vendor, who may loose the success that they enjoy
now.
Please don't flame. This is merely a plea, not a brilliant opinion or
even a slightly warm one...
Sincerely,
Gordon Spoelhof,
Computer Technology Consultant
Eastman Kodak Co. - Information Technology Management
Disclaimer: "Neither my wife nor my employer endorse opinion according
to Gordi..."
Internet: spoe...@Kodak.COM
Telephone: 716-781-5576
Secretary: 716-724-1365 (Sharon Hancock)
FAX: 716-781-5799
US Mail: Gordon Spoelhof
CIS/ITM 2-9-KO
Eastman Kodak Co
343 State Street
Rochester, NY 14650-0724
Neil Rickert
>In article <1991Aug13.1...@mp.cs.niu.edu> ric...@mp.cs.niu.edu (Neil Rickert) writes:
>>
>> Start by complaining to your vendor for supplying an insecure system.
>>Not that it will do much good. But if enough people complain often
>>enough, ...
>
>Excellent!
>
>Although I am not sure you were being flip, that is one thing that has to be
>done. Our vendors priorities are survival and they are waging wars on the
I was not being 'flip'. I do not have sources here. That means every
time my vendor supplies a new version I have to spend some time finding out
all the stupid security holes left behind. Then I have to go and reinstall
all the security enhancements (such as shadow password files). It is a
royal pain.
Personally I think vendors should distribute systems as security tight as
possible, and include documentation - perhaps even a shell script - to
loosen things up a little for convenience at the choice of the system
administrators. But at present they tend to set things up for maximum
convenience, and don't even warn you about all the security holes they leave.
>However, please do not downplay the problems of the novice site. Keeping
I don't. But this whole discussion started out with a complaint about the
use of Crack. The complainer was at an academic site.
At an academic site, the only reasonable approach is to assume each user
is responsible for the security of his own password. The administrator
must be sure outside users cannot break into administrative accounts. After
that, he must make sure that anyone using a regular account cannot compromise
more than the files owned by that account. In a university, students tell
each other their passwords. They shouldn't, but you can't police that. So
if you are worried about someone getting on who doesn't have an account, Crack
is the least of your concerns. Just assume it is bound to happen, and make sure
that the intruder can do no damage other than to the user who was careless about
his password.
Any concern about Crack is trivial in comparison to vendors with a default
setup which, if connected to Internet, would allow someone from outside who
knew what he was doing to become root within 5 or 10 minutes. (Yes, I am
talking about that '+' in /etc/hosts.equiv on Suns). It is totally
inexcusable for vendors to sell systems with such gaping holes.
Mark Garrett
> Being a new (~1 yr.) system manager on an Ultrix system, and recovering
> from my first hack job (~4 weeks ago), I have several questions for the
> net as a whole, and for the writers of password crackers in particular:
>
> now come up with some ways that I can protect my system from the
> unauthorized usage of this program. My system runs 24 hours/day, and I
> close holes as soon as I can find them - but this one is over my head!
>
> Help!
Since your running ultrix upgrade to a version >= 4.0, thats
if you aren't already, then install the upgraded security, and turn it on.
Once you've done this your passwd file will no longer be reachable
as /etc/passwd only contains user:*:UID:GID..... with the passwds
hidden in /etc/auth* not only are they readable only to root and the
group authread, it is also nolonger in a format that crypt of fcrypt will
work with. I image the mods to fcrypt to make it work as per Ultrix
crypt16 are small, but only you should be able to access the passwds anyway.
Does this help you.
Besides the best security doesn't revolve around secrecy of your algorithm,
train your users (ie install npasswd).
--
Mark Garrett Internet: ma...@loki.une.edu.au Phone: +61 (066) 20 3859
University of NewEngland, Northern Rivers, Lismore NSW Australia.
Harald Nordgard-Hansen . Kjemiteknikk
(...)
|>
|> Since your running ultrix upgrade to a version >= 4.0, thats
|> if you aren't already, then install the upgraded security, and turn it on.
|> Once you've done this your passwd file will no longer be reachable
|> as /etc/passwd only contains user:*:UID:GID..... with the passwds
|> hidden in /etc/auth* not only are they readable only to root and the
|> group authread, it is also nolonger in a format that crypt of fcrypt will
|> work with. I image the mods to fcrypt to make it work as per Ultrix
|> crypt16 are small, but only you should be able to access the passwds anyway.
|>
|> Does this help you.
|> Besides the best security doesn't revolve around secrecy of your algorithm,
|> train your users (ie install npasswd).
|>
|>
|> --
|> Mark Garrett Internet: ma...@loki.une.edu.au Phone: +61 (066) 20 3859
|> University of NewEngland, Northern Rivers, Lismore NSW Australia.
I just cant resist this one... If you are running Ultrix, any version, it
would take anyone who knew about the problems in the area of minutes to
break into your machine if they have access to any machine connected to
your machine. (On the internet, that means the whole world..) I know DEC is
working on many of these problems (no I'm not going to publish them, as some
of the holes cannot be plugged without removing significant functionality).
We can only hope that most will be plugged in the future.
The best way to keep your system secure, is to look out for abnormal
behaviour from any programs, monitor the logs, keep up to date on the net,
and generally make sure that you know what is going on on your machine.
Then you can add in the different security options and replacement programs
as you find out what they do to the security and ease of use on your system.
DISCLAIMER: I do not say that any other Unix flavours or other operating
systems is any more secure, it's only that I have spent most time with Ultrix.
I could equally well break into SunOS, but that was not the issue here.
The point I wish to make is just this: Do never fool yourself into thinking
that your system is secure. After all, who needs passwords to become root on
a unix box? But on a well-run system, it usually will be noticed. It's not
perfect, but it's better than being ignorant of any security breaches.
-Harald
--
Harald Nordg{\aa}rd-Hansen, ! If there is any- !Addr: Inst. for Kjemiteknikk,
Laboratory of Chem. Eng., ! thing good that ! N-7034 Trondheim-NTH,
The Univ. of Trondheim,NTH ! happens in life; ! NORWAY. Phone +47 7 59 4691
Email: hha...@kjemi.unit.no ! It's from Jesus. (Amy Grant: Hope Set High)
Mark Zenier
> Hmm, exhaustive search.. I get 560 encryptions/second on a Sparc II, with an
> implementation of fcrypt() I got off sci.crypt recently. Let's call that
> 2^9. One calendar year is ~ 2^25 seconds. That's 2^34 encryptions per
> machine/year. So, if you had 2^22 Sparc II's (4 million), you could do
> an exhaustive search in one year. Not likely.
But anybody who knows what end of a soldering iron to pick up should
be able to build a DES add-on unit that could hit 2^14 to 2^18 trials a
second, and 2^26 could be achievable in somebody's basement.
Remember that the DES was designed for ease of implementation in
HARDWARE.
Mark Zenier ma...@ssc.wa.com mzenier%pol...@sumax.seattleu.edu
J. Adams - SunOS Wizard
More appropriate would be an ASIC programmer. You'ld be looking at
some pretty massive parallelism and some mighty fast clock rates to get
2^14 encryptions/sec, though. Note, too, we're talking salted DES
here, so you can't just buy a bagfull of commercial DES chips (not that
you'd want to considering the cost/speed).
Plus, the means to store such a search as a dictionary aren't readily
available. This means you'd most likely have to re-run the search each
time.
A lot has been posted about dictionary-based searches. This is entirely
valid. An _EXHAUSTIVE_ search is something else altogether.
Possibly in somebody's basement at Ft. Meade. Not in mine, though...
Bill Stewart 908-949-0705 erebus.att.com!wcs
]> Shareware and releasing something into the public domain is fine. HOWEVER,
]> in the case of Crack, COPS, et. al., you could have at least ATTEMPTED to
]> see to it that the hackers on the net have a hard time getting to it.
security weaknesses on your system. If you had run it 6 months ago,
you probably wouldn't have been cracked on, or if you had been,
it would have been with tools that COPS doesn't provide.
Because COPS et al are published, your self-protection tools
can be as good as the tools the bad guys are attacking you with.
Otherwise, if COPS is outlawed, only outlaws will have COPS :-)
]> Now that you have let the djinni out of the bottle, so to speak,
Hey, they're handing you a djiini on a leash - all you've
got to do is hang on.
In article <1991Aug13.1...@convex.com> ti...@convex.com (Mike Tighe) writes:
]Of course. What we need is a 5 day Waiting Period for the purchase of
]computer software. This way the Software Police could have time to check
But ftp was too slow *already* :-)
--
Pray for peace; Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# Wasserman can't *possibly* make all those sounds on a string bass.
# It's total disrespect for the instrument. And it was *wonderful*!
Thomas Truscott
> nolonger in a format that crypt of fcrypt will work with.
>Besides the best security doesn't revolve around secrecy of your algorithm,
>train your users (ie install npasswd).
Speaking of which, DEC's crypt16 algorithm is not documented anywhere
I can find. Is this an oversight?
A curious feature of crypt16 is that it is trivial to determine
from the encryption whether the password is <= 8 chars long, or > 8.
Can someone please describe the crypt16 encryption format?
Similarly, can someone describe the SCO encryption format?
Tom Truscott