On Tue, May 08, 2012 at 07:56:12PM -0400, Michael Conrad wrote:
> 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.

Thanks to PAM's API allowing it, most protocols now have a way to
present the challenge. FTP, telnet, and SSH definitely do, and in
principle it could be done with http by putting the challenge in
whichever header it is the browser shows you when it presents the
authentication dialog.

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

This method is fundamentally insecure. An attacker passively sniffing
the connection can get the password as you enter it, but press enter
on their login prompt before you do. This is why a challenge (which
would be different for each open unauthenticated connection) is
essential to making onetime passwords secure.

The fact that we're having this discussion keeps reinforcing my point:
designing and implementing authentication schemes should be left to
the security gods, not taken up by Busybox...

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

Which was the biggest gaping environment-based security hole in
history... (YES, that really was a vuln at one point. And AGAIN when
glibc reallowed LD_LIBRARY_PATH for suids but with restrictions that
were supposed to make it safe, but overlooked some corner cases..)

Rich
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to