[PATCH] Out-of-band challenge (OBC) authentication method

[Ben Lindstrom]

To take this a step farther wouldn't it be better to build this more like 
the "ProxyCommand".  I'm not thrilled with the idea that we start adding 
massive amount of authentication methods that are used by a dozen people. 
I'd rather see someone invest the time in a good external proxy method for 
adding in custom authentications (Even at that, I dislike it from a 
security view since it makes it easier to compermise the deamon).

Also, email isn't very reliable and timely transmission of information. 
Even worse if you are sending it to an SMS gateway.

- Ben


On Wed, 6 Feb 2008, Daniel Kahn Gillmor wrote:

> On Wed 2008-02-06 00:47:08 -0500, paul wrote:
>
>> This patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1438) creates
>> a kbdint device that provides a server-based authentication
>> mechanism. The server generates and emails you a random string when
>> you attempt to login. You're authenticated if you can correctly answer
>> the challenge.
>
> Thereby proving the old adage that every program expands until it can
> send mail ;)
>
> This is a seriously neat idea, but i'm not sure why you'd want to
> limit it to sending mail, or assuming that the particular type of SMTP
> submission you've implemented here will work for everyone (port 25
> might be blocked, users might need TLS, SMTP authentication, etc).
>
> Wouldn't it make more sense to make this a spawnable, unprivileged
> sub-process that accepts the challenge on stdin?  For example, this
> could be specified as:
>
>   ChallengeMethod mail -s 'Challenge from %h' %u
>   ChallengeMethodUser nobody
>
> (meaning "for each challenge, as the user 'nobody', invoke
> /usr/bin/mail with these arguments")
>
> This would be instead of having to specify ChallengeSMTPServer.
>
> If you'd like to remove the challenge-generating part from ssh as
> well, you could also implement it as a spawnable unprivileged
> subprocess which emits the challenge on stdout, which would probably
> be better.  This would allow an external system to do things like
> buffer a single challenge for a limited duration (instead of issuing a
> dozen different challenges for a single user at once), or select its
> challenge from an alternate randomized string space.
>
> An administrator could also make use of the already-present Match
> functionality to avoid needing ChallengeUsers in the config file.
>
> This would remove the mail-sending and user-mapping functionality from
> ssh, which means it would be much more flexible for other users (who
> might prefer the OBC to be delievered to an authenticated RSS feed,
> posted to a bulletin board in steganographic form, etc).
>
> The patch would need to make sure that the spawned out-of-band
> challenge drops as much privileges as possible, and admins would need
> to make sure that their chosen ChallengeMethod is not dangerous or
> subject to format-string expansion in dangerous ways.
>
> It also occurs to me that if this is implemented, it could create a
> way for anonymous miscreants to cause a mailstorm for the targeted
> user simply by trying to log in as hir.  I think this is true even in
> conjunction with MultiAuth, because it doesn't look like the MultiAuth
> patch allows the server to mandate an order in which the
> authentication flavors are run (client-chooses-auth seems to be built
> into the SSH protocol, if i'm reading my ssh -vvv output correctly).
> If those challenges are 10-penny-apiece text messages, this auth
> method could rack up quite a bill.
>
> One last general thought: why not build this functionality as a PAM
> module instead of a patch to OpenSSH?  If you did that, OpenSSH
> systems that use PAM could make use of it directly, and so could any
> other PAM-enabled systems.
>
> Thanks for writing this up and publishing it, Paul.  It's very
> interesting.
>
>       --dkg
>