Password security - Another idea
Brad Strand
bstrand at woods.unix.eta.com
Sat Jan 7 06:30:43 AEST 1989
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."
More information about the Comp.unix.wizards
mailing list