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