Reusable passwords (was: Re: password hasher (crypt()) replacement)

Reusable passwords (was: Re: password hasher (crypt()) replacement)

Post by Stephen Knila » Sun, 06 Aug 1995 04:00:00



In article <npag9qe0sn....@enci.ucalgary.ca> g...@enci.ucalgary.ca (Gord Matzigkeit) writes:
>-----BEGIN PGP SIGNED MESSAGE-----

>Hi!

>I hope I can throw some cool water on this flamewar... ;)

I didn't start it, and I am not trying to flame *anyone*.  I have to work
*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:

>[deleted]

> 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
>legitimate account.

I know it *can* be and often *is* trivial to read the password file.  Heck,
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
standard.

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.

>There are many ways to avoid the problem of getting the password file,
>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
>in.

The only way to help prevent that is an interactive encoding scheme based on a
seed that is only passed once.  Otherwise, it could be easily broken.

>Why put so much effort into trying to make passwords better when they
>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.

That is why I included a few caveats in my first post about that.

> Stephen> would be VERY difficult given the methodologies I presented!
> 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

It would be better to provide decoys, or somehow disable access to your password
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.

>That's only two ifs, and they aren't that difficult to achieve, no
>matter how slow you make the crypt(3) algorithm, and no matter how
>slow you make the login program.

As I said, speed has NO inherent benefit.  That was the basis of my post!

> Stephen> Since speed is dependant on the logon program, a
> 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
>passwd file.

Sometimes even crypt won't help in such a case.

> >>  Or I'll query the FTP daemon instead, or any of a variety of
> >> 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.

I never suggested slowing down login(except on invalid attempts).  As you
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
knowledge.

> Stephen> Obviously, *I* was speaking of a WELL setup system with only
> Stephen> the logon routine allowing such access.

>That is not unix, though.  That's VMS.

Actually, the setup DOES have a *lot* to do with security.  I have been on some
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!

>Unix users don't want VMS, they want Trusting, Open, Insecure unix.

> 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.

It was *my* point TOO!  Just look at my first post!  I said "Slowing down
crypt has NO INHERENT BENEFIT".

> >> What has this got to do with the crypt() routine ?

> 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.

I was speaking of an IDEAL which no UNIX system may have, but any could attain.

>This raises the double-headed issues of security through obscurity
>(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).

Actually, it is more like adding a second door that must be opened by a
combination.  That way, a key found under the mat doesn't help too much.

>The crackers would be driven crazy, but so would the users.  I think
>this is a high price to pay for another layer of tin foil on a steel
>door.

The users might have to enter passwords twice sometimes, but that is the
price you must pay!  They don't like passwords either, generally.

>Sure, whatever.  I really don't understand the implications of this
>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.

As I said, it would be better to make that file so that it is either a decoy,
and/or contains only PART of the info.  Otherwise, it can *still* help
hackers.

> Stephen> A captured login is one where they MUST run the routines YOU
> 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.)

Some users actually prefer it.  Perhaps 30% of my companies customers have done
this on their own.  Personally, *I* don't like it, because it hurts *my*
freedom, but it is good for security.

>I don't know what you mean by this.  Having two passwords for one
>account just means I have twice the chance of cracking that account.

>A chain is only as strong as its weakest link.

Though I may have misunderstood some things, all my advice has been good and
sound.  The same is true of this.  I meant you would need to enter BOTH
passwords correctly, not either/or.

>That's a big assumption that I'm not willing to take.

> 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!

Random numbers DO have application in ...

read more »

 
 
 

Reusable passwords (was: Re: password hasher (crypt()) replacement)

Post by Nico Garc » Mon, 07 Aug 1995 04:00:00


Bullshit. FTP and sendmail have had bugs, has httpd, that permitted
unauthorized access to system files, including passwd. Read your history,
and old issues of phrack.

                                Nico Garcia

My opinions are my own, not MIT's or my employer's or my cat's
(Well, maybe my cat's....)

 
 
 

1. password hasher (crypt()) replacement



The kind of answer I was hoping for :-).

I've been thinking about this (apart from some seed values, this could specify
the number of rounds), but I haven't got a clue where to put this information
on a Linux system (you can't hide it into a binary). And, OTOH, I want to
make the algorithm as general as possible - this would not allow it to be
used for stuff like NIS.

[Linux F-up to col.d.apps, I forgot that col.d was not in use anymore]
--

PGP26ui: 14 C4 B3 B6 97 7F CA 4F  FC 7D E8 B1 AB 25 03 19 [Key on servers]
http://www.lake.de/sonst/homepages/s2449/index.html

2. networking documentation

3. Can't set root password- Password busy error -is not due to temp password file

4. SAN lun vs Local disk

5. Mixed SHA, MD5 and Crypt Password Authentication

6. tn3270 for Solaris 2.3 anyone?

7. password encryption using crypt()

8. Savannah, GA Area - Solaris System Admin. Position

9. Apache: How to CRYPT password for .htaccess ?

10. decrypting a crypt()-password

11. Can i get AIX4.3.3 to use MD5 password crypt

12. Crypt for passwords

13. How can I crypt and decrypt a password in C