: What's the point in running Crack if you have shadow passwords? If someone
: can read /etc/shadow, they're root already and I don't care if they can crack
: passwords or not, right? Yes, I realize that users might have the same
: password on multiple systems, and a cracker who could read /etc/shadow and
: crack their password could get into their account on other systems, but why
: isn't Crack on the systems *without* /etc/shadow? No, I'm not considering
: NIS.
Well, there are methods of getting the actual passwd file, without becoming
root. So if a person figures out how to read the file, that does not
mean they will immediately become root, but it now allows them to get alot
more accounts due to weak passwords. You may want to implement a passwd
program that forces users to select harder pws.
--
Christopher William Klaus <ckl...@shadow.net> <i...@shadow.net>
Internet Security Systems, Inc. Computer Security Consulting
2209 Summit Place Drive, Penetration Analysis of Networks
Atlanta,GA 30350-2430. (404)518-0099. Fax: (404)518-0030
What's the point in running Crack if you have shadow passwords? If someone
can read /etc/shadow, they're root already and I don't care if they can crack
passwords or not, right? Yes, I realize that users might have the same
password on multiple systems, and a cracker who could read /etc/shadow and
crack their password could get into their account on other systems, but why
isn't Crack on the systems *without* /etc/shadow? No, I'm not considering
NIS.
Any words of wisdom one way or the other? I'd appreciate mail; I will follow
the group, but it's large and noisy.
Thanks in advance,
--
| Dave Schweisguth Internet: d...@proton.chem.yale.edu MIME spoken here |
| Yale Depts. of MB&B & Chemistry Phone: 203-432-5208 Fax: 203-432-6144 |
| For complying with the NJ Right To Know Act: Contents partially unknown. |
i'm sure he didn't mean anything specific, there have always been various holes
that allowed anyone to read any file on the system. remember the vixie crontab
bug?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Babak Masalehdan # Linux 1.1.50
ba...@telerama.lm.com # ...if privacy is outlawed
Finger for pgp public key. # bayl bhgynjf jvyy unir cevinpl...
|>d...@proton.chem.yale.edu (Dave Schweisguth) writes:
|>
|>>What's the point in running Crack if you have shadow passwords? If someone
|>>can read /etc/shadow, they're root already and I don't care if they can crack
|>>passwords or not, right? Yes, I realize that users might have the same
|>>password on multiple systems, and a cracker who could read /etc/shadow and
|>>crack their password could get into their account on other systems, but why
|>>isn't Crack on the systems *without* /etc/shadow? No, I'm not considering
|>>NIS.
|>
|>This is the problem with "security by obscurity" Always assume that
|>somehow or another the cracker has your password file. Otherwise you
|>will be lax and then discover that your users have used ddddd as a
|>password, which a cracker could break by hand with a number of tries.
Secret password files are not security through obscurity. They are not such
a good idea but calling them security through obscurity is wrong terminology.
This bad use of terminology used to be used as flame-fodder in the days
before shaddow password files for UNIX arrived since some of the misleadingly
named UNIX security documents made the somewhat contentious claim that it is
safer to have a world readable password file than a secret one. The more cynical
may consider it more likely that the system design was predicated on the
password file being readable and that the document in question was an excuse
to avoid doing the job properly.
|>Furthermore your cracker could have picked up one of your backup tapes,
|>in which case he has /etc/shadow, without being root. (You do store your
|>backup tapes in a vault to which only you have the combination right?)
Backup tapes should always be stored in a secure manner unless the filestore
has a secure encryption layer enabled. Keeping confidential information
confidential is the main concern of many sites.
If you have standard UNIX password files then you probably should consider them
to be plaintext since 8 characters is simply not enough to prevent a crack
by exhaustive search using modern machines.
Crack is not the way to go about the problem of excluding duff passwords. A
duff password rejection filter in the change password program is the way to go.
Cranking up the password length to at least 16 chars is also a good move.
If you can use a better one way hash than the UNIX default (sabotaged DES).
--
Phillip M. Hallam-Baker
Not Speaking for anyone else.
>In article <unruh.7...@unixg.ubc.ca>, un...@unixg.ubc.ca (Bill Unruh) writes:
>Secret password files are not security through obscurity. They are not such
>a good idea but calling them security through obscurity is wrong terminology.
>This bad use of terminology used to be used as flame-fodder in the days
>before shaddow password files for UNIX arrived since some of the misleadingly
>named UNIX security documents made the somewhat contentious claim that it is
>safer to have a world readable password file than a secret one. The more cynical
>may consider it more likely that the system design was predicated on the
>password file being readable and that the document in question was an excuse
>to avoid doing the job properly.
Security is not just cryptography, it is also psychology. All things
being equal, it is clearly better to hide your password file that have
it open to all. However things are not equal. As the post that opened
this string showed, the assumption of sys admins to a shadow file is
that the shadow file in itself is good enough. You don't have to try to
get your users trained to use better passwords. Open files at least push
the sys admin to taking password constraints seriously ( if nothing else
than by running crack)
>Crack is not the way to go about the problem of excluding duff passwords. A
>duff password rejection filter in the change password program is the way to go.
Agreed completely.
>Cranking up the password length to at least 16 chars is also a good move.
>If you can use a better one way hash than the UNIX default (sabotaged DES).
Great idea except the root password is needed for single user boot up.
and vmunix has crypt statically linked in. You can't change either the
length ( many getpass versions die with longer text) or the routine
without source ( and what company gives that away?)
A good idea might be to up the 25 rounds of DES the system does now.
--
Bill Unruh
un...@physics.ubc.ca
>What's the point in running Crack if you have shadow passwords? If someone
>can read /etc/shadow, they're root already and I don't care if they can crack
>passwords or not, right? Yes, I realize that users might have the same
>password on multiple systems, and a cracker who could read /etc/shadow and
>crack their password could get into their account on other systems, but why
>isn't Crack on the systems *without* /etc/shadow? No, I'm not considering
>NIS.
This is the problem with "security by obscurity" Always assume that
somehow or another the cracker has your password file. Otherwise you
will be lax and then discover that your users have used ddddd as a
password, which a cracker could break by hand with a number of tries.
Furthermore your cracker could have picked up one of your backup tapes,
Some thoughts...
First off, you don't necessarily have to be root to read a shadow
password file. There are ways of getting the DES encrypted password
strings without simply grabbing root and catting out the shadow file...
no, you do not necessarily need to be running NIS for this to be possible.
Secondly, the more accounts an intruder has on your system, the harder
that intruder is going to be to get rid of. If an intruder goes to the
trouble of cracking out your passwords, that intruder is going to have
the means to get back into your system even after you discover his
presence and (hopefully) patch whatever hole that was exploited to get
root in the first place.
--
------------------------------------------------------------------------
Asriel :: The Youth Underground Communications Kult Nineteen-Ninety-Four
---------------------- -------------------
lbl...@cluster.mcs.com "Hi, I'm Bruce Sterling. Have you read me?"
------------------------------------------------------------------------
main(){while(1){fork();}}
In article <3atijv$g...@bradley.bradley.edu> p...@bradley.bradley.edu (Pete Hartman) writes:
>lbl...@MCS.COM (Asriel DeCatte) writes:
>>password file. There are ways of getting the DES encrypted password
>>strings without simply grabbing root and catting out the shadow file...
>>no, you do not necessarily need to be running NIS for this to be possible.
>
>So do you care to let us in on the secret so we can protect ourselves?
i'm sure he didn't mean anything specific, there have always been
various holes
that allowed anyone to read any file on the system. remember the vixie
crontab
bug?
Or, a quite recent example: IRIX 5.2 (from SGI) shipped with colorview
being setuid, allowing anyone to read any file on the system.
Steve
--
Stephen P Potter s...@vx.com Varimetrix Corporation
2350 Commerce Park Drive, Suite 4 Palm Bay, FL 32905
(407) 676-3222 CAD/CAM/CAE/Software
So do you care to let us in on the secret so we can protect ourselves?
--
Pete Hartman Bradley University p...@bradley.bradley.edu
I mean...it's not even been a two-and-two-make five sort of a day,
it's more like a two-and-two-make...fish...
or something....
THen there's also the atmore script that uses at to read any file
regardless of permission and ownership as long as you have access to
the directory containing the file. (this works on solaris 2, don't
know about other systems.)
>
>i'm sure he didn't mean anything specific, there have always been various holes
>that allowed anyone to read any file on the system. remember the vixie crontab
>bug?
>
>--
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Babak Masalehdan # Linux 1.1.50
> ba...@telerama.lm.com # ...if privacy is outlawed
> Finger for pgp public key. # bayl bhgynjf jvyy unir cevinpl...
--
Edsel Adap
ed...@io.org (905) 669-8375
ad...@andrews.edu LINUX all the way!!!
Plenty of point, actually. Too many people wrote me for me to thank them
personally, which just shows you how foggy my mind was yesterday. The two
biggies are:
- bugs in setuid programs might allow someone to *read* /etc/shadow without
being root
- someone might guess a *really* bad password by hand
Should've thought of both (at least #1, which I would worry about more)
myself. Duh. I didn't intend to distinguish between running Crack and using
an aggressive passwd replacement, by the way.
Thanks all,
: Great idea except the root password is needed for single user boot up.
: and vmunix has crypt statically linked in. You can't change either the
: length ( many getpass versions die with longer text) or the routine
: without source ( and what company gives that away?)
FreeBSD? NetBSD? Linux?
Phil.
--
Phil Homewood ph...@rivendell.apana.org.au
APANA Brisbane Regional Co-Ordinator bris...@apana.org.au
"I can't remember anything, Can't tell if this is true or dream,
Deep down inside I feel to scream, This terrible silence stops me"
: Crack is not the way to go about the problem of excluding duff passwords. A
: duff password rejection filter in the change password program is the way to go.
: Cranking up the password length to at least 16 chars is also a good move.
: If you can use a better one way hash than the UNIX default (sabotaged DES).
Note that this is not trivial to do this right. Linux has (had) an
implementation that was flawed. the second 8 characters were treated
as a separate password. As a cracker you run crack on the second half,
telling it to do all 4 letter combinations. This will give you the
last 1 - 4 characters in a mater of seconds. Next you search /usr/dict/words
for "^????????abcd" where abcd are the letters you found in step one.
Bingo. Longer passwords even made it easier to crack it! now a simple
plaintext search results in one or a few possible passwords, whereas
otherwise I would have had to invest a few hours of CPU time to test
all words in /usr/dict/words.....
Roger.
--
* The Dutch taxdepartment announces: We will pay people back much more *
* quickly. Starting in 1997 we will start transferring the funds back *
* to the people around July instead of the current date in November. *
EMail: R.E....@et.tudelft.nl ** Tel +31-15-783643 or +31-15-137459
** <a href="http://einstein.et.tudelft.nl/~wolff/"> my own homepage </a> **
Just because your encrypted passwords are in the shadow file and are
only readable by root, that does not mean that one of your users has
chosen a bad password.
Crack allows you to determine which users have chosen passwords that
can easily be guessed. It allows you the opportunity to change those
passwords before someone cracks that account. Remember the first line
of defense on crackers is making sure that your users are not leaving
the door unlocked.
Tom Haynes
Sybase, Inc.
Quite - and the old old finger bug and the certain vendors shadow library
use korn shell as your login shell and cat file descriptor 12.... 8)
Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''
> Note that this is not trivial to do this right. Linux has (had) an
> implementation that was flawed. the second 8 characters were treated
> as a separate password. As a cracker you run crack on the second half,
> telling it to do all 4 letter combinations. This will give you the
> last 1 - 4 characters in a mater of seconds.
That wasn't Linux, as such, that was Shadow. Bad design, if you ask
me. The idea, I think, was that naive programs which only looked at
the first eight characters would still work. Trouble is, they mostly
don't anyway, as they use strcmp(), not memcmp(), to check.
Ultrix (4.3A) has a crypt16() function that seems to work similarly to
crypt(), but takes a 16-character password and emits longer
ciphertext. But it's not the broken scheme described above. Anybody
know what it is, and whether it's secure?
--
- David A. Holland | Any sufficiently advanced bug is
dhol...@husc.harvard.edu | indistinguishable from a feature.
> Quite - and the old old finger bug and the certain vendors shadow library
> use korn shell as your login shell and cat file descriptor 12.... 8)
Not to mention mode 666 core dumps of /bin/login found in the root
directory, as somebody mentioned here a few days ago in connection
with Solaris...
My concern wasn't for the last 8 characters, but the first 8. In the
years since I've spent a significant amount of time muddling over the
algorithm I use in Shadow and I always come back to the same
conclusion -- if the first 8 are so weak that having the last 1 to 8
gives you the first 8 trivially, you can trivially go the other way
as well.
My observation back when I wrote the code (and I had one of the first,
if not the first, publically available enhanced security products for
the UNIX market) was that all of my "long" passwords were just one or
two characters longer than an 8 character password. I looked at the
extra letters like a "Keep Out" sign. If you see one of those 24
character encrypted strings, you know for an absolute fact that you
have to crack a full 8 character password at a minimum. You might
get off easy with the last 8 characters, but you still have to do all
8 of the first ones.
There is some experimental code in one of the modules for doing SCO
UNIX-style encryption, but I've never had a request to enable it. It
allows 80 character passwords if you want them.
>Ultrix (4.3A) has a crypt16() function that seems to work similarly to
>crypt(), but takes a 16-character password and emits longer
>ciphertext. But it's not the broken scheme described above. Anybody
>know what it is, and whether it's secure?
I don't know about Ultrix, but some other vendors, including one vendor
with a genuine C2 rated product, use a scheme similar to what I came
up with for Shadow.
--
John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: j...@rpp386.cactus.org
There are three documents that run my life: The King James Bible, the United
States Constitution, and the UNIX System V Release 4 Programmer's Reference.
> What's the point in running Crack if you have shadow passwords?
Just because you have shadow passwords doesn't mean you have good
passwords. It is true that some versions improve the user's choice of
passwords. Even so, how sure are you that somebody might not guess a
password? Or that one of your users picked the same password on
another system that isn't using shadow password files? They can run
crack on another system, find the password, and try the same password
on your system.
--
Bruce Barnett <bar...@crd.ge.com> uunet!crdras!barnett