OTP feature for /bin/login

[Michael Conrad]

On 5/8/2012 6:56 PM, Rich Felker wrote:
> 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).

My thought here was that you can't always alter the original protocol 
that much (httpd, ftpd, etc).  If you can and need to, then you might as 
well just write a custom daemon  (which actually, is exactly what you're 
describing below with the ssh passthrough) or use PAM.  Writing a 
one-size-fits-all authentication API is not a simple thing, and I think 
any attempt to do so would end up as complex as PAM.

The OP was describing a system where you'd have your phone 
time-synchronized with the server, and be unidirectional.  Your phone 
knows what the correct password is at any given time.

>> 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...

I was about to say "not any worse than LD_LIBRARY_PATH", but I suppose 
then it would need the same special restriction for setuid programs.  
(It would just require a check of geteuid... but you're right, probably 
better to forget it and either use a config file or hard-code it.)

-Mike