Passwords

[Scott Bennett]

In article <17401:Apr1307:58:0691 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <1991Apr12.120209.21241 at mp.cs.niu.edu> rickert at mp.cs.niu.edu (Neil Rickert) writes:
>>  What I have never understood is why the password encryption algorithm doesn't
>> use additional information other than the password - the user name and the
>> machine name (or domain name for YP based networks).  That way anyone who
>> broke one encryption has succeeded only in breaking it for one user on
>> one system.  Sure, this would make life slightly tougher for administrators
>> when propogating accounts to another host.
>
>There's another reason, probably the more important one: if crypt()
>depends on the hostname and username, then somebody has to keep that
>information around and give it to crypt(). Since so many different

     Well, yes, things like login and rlogind and su would have to
provide that information to crypt().  There may be a couple of others,
but the quantity of programs involved would not be unmanageable, nor
would the changes to those programs be particularly monumental.

>programs use crypt() in so many different situations, this is (for all
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>practical purposes) impossible.
>
>I advocate a *single* program to do *all* password checking. You give it
>a login name and a password on its input; it gives you a username on its
>output, or exits 1 with no output. If every use of crypt() were changed
>to use this program instead, it would be trivial to add features to
                                          ^^^^^^^
     Possibly, but the vendors would probably be so busy fixing the
rest of the programs (see your own reason that I underlined above)
that broke when the changes were made that they would have few
resources left to add the features.  Neil has the right idea.

>increase security. But do you expect vendors to have enough foresight to
>take lasting modularity over short-term convenience?
>
>(By the way, kludging usernames into passwords doesn't really help
>except for stored-dictionary attacks. If the username is XORed in before

     Where in the grid did you get the idea of XORing anything?
Neil's posting certainly didn't say anything like that.

>encryption, you can break the password independently of the username. If
>the username is XORed in after encryption, it's pointless.)
>
>---Dan


                                  Scott Bennett, Comm. ASMELG, CFIAG
                                  Systems Programming
                                  Northern Illinois University
                                  DeKalb, Illinois 60115
**********************************************************************
* Internet:       bennett at cs.niu.edu                                 *
* BITNET:         A01SJB1 at NIU                                        *
*--------------------------------------------------------------------*
*  "Well, I don't know, but I've been told, in the heat of the sun   *
*   a man died of cold..."  Oakland, 19 Feb. 1991, first time since  *
*  25 Sept. 1970!!!  Yippee!!!!  Wondering what's NeXT... :-)        *
**********************************************************************