vendors and password security
Tom Christiansen
who ship a shadow-passwd system by default (as opposed
to an add-on). Also, does anyone ship Kerberos?
--tom
Jerry M. Carlin
"By default"; Well, you can turn shadow passwords on in AT&T V.3.2 and
later UNIX'es and SUN on 4.1 but they are not turned on as shipped but
the software is available out of the box so I guess they're between
'default' and 'add-on'.
IBM ships Kerberos with their VM/CMS TCP/IP product :-) :-) :-)
I've heard SUN will have it in Solaris 2.0 and its in OSF's DCE but
I don't know of any UNIXes that have it out-of-the-box yet.
--
Jerry M. Carlin (510) 823-2441 jmc...@srv.pacbell.com
To dream the impossible dream. To fight the unbeatable foe.
Dave Quinn
security package installed. this includes the shadowed
password suite. however, they (ibm) neglected to take care
of some other points in their shipped software. i believe
some of the PC based *nix ship with shadowing as well,
i am thinking specifically of SCO's SysV386.
-david
/* this post was constructed virtually all within my self-being */
Al Clark
IBM AIX 2.2 and up ships with shadowed password file.
--
Al - acl...@netcom.com - My opinions are my own.
*** Commit acts of random kindness and senseless beauty! ***
Michael Ewan
DEC Ultrix ships with Kerberos and Hesiod. Shadow passwords is a
feature the administrator may enable.
Mike
--
Michael Ewan (503)627-6468 Internet: mik...@tekgen.BV.TEK.COM
Unix Systems Support UUCP: ...!uunet!tekgen.bv.tek.com!mikeew
Tektronix, Inc. Compuserve: 73747,2304
"Fig Newton: The force required to accelerate a fig 39.37 inches/sec^2"-J. Hart
Per Andersson
But rumour says you can't compile your own kerberized programs at all, because
of export restrictions, and Dec didn't want to have two versions of Ultrix.
This may have changed since I last checked of course.....
/Per
--
Per Andersson (per...@admin.kth.se, per...@stacken.kth.se)
Now working at NobelTech AB, still reading news at the
Royal Institute of Technology.
peter da silva
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
Tony Vecchi
Actually SCO ODT has that out of the box when you choose to install
the C2 security option. I just finished upgrading to 1.1.1f from 1.0
and the system is pretty stable even with the extra security installed,
touchy..but stable :-)
Tony
Gene Rackow
>Intel V.3.2 has shadow passwords turned on "out of the box".
>--
many other holes to even count. COPS had a field day on the box when we got it.
-_gene
Gene Rackow email: rac...@mcs.anl.gov
Math & Computer Science voice: 708-252-7126
Argonne National Lab FAX: 708-252-5986
9700 S. Cass Ave. / Argonne, IL 60439
Jeff Leyser
!!I was wondering whether there are any vendors out there
!!who ship a shadow-passwd system by default (as opposed
!!to an add-on).
Motorola's Unix for their RISC line of mini's (Sys V/88) has shadows active
by default.
--
Jeff Leyser je...@ncoast.org
Opinions? I thought this was typing practice! ley...@tsa.attmail.com
Charles Hannum
AIX 3 (RS/6000) uses shadow passwords by default. Indeed, trying to
circumvent the mechanism causes problems.
BTW, I once had a discussion with Hal Abelson that went something like
this:
Q: What about shadow passwords?
A: No, then they'll just use one of the other dozen ways to break in.
Furthermore, they'll crack root, steal your shadow password file, and
you've gained nothing.
Win Treese
> Yes, DEC ships kerberos client (and server) with Ultrix, I think 4.0 and newer.
> But rumour says you can't compile your own kerberized programs at all, because
> of export restrictions, and Dec didn't want to have two versions of Ultrix.
> This may have changed since I last checked of course.....
Since Digital started shipping Kerberos with ULTRIX, it has been
possible to write your own applications. What you can't do is use the
session key to encrypt user data. That restriction, of course, comes
from export restrictions.
Win Treese Cambridge Research Lab
tre...@crl.dec.com Digital Equipment Corp.
Jerry M. Carlin
>BTW, I once had a discussion with Hal Abelson that went something like
>this:
> Q: What about shadow passwords?
> A: No, then they'll just use one of the other dozen ways to break in.
>Furthermore, they'll crack root, steal your shadow password file, and
>you've gained nothing.
FLAME ON
The problem is tough so why bother tackling it. Let's just give up. In
fact, we should not tackle any tough problems like polution, war, disease
etc. After all, if we cure one disease, we'll just get another so lets
give up on vaccination, surgery and other forms of medicine. It's all
futile in the long run.
Using the medical analogy shows how utterly stupid the argument is.
FLAME OFF
Greg Lindahl
>In article <1992Feb23.2...@mintaka.lcs.mit.edu> myc...@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>> Q: What about shadow passwords?
>> A: No, then they'll just use one of the other dozen ways to break in.
>>Furthermore, they'll crack root, steal your shadow password file, and
>>you've gained nothing.
>
>FLAME ON
Why are you flaming him for pointing out something obvious? Security
through obscurity is *not* a fix; if you want to maybe possibly
protect your passwords, you must not only use shadow passwords but
also educate your users about picking good passwords, and test the
passwords that they pick. You must also worry about non-password
security holes. Flaming people here won't increase your security.
--
Signature virii are lame.
Al Clark
I suspect he knows that; he was just venting (I think that is what
FLAME ON means). Your point is well taken, at the risk of creating
a timeless saying, "A chain is as weak as its weakest link". And
lack of a shadowed password file is a major weak link. He is,
(or maybe its my own feelings leaking through), railing at people
who try to justify not fixing a link by saying, in effect,
"Why fix this link, somebody will just find another weak one".
Actually, I just realized, maybe you are both saying the same thing,
but you object to his emotional outburst. Oh well, ...
Alan J Rosenthal
>>who ship a shadow-passwd system by default (as opposed
>>to an add-on).
>
But, it also ships with nis, and if you run ypserv, it adds the passwords back
into what you get with ypcat passwd. At least the version we have (running on
an ibm rt) does.
Bennet Yee
>In article <1992Feb24....@murdoch.acc.Virginia.EDU> gl...@fermi.clas.Virginia.EDU (Greg Lindahl) writes:
>>In article <1992Feb24.1...@PacBell.COM> jmc...@PacBell.COM (Jerry M. Carlin) writes:
>>>In article <1992Feb23.2...@mintaka.lcs.mit.edu> myc...@hal.gnu.ai.mit.edu (Charles Hannum) writes:
>>
>>>> Q: What about shadow passwords?
>>>> A: No, then they'll just use one of the other dozen ways to break in.
>>>>Furthermore, they'll crack root, steal your shadow password file, and
>>>>you've gained nothing.
>>>
>>>FLAME ON
>>
>>Why are you flaming him for pointing out something obvious? Security
>>through obscurity is *not* a fix; if you want to maybe possibly
>>protect your passwords, you must not only use shadow passwords but
>>also educate your users about picking good passwords, and test the
>>passwords that they pick. You must also worry about non-password
>>security holes. Flaming people here won't increase your security.
>>
>
>I suspect he knows that; he was just venting (I think that is what
>FLAME ON means). Your point is well taken, at the risk of creating
>a timeless saying, "A chain is as weak as its weakest link". And
Using normal, non-shadowed password files is NOT security through
obscurity. STO is having a command called ``root'' in your /etc that
is not in your man pages. STO is having a backdoor in your system
like the sendmail DEBUG mode (except it's not just for DEBUG any more)
that anybody can use, with the only ``access control'' being not
telling people about the existence of the back door.
The standard password mechanism is a cryptographic mechanism for
security. The only problem is that its assumption that people chose
passwords from the entire key space is false -- people are lazy and
chose dictionary words which limits the search space for exhaustive
attacks dramatically. If everybody *did* use random strings as
passwords, there wouldn't be a problem. Unfortunately, educating
users to make them understand this and follow the appropriate
procedures is very difficult if not impossible, so it becomes a weak
link in our security systems. The point, however, is that it is by no
means *inherently* weak.
The beauty in the encryption approach to Unix passwords is that it
makes the system assumptions very obvious.
Many older systems didn't depend on encryption, but just normal access
control mechanisms to prevent illegal access to a plaintext password
file. To prove that this is secure, you must prove as a lemma that
the file access control mechanism is correct, quite a daunting -- and
tedious -- task.
With the Unix style approach, it is obvious that breaking the password
system in general (assuming users chose passwords uniformly from the
entire key space) is equivalent to breaking the (perturbed) DES system
under a known plaintext attack. Clear and simple. Plus, if the
cryptosystem _is_ determined to be weak, how to upgrade the system
with any better cryptosystem that cryptologists develop is obvious.
[This actually happened with the cryptosystem used prior to the
perturbed DES system -- perturbed DES is the replacement. See
_Password Security: A Case History_ by Robert Morris (Sr) and Ken
Thompson.]
If you think that shadow password files is a must, then you'll have
even greater problems with many standard cryptographic assumptions.
After all, all public key schemes publish enough information so that
information-theoretically, at least, the private key can be computed.
Ho hum.
Shadow password files do help enhance security in practice in
present-day systems. Don't mistake them, however, for a necessary
component in *all* security systems.
-bsy
--
Bennet S. Yee Phone: +1 412 268-7571 Email: bs...@cs.cmu.edu
School of Computer Science, Carnegie Mellon, Pittsburgh, PA 15213-3890
Greg Lindahl
>Using normal, non-shadowed password files is NOT security through
>obscurity.
It is if you haven't educated your users about how to pick a good
password. Shadow password files are also security through obscurity,
because they convince some admins that it's not necessary to encourage
users to have a good password. Someone steals your backup tape, or
uses some hole to read that part of the disk, and your passwords can
be decrypted if they're weak.
>The only problem is that its assumption that people chose
>passwords from the entire key space is false -- people are lazy and
>chose dictionary words which limits the search space for exhaustive
>attacks dramatically. If everybody *did* use random strings as
>passwords, there wouldn't be a problem.
Indeed; educating users about this is what I'm advocating. I am not
saying that shadow passwords are a bad thing; just that they are not
the whole solution.
Bill Vermillion
Esix ships shadowed passwd out of the box.
--
Bill Vermillion - bi...@bilver.uucp - ..!{ge-dab|tous|tarpit}!bilver!bill
peter da silva
> In article <id.GP...@ferranti.com> pe...@ferranti.com (peter da silva) writes:
> >Intel V.3.2 has shadow passwords turned on "out of the box".
> That may be true, but they also have a publicly writable /usr and /etc with
> too many other holes to even count.
Damn, and all this time I was blaming the installers.
Oh well, intel V.3.2 is well and truly dead by now. They handed it off to
ISC and ISC got bought by Sun.
Greg Pavlov
>
> The standard password mechanism is a cryptographic mechanism for
> security. The only problem is that its assumption that people chose
> passwords from the entire key space is false -- people are lazy and
> chose dictionary words which limits the search space for exhaustive
> attacks dramatically. If everybody *did* use random strings as
> passwords, there wouldn't be a problem.
This is heading off this particular subject, but I was wondering what people
might think of the following.
As Bennet - and everyone - knows, getting users to assign non-obvious pass-
words is difficult. Further, truly random passwords are often self-defeating
in that, if the appear difficult to remember, people will tend to write them
on a post-it scrap and stick it to the front of their monitor :-)
So: as a middle ground: how about encouraging people to at least do one or a
combination of the following:
1. use highly transliterated spellings of words;
2. imbed digits or numbers for letters or words;
3. use transliterations of other-language words;
4. combine the above into short but multi-word password strings
examples: luv2seeu!! spasiibo meetuat8? 711kofeestinks onthe.at7
- make sense ?
greg pavlov
pav...@karloff.fstrf.org
(no. 2 above courtesy of our Systems Administrator)
w...@gandalf.umcs.maine.edu
Shadow passwords by themselves don't make your system "secure".
But they sure don't hurt. Shadow passwords will make it much more
difficult for non-pro crackers to break into your system. Non-pros are
generally known as wanna-be crackers in college who JUST got crack 4.0.
They then run it, and just manage to steal 4 or 5 accounts from people
who still use their lastname as an account password. With shadow
password files, I thin there will be a lot less cracking attempts by
those who are just mildly knowledgeable.
Timothy Newsham
>In article <1992Feb25.0...@cs.cmu.edu>, bs...@CS.CMU.EDU (Bennet Yee) writes:
>>
>> The standard password mechanism is a cryptographic mechanism for
>> security. The only problem is that its assumption that people chose
>> passwords from the entire key space is false -- people are lazy and
>> chose dictionary words which limits the search space for exhaustive
>> attacks dramatically. If everybody *did* use random strings as
>> passwords, there wouldn't be a problem.
>
> This is heading off this particular subject, but I was wondering what people
> might think of the following.
>
> As Bennet - and everyone - knows, getting users to assign non-obvious pass-
> words is difficult. Further, truly random passwords are often self-defeating
> in that, if the appear difficult to remember, people will tend to write them
> on a post-it scrap and stick it to the front of their monitor :-)
>
>
I am starting to wonder about this. In some environments (maybe most)
it would probably be better to have a random password that someone has
to write down than one that is easy to guess. The reason being less
attacks are likely to be initiated in the office and more from remote
systems from people with no physical contact. In this day and age of
networking maybe a site needs more net security but doesnt necessarily
need alot of local security. Also administrators might be able to
keep people from posting the passwords out in public. Maybe if a person
has it written down in a notebook. I can see how this rule (NEVER WRITE
DOWN YOUR PASSWORD) has come into existance but should we be blindly
following it without re-evaluating the goals and environment associated
with it.
...
Greg Lindahl
> Non-pros are
>generally known as wanna-be crackers in college who JUST got crack 4.0.
>They then run it, and just manage to steal 4 or 5 accounts from people
>who still use their lastname as an account password. With shadow
>password files, I thin there will be a lot less cracking attempts by
>those who are just mildly knowledgeable.
But why do half the job, when you can also ensure that your users
don't have trivial passwords? This isn't a situation in which you can
only take *one* action; you should be aware that there are a number of
good actions you should take.
Thomas Sippel-Dau
>IBM ships Kerberos with their VM/CMS TCP/IP product :-) :-) :-)
... And I thought MVS and VM/CMS were the 1965-88 incarnations of Kerberos
--
*** This is the operative statement, all previous statements are inoperative.
* email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
* voice: +44 715 895 111 x4937 or 4934 (day), or +44 718 239 497 (fax)
* snail: Imperial College Center for Computing Services, Kensington SW7 2BX
jeffrey michael adkins
>password files, I thin there will be a lot less cracking attempts by
>those who are just mildly knowledgeable.
This can be summed up in two statements.
Locks are to keep honest people out.
The better the lock, the more honest people are.
Daniel Ortmann
[...]
) So: as a middle ground: how about encouraging people to at least do
) one or a combination of the following:
How about taking the first letters of a favorite phrase and inserting a
number and a special character? It works for me.
Of course, there is *always* the EE 101 (newbie) student who inserts the
kill character in his password. :-)
Greg Lindahl
>) So: as a middle ground: how about encouraging people to at least do
>) one or a combination of the following:
>
>How about taking the first letters of a favorite phrase and inserting a
>number and a special character? It works for me.
I always explain to people how *not* to pick a password, and let them
come up with their own scheme for making good ones. Then I
double-check by running Crack. Encouraging users to do simple things
like "insert a number in the middle of a word" might leave you with
*all* your accounts broken.
Jaehoon Lee
system (some sort of Unix and Harris' very own OS). If I recall correctly,
the passwd program on Unix part was so picky that it will say "You have to
have 2 digits in your password." or "You have to use 2 uppercase characters."
etc... It was virtually impossible to choose a new password (remembering it
was another problem.. but I did not have to deal with it...:)
Does anyone remember such machine?
I hated that machine so much I did not bother changing my initial password....
I rarely used it of course...
Jaehoon
--
Jaehoon Lee: Jeon-Im Researcher at Korea Telecom Research Center (KTRC)
Alumnus of: Seoul High(1984-36th), UNL(1989), and SUNY at Buffalo(1991)
Internet: j...@Sorak.KAIST.ac.kr (SDN account)
* Hey! My opinions have nothing to do with my company/my boss. *
Charles H. Buchholtz
>
>I always explain to people how *not* to pick a password, and let them
>come up with their own scheme for making good ones. Then I
>double-check by running Crack. Encouraging users to do simple things
>like "insert a number in the middle of a word" might leave you with
>*all* your accounts broken.
I found that people got overwhelmed when I said, "OK, now type in your
password. It should be between 6 and 8 characters, not based upon
your name, not all lower case, and not a word in the English
language." It was too many negatives to absorb at once. It's like
the old joke, "stand in the corner and *don't* think of a penguin";
they spent all their time thinking of what passwords *weren't*
allowed. I also found that people were throwing out perfectly good
nine character passwords, because they were "too long".
So I started telling them what sort of passwords *to* use, and people
seemed much happier. I hand them this handout before starting to
build the account, so that by the time I'm ready, they've read it. I
assume that it gives enough choices and room for creativity that my
system isn't vulnerable to cracking. And, we're running a version of
passwd that rejects passwords that crack could crack.
Here's the handout.
----------------------------------------------------
Choose a password that is hard to guess. "Guess", in this context,
refers to a password guessing program that can try hundreds of
passwords in a minute. Such programs usually try, in order,
variations of your name, a list of commonly chosen passwords, and
words from the English language.
Passwords should be at least six characters long; 8 is a good length.
I recommend the following methods for choosing passwords:
+ choose two short words and join them with a symbol, like
"big$deal"
+ choose a phrase, and then use the first letters; for
example, "A stitch in time saves nine": "asits9"
+ choose an address that you have never lived at, like
"219S.45th"
+ use letters, numbers, and symbols to make a phrase, such as
"2b|~2b" (To be or not to be)
Don't use any of the passwords given above.
Do not give out your password. This includes using that password for
an account outside of the University. A clever way to get passwords
is to advertise a Bulletin Board System or a network game of some
sort, ask people who join to choose a password, and then use those
passwords to try to break into their other accounts. Or someone could
ask you to use a program that they wrote, which prompts you to enter
your password. Do not use your Eniac password in these situations.
And don't set your password to anything that you don't make up
yourself. For instance, someone could fake a posting from the Systems
Administrator, saying "Everyone change your password to 'asits9'", and
then break into everyone's account.
----------------------------------------------------------------
Charles H. Buchholtz Systems Programmer ch...@seas.upenn.edu
School of Engineering and Applied Science
University of Pennsylvania
w...@gandalf.umcs.maine.edu
Yes of course trivial passwords are a big security flaw, and yes
a modified passwd should use a dictionary check before allowing a
password check, but without the ability of seeing a password file I
think offers a high degree of protection against the wannabe crackers.
One of the most important logs you can keep is of incorrect logins.
However, disabeling an account after X inccorect login attempts isn't
a good idea. Too often disgruntled crackers will purposely lock out
as many accounts as possible that way. Some probably even have a
program thats su's through the /etc/passwd list until every one is
locked out.
And yes, signature virii are lame :)
Darren Reed
>In article <1992Feb20....@news.eng.convex.com>
>tch...@convex.com (Tom Christiansen) writes:
>>
>> I was wondering whether there are any vendors out there who ship a
>> shadow-passwd system by default (as opposed to an add-on). Also,
>> does anyone ship Kerberos?
>AIX 3 (RS/6000) uses shadow passwords by default. Indeed, trying to
>circumvent the mechanism causes problems.
[...]
AIX has shadow passwords by default? Oh good! Praise IBM for bringing
back steel-doors in paper walls. They obvioulsy *are* competing with
Sun; at all levels. :-)
They're doing some things bigger and better though. Did you know that
a default AIX 3.1 installation on RS/6000s will allow almost anyone to
become root over the network in less than 30 seconds? Thousands of IBM
owners don't but thousands of crackers do...
Next time your internet host is "cracked" it may not be TERMINUS (or a
Sun with a gratuitous hosts.equiv) that the attackers use but any one
of the 1000s of RS/6000s on the internet out there.
CERT has been mysteriously silent, perhaps hamstrung by their policy
of not releasing advisories before a vendor supplied patch is
available. Well, I'll wait a week longer and will let everyone know
what the problems are. Why a week? I'd like to check my legal
situation... :-(
My concience is torn between the necessity to enable owners to secure
their machines and the danger of giving free access to even wannabe
crackers (the "good" ones must know all about this allready). (People
from IBM wishing to change my mind might want to give me a phone call
at the number in my signature.)
---------------------------------------------------------------------
Avalon .. a.k.a Darren Reed. Email: ava...@coombs.anu.edu.au
Computer Science Stud. Phone: +61-3-435-1654
"Its not a bug, its a feature!" IRC: Avalon (what else ? ;-)
--
---------------------------------------------------------------------
Avalon .. a.k.a Darren Reed. Email: ava...@coombs.anu.edu.au
Computer Science Stud. Phone: +61-3-435-1654
"Its not a bug, its a feature!" IRC: Avalon (what else ? ;-)
Greg Lindahl
> Yes of course trivial passwords are a big security flaw, and yes
>a modified passwd should use a dictionary check before allowing a
>password check, but without the ability of seeing a password file I
>think offers a high degree of protection against the wannabe crackers.
Er, a shadow password file just makes it *harder* to get the encrypted
passwords, because the rest of the system is not totally secure.
For example, a friend just mailed me info on a security flaw in the
latest release of AIX. If I were a malicious person, I could go get a
copy of the shadow password file, and then long after this particular
hole is fixed, I'll still have lots of passwords. Why is this so easy?
Because the local security people think that shadow passwords are the
ultimate, and that users don't have to pick good passwords when shadow
password files are used.
Wrong.
>One of the most important logs you can keep is of incorrect logins.
Yes. But beware recording the username used in an incorrect login --
one common typo that people make when logging in is they type their
password as their login name. If you log this somewhere, it can be a
source of passwords for cracking.
Edward DeHart
> Next time your internet host is "cracked" it may not be TERMINUS (or a
> Sun with a gratuitous hosts.equiv) that the attackers use but any one
> of the 1000s of RS/6000s on the internet out there.
> CERT has been mysteriously silent, perhaps hamstrung by their policy
> of not releasing advisories before a vendor supplied patch is
> available. Well, I'll wait a week longer and will let everyone know
> what the problems are. Why a week? I'd like to check my legal
> situation... :-(
CERT has been mysteriously silent due to other incidents. One incident
was large enough for us to post an advisory (CA-92:03). If you or anyone
believes that we have been silent too long, or not answered an e-mail
message please send a reminder or telephone us. We are a small group
and it's a large network.
As for our policy on releasing advisories, please keep in mind that most
of the sites do not have source code. Having a vendor supplied solution
is, in our opinion, the best approach. This solves the problem in the
current release of the software and in future releases. If the vendor
is unable to produce a patch and there is a work around we will make
a post (i.e. rdist advisory).
> My concience is torn between the necessity to enable owners to secure
> their machines and the danger of giving free access to even wannabe
> crackers (the "good" ones must know all about this allready). (People
> from IBM wishing to change my mind might want to give me a phone call
> at the number in my signature.)
This is a decision that we deal with daily. With each Advisory there are
always the questions of when to release it and how much to report. My
suggestion is be conservative and delay as long as possible.
We now have a good contact for IBM. One of our proactive tasks has been
to establish better contacts with the vendors. We do have a vendor
mailing list that allows us to share information between vendors. In recent
months, we have started to receive security information from vendors
in addition to end users. A couple of the CERT Advisories were submitted
to us by the vendors.
It might be a slow process and difficult to measure, but many of the UNIX
vendors are addressing security issues. The next time your organization
purchases computer equipment, ask if the vendor has a security response
group, are patches made available via ftp or uucp, and does the vendor
have a CERT contact? If these questions are frequently asked, maybe some
vendors will wake up to their customers needs.
Thank you,
Ed DeHart
Computer Emergency Response Team
Internet E-mail: ce...@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4),
and are on call for emergencies during other hours.
Brian Tao
>
>If I recall correctly, the passwd program on Unix part was so picky
>that it will say "You have to have 2 digits in your password." or
>"You have to use 2 uppercase characters." etc... It was virtually
>impossible to choose a new password (remembering it was another
>problem.. but I did not have to deal with it...:) Does anyone remember
>such machine?
The MIPS RC3330 server here (running RiscOS 4.0 and some flavour of UNIX)
demands that your password be at least six characters long, contain at least
one uppercase letter and have at least one number or punctuation mark in it.
I think most people just ended up capitalizing the first letter of their
password and then appending enough 1's to the end to make it 6 characters...
--
Brian T. Tao =*8-) | ::::::::> tcom...@bluffs.scar.utoronto.ca <:::::::
Dept. of Exobiology | :::::> generic!terranet!ta...@zoo.toronto.edu <:::::
University of Toronto | "Though this be madness, yet there is method in't."
Barry Shein
The problem with shadow password files is that it is an admission
that, should anyone get hold of the system password file, the system
has been seriously compromised.
If not, then why have a shadow password file?
Previous to shadow password files this wasn't an issue.
A better solution would have been better password encryption
algorithms, and an optionally more stringent password changer.
As it stands, with shadow passwords, one must be able to account for
any printout, backup copy or other method that someone might obtain a
copy of your shadow password files (the one with the encryptions in
it.)
Of course, most systems don't audit that, so really have no idea if
the shadow password files are walking out the door, so to speak.
Yes, it's better than nothing. But it's really not a very good way to
solve the problem.
--
-Barry Shein
Software Tool & Die | b...@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
Craig A. Finseth
|> The problem with shadow password files is that it is an admission
|> that, should anyone get hold of the system password file, the system
|> has been seriously compromised.
No, it is an admission that one among many barriers has been broken.
If a system administrator can detect that any one barrier has been
broken before they all are, the administrator can take steps to
prevent a security breach before it happens.
|> If not, then why have a shadow password file?
To create another barrier to attackers.
|> Previous to shadow password files this wasn't an issue.
Incorrect statement. Previous to shadow password files this wasn't
*recognized* as an issue.
|> A better solution would have been better password encryption
|> algorithms, and an optionally more stringent password changer.
A better algorithm would not be useful as none of the common attackers
have succeeded in breaking the algorithm. The problem is that they
cyphertext is available *at all* to the attacker.
A password setting program that disallows "obvious" passwords is
probably the single best step that any system administrator can take.
One more barrier.
|> As it stands, with shadow passwords, one must be able to account for
|> any printout, backup copy or other method that someone might obtain a
|> copy of your shadow password files (the one with the encryptions in
|> it.)
True, but not in a useful sense. In my particular circumstances, for
example, I am not worried about anyone who has physical access to our
site breaking in. I am worried about attackers who aren't from, say,
this city or state. For those attacks, it doesn't matter what I do
(within reason) with any printouts or backup tapes.
|> Yes, it's better than nothing. But it's really not a very good way to
|> solve the problem.
No successful security system is ever built around just one barrier.
Instead, a successful system will incorporate many different barriers,
some of which are hard to break and some of which are easy. Their
goal is not to provide a "Maginot Line" -- we know that will never
work -- rather, their goal is raise warning flags and buy the defender
time to take steps.
Shadow password files are one of these barriers.
Craig A. Finseth f...@unet.umn.edu [CAF13]
Networking Services +1 612 624 3375 desk
Computer and Information Services +1 612 625 0006 problems
University of Minnesota +1 612 626 1002 fax
130 Lind Hall, 207 Church St SE
Minneapolis MN 55455-0134, USA
![William Unruh [Unruh]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWv7WHGLCNCt-thA6rAm55iSwO3SZJai1pu9IxYo_K0pOMS=s40-c)
William Unruh [Unruh]
simply slow down the passwd algorithm by running through the algorithm
10000 times instead of I think it's 25 now. So Crack et al get reduced
back to a few password a second rather than 1000/sec. Again that should
buy a few years, which is all we can hope for.
Alternatively, individual sites could alter their passwd encryption to
encrypt a different number than 0 with the passwd key. This would of
course make the passwords untransportable to new sites/machines, but
that's probably not a bad thing anyway.
Bill Unruh
un...@physics.ubc.ca
Alan J Rosenthal
>that, should anyone get hold of the system password file, the system
>has been seriously compromised.
Not at all. Is the fact that you lock your car doors an admission that it's
trivial to hot-wire your car, or that you have a million dollars in your glove
compartment?
A point that most folks have been missing in the shadow password file debate is
that these risks should be multiplied together like probabilities. Someone
said that a chain is as strong as its weakest link. This is bogus. Two weak
links make a weaker chain than one weak link. To get numerical about it, if
there's a .1 chance that a cracker can scam your passwd file and a .01 chance
that they can crack a password in it once they get it, if these capabilities
are independent there is now only a .001 chance that they can crack a password
in your system. Obviously in real life we won't be able to compute numbers,
but multiplying risks is a better abstract model than simply taking the max.
Charles Geyer
fl...@dgp.toronto.edu (Alan J Rosenthal) writes:
> A point that most folks have been missing in the shadow password file debate
> is that these risks should be multiplied together like probabilities. Someone
> said that a chain is as strong as its weakest link. This is bogus. Two weak
> links make a weaker chain than one weak link. To get numerical about it, if
> there's a .1 chance that a cracker can scam your passwd file and a .01 chance
> that they can crack a password in it once they get it, if these capabilities
> are independent there is now only a .001 chance that they can crack a password
> in your system. Obviously in real life we won't be able to compute numbers,
> but multiplying risks is a better abstract model than simply taking the max.
Totally bogus. Probabilities multiply if the events are *statistically*
independent. What argument do you have for that except pure handwaving?
Multiplying probabilities that are just made up is the way people managed
to "prove" that Three Mile Island never could have happened in a billion
years.
When you think about it the probabilities are *obviously* dependent.
There may be some good arguments for shadow password files but this isn't
one of them.
--
Charles Geyer
School of Statistics
University of Minnesota
cha...@umnstat.stat.umn.edu
Alan J Rosenthal
>Totally bogus. Probabilities multiply if the events are *statistically*
>independent. What argument do you have for that except pure handwaving?
Well, I did put in an "if they are independent" in there. And yes,
security-related things certainly have security-awareness as a common
determining factor, so they are never completely independent. Nevertheless,
I'm not trying to compute actual probabilities. I'm just saying that it's
worthwhile strengthening more than one link in the chain. It's not just the
weakest link in the chain which determines the weakness of the entire chain.
Wayne A. Christopher
If you connect two weak chains end to end, you get a chain that's as
weak as the weaker one, but if you connect them in parallel, you get a
stronger chain. It all depends on whether the cracker has to get
through all the measures, or just one.
Wayne
Charles Geyer
>cha...@umnstat.stat.umn.edu (Charles Geyer) writes:
>>Totally bogus. Probabilities multiply if the events are *statistically*
>>independent. What argument do you have for that except pure handwaving?
>
>Well, I did put in an "if they are independent" in there.
I saw it. I also noted that it could not possibly mean *statistically*
independent.
>And yes,
>security-related things certainly have security-awareness as a common
>determining factor, so they are never completely independent. Nevertheless,
>I'm not trying to compute actual probabilities.
So why the bafflegab about multiplying? This just agrees that my "totally
bogus" was not overstating the case.
>I'm just saying that it's
>worthwhile strengthening more than one link in the chain. It's not just the
>weakest link in the chain which determines the weakness of the entire chain.
Well it can't hurt to strengthen links. I'll give you that. It needn't
help though. You haven't made an argument, just stated your opinion,
which is o. k. I'm not trying to argue with your opinion, just comment on
a bogus use of probability.
Sherwood Botsford
For a chain supporting a load, the failure of one link drops the load.
In this case, someone has to first get the ciphertext, then break the password.
Both tasks must be accomplished. In terms of analogy, your load is supported
by two chains, and both have to be broken to drop it.
In terms of breaking the password file, then the chain argument is valid. It
is necessary only to break the password of one privledged user;
sb