OTP feature for /bin/login
Rich Felker
dalias at aerifal.cx
Tue May 8 22:56:39 UTC 2012
On Tue, May 08, 2012 at 05:38:26PM -0400, Michael Conrad wrote:
> > With the little amount of thought I've done on it so far, I've concluded
> >that a viable system would have to have executables instead of shared
> >objects as atoms, i.e. the /bin/login program configurably executes into
> >/bin/login-X-mechanism, where X can be passwd, OTP or anything of the
> >kind, and /bin/login-X-mechanism does the X-specific work.
> >
>
> +1
>
> Call them "Busybox Auth Helpers" and the API is as simple as read
> "$username\n$password\n" from stdin, and return 0 or 1. Serves
> everyone's needs in about 20 lines of code added to busybox. All
> configuration and selection of which accounts are affected can be
> written into a Multiplexor which obeys the same API. You could even
> write an auth helper that dynamically links out to PAM.
A *good* OTP system (I'm not sure how good the submitted one is) needs
bidirectional communication for login. For a printed sheet of
passwords, the host has the ask the user for a specific number off the
sheet, not just any password, so the authentication method needs a way
to present this information to the user. Or if you have a device on
the client side that can generate passwords based on a challenge from
the host, you need a way to present the challenge to the user when
they attempt to login (so they can enter it in their device).
> It could be as simple as checking getenv("BUSYBOX_AUTH_HELPER"), or
> hard-coded busybox config string. If it doens't exist, fall back to
> passwd/shadow.
Letting this be configured by the environment is a gaping security
hole...
By the way, another *really* easy way to do this (back in the day, I
tacked this onto SSH1, which was unable to support integrated
challenge/response) is to make a dummy account with no password or a
publicly-available password, whose login shell is a setuid-root
program that performs the challenge-response for OTP or whatever and
exits with failure if the login fails, or switches to the target user
and execs their login shell if login succeeds.
> Writing a minimal implementation of OTP **as an applet** would
> certainly be in the spirit of busybox. Adding extra
> feature-specific behavior to existing applets IMHO is not.
Indeed, this would be one way to do what I just described.
Rich
More information about the busybox
mailing list