Password security - Another idea

[Brad Strand]

The recent discussions regarding Unix password security (and the lack
thereof) got me wondering about other authentification schemes.  One
such scheme that I haven't seen mentioned here, is replacing the password
with a 'pass-function'.  By that I mean that instead of having a
password such as "xyzzy", each user would have his/her own personal
function F, perhaps like

    F(C) = 4C + 3

The idea would be for the system to replace the "password:" prompt
with a prompt more like, "How about C?", where C is some reasonably
small (maybe 16-bit) random "Challenge" number generated by the system.
The user must then apply his/her pass-function to this particular C,
and enter the resulting F(C).  Example:

   login: <bstrand>
   How about 1204? <4819>
   Welcome, Brad!   ... etc.


Some advantages of something along these lines:

1. Since the required response is non-constant, brute-force attacks (trying
   all possible passwords) would not be likely to succeed.  In other
   words, if there were p possible passwords, I am guaranteed of finding
   the correct one in at most p trials.  If, however, there were f possible
   responses to the system's challenge, I am NOT guaranteed of succeeding
   in f trials, since all trials are (in a sense) independent of one another.

2. People "sneaking-a-peek" at you logging on would not (most probably)
   be able to log in as you later.

3. Same as (2) for people using a network monitor or "Trojan Horse" login
   program.

4. Intuitively, mathematical functions seem more "uniformly distributed"
   than passwords...Hence, it seems more likely that someone would use
       N = 3C^2 + 1331       as a pass-function, than it would be for 
   someone to use  "Bn&@v8}?" as a password.  (Intuitively, there seems
   to be far more easy-to-remember functions than easy-to-remember passwords,
   but I could very well be wrong here.)


Some Disadvantages:

1. People might tend to pick simple 'pass-functions' (N = C + 3)
   because more difficult ones might be either harder to remember, or
   harder to calculate in one's head.

2. Would need to come up with a standard method of representing and/or
   encrypting the pass-functions for use in the '/etc/passfunc' file.
   This is probably non-trivial.


Questions:

1.  Am I really missing the boat here?  Would something like this be 
    a stupid waste of time?  Or might something along these lines
    actually be useful?

2.  Has anyone tried something along these lines on a per-user
    basis?  (Quite a while back, I remember using a
    pass-function on a "system-wide" basis.  It was a program
    used to screen access to a dial-in line.  The user had to
    respond correctly to a Challenge before a "shell" would be
    created...I say "shell" because it was non-Unix system...)
   
3.  Obviously, I've greatly oversimplified the implementation in
    this description, but what improvements (if any) could be
    added to strengthen this sort of scheme?  Example:  the
    system could issue two Challenges, C1 and C2.  Now we have
    two variables to use in the function...would this help? Etc.


Brad Strand, ETC-03J             bstrand at woods.unix.eta.com
ETA Systems, Inc.                      "Racing to Win"
1450 Energy Park Drive               
St. Paul, MN  55108                     "So it goes."