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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
