>-----BEGIN PGP SIGNED MESSAGE-----
>I hope I can throw some cool water on this flamewar... ;)
*real* hard to avoid capitals for emphasis, as it is a *habit*.
>>>>>> "Stephen" == Stephen Knilans <steph...@netcom.com> writes:
> Stephen> In article <yd520v36qqw....@coyote.uk.sun.com>
> Stephen> al...@coyote.uk.sun.com (Alec Muffett) writes:
> Stephen> You have to get ACCESS first! PLUS, finding out how
> Stephen> passwords are encoded wouldn't do you ANY good! You have
> Stephen> TWO choices, and ONLY two choices! try to somehow read the
> Stephen> password file, and figure the password out, or HACK IT!
>That's exactly what Alec meant. Reading the password file on a unix
>system is quite trivial. If you don't believe me, too bad, but you'll
>find out the hard way some day that it is very easy for crackers to
>get the password file from almost any unix machine without having a
I use that fact to update passwords. I'm sure many do. It is all too real.
However, *none* of my systems, not even the one at work, make it easy for
a hacker to get them. The *only* access is through login, and I could
really complicate that. A multiple step verification, where the whole
encoded password is not in the passwd file, minor changes to the ACL features
in the O/S, and some special login program could *really* complicate
matters in trying to crack the file. They would have to know the location
of all files, and the methods involved for decoding, and they would also have
to have root priveledge. Please note that I am not suggesting the SUID bit,
but rather some switching mechanism to enable/disable access to the heirarchy
based on what part of the program is running, and an ACL type setup, like on
VMS. Actually, though I HATE the VMS I/O, and assumptive file handling, the
standardized File I/O(such as ISAM), and the Access Control Lists, and a few
other things are *very* nice! Hopefully, UNIX will soon adopt that as a
I realize that this means recompiling a number of programs, etc. ALL the code
could be in a library routine to simplify things, and have some hidden
variables to make each system a little different. Similarity, while nice,
is the biggest hole in security.
>but none of them works consistently. At some point, it is just easier
>for a cracker to sniff the connection you use to type your password
seed that is only passed once. Otherwise, it could be easily broken.
>are an obsolete technology? Users will always choose the easiest
>passwords that they can, so slowing the algorithm by a constant factor
>will always just be silly.
> Stephen> If you had a few decades, and retried every password/user
> Stephen> combo a few thousand times, AND nobody changed passwords,
> Stephen> AND there were no disabling methods, you probably WOULD
> Stephen> EVENTUALLY be able to figure it out. That is a LOT of ifs
> Stephen> though!
>1) if I can get ahold of your password file
>2) if I know your crypt(3) algorithm
file. The password file contains a LOT of valuable info. Even *without*
knowing the password, it simplifies hacking in many ways. That may even
allow them to find an *unencoded* password to the account.
I am not crazy about standard routines for just that reason. I like the idea of
using a routine like crypt as only the basic encoding method. Switching bytes,
providing random seeds, and using multiple passes will make things harder.
Again, though, even the home directory info in the password file can be a big
help in cracking. Project info can also help in other areas.
>matter how slow you make the crypt(3) algorithm, and no matter how
>slow you make the login program.
> Stephen> super computer that could do 1000,000MIPS over a 100Mbps
> Stephen> link wouldn't speed up your ability to crack by even a few
> Stephen> seconds!
>But speed *isn't* dependant on the login program when you have the
> >> other channels into the authentication mechanism.
> Stephen> This is SO easy to bypass, that your statements show a GREAT
> Stephen> lack of knowledge here! You don't even need to allow FTP
> Stephen> access at ALL! If you did, you could disable it in MANY
> Stephen> areas!
>This is not the point Alec is making, I think. The point I would make
>is that unix has so many ways to get the passwd file, just plugging
>each way as you discover it is inadequate. Some superiour solution is
>needed, and slowing down login isn't it.
provide access using a new method, you should make sure that doesn't poke holes in security. Most of the security problems are obvious, or already public
> Stephen> the logon routine allowing such access.
>That is not unix, though. That's VMS.
VMS systems that had very bad security. I was once on a customers SUN system,
and they gave *me* the system passwords to at least 3 systems on their network!
I loved this! If I had a problem, *I* could fix it! I didn't have to bother
with politics, etc... Looking at it from the customers point of view, I was
scared for them! What if another had these passwords? The best security in
the world wouldn't have helped!
> Stephen> If you have the best security in the world, and allow
> Stephen> EVERYONE full access to passwords and input devices,
> Stephen> etc... it all becomes worthless.
>Exactly. Alec's point is that slowing down crypt(3) doesn't solve any
>of these inherent problems.
crypt has NO INHERENT BENEFIT".
> Stephen> WHO says you even really need a crypt routine? crypt is the
> Stephen> LAST stage in security!!!! Its SOLE purpose is to encode
> Stephen> some memory versions, and disk versions, of the password, to
> Stephen> foil many attempts at getting a password list! The IDEAL
> Stephen> idea is to avoid letting them look at that memory or that
> Stephen> file!
>This is where I think you're mistaken. The ideal you mention is
>almost completely unattainable. The cracker can nearly always get
>ahold of the passwd file without too much effort.
>(STO) and user-friendliness. STO is the (mistaken) notion that if
>something is tricky enough, then it will be secure (like leaving the
>house key under the mat).
combination. That way, a key found under the mat doesn't help too much.
>this is a high price to pay for another layer of tin foil on a steel
price you must pay! They don't like passwords either, generally.
>point, though. crypt(3) is what we're proposing to change. Assume
>that the cracker has the password file... he doesn't need to wait for
>enemy code to delay him and trick him into thinking he's cracked the
>system, he just has to get ahold of a single working password.
and/or contains only PART of the info. Otherwise, it can *still* help
> Stephen> specify! ANY failure in the routines, etc... will kick them
> Stephen> off!
>This would *not* be popular with unix users AT ALL. (Sorry to shout
>here, but, really, it wouldn't.)
this on their own. Personally, *I* don't like it, because it hurts *my*
freedom, but it is good for security.
>account just means I have twice the chance of cracking that account.
>A chain is only as strong as its weakest link.
sound. The same is true of this. I meant you would need to enter BOTH
passwords correctly, not either/or.
> Stephen> ALSO, they would have to know HOW it was to be presented!
>This is not a factor. If you are suggesting that the cracker doesn't
>know what the source to the login program is, then nobody in the free
>world knows the source, and I sure wouldn't want to run an obscure
>program as *my* login program!
read more »