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

[Paul Sery]

Daniel Kahn Gillmor wrote:

> On Wed 2008-02-06 00:47:08 -0500, paul wrote:
>
> Thereby proving the old adage that every program expands until it can
> send mail ;)

As they say, it seemed like a good idea at the time! I was unaware that 
this was a common pitfall.

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

Email seems like the most logical channel for this system. I'll adopt any 
medium that proves better.

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

That makes sense. I originally hard-wired an MTA/system call to do 
(crudely) just what you describe. It then seemed better to fold the 
function into sshd. I'll rewrite to learn the method to use from 
sshd_config. This would indeed be cool since the method could be anything 
including an ssh pipeline to some ssh-aware device that you carry around.

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

I'm all for making things simpler for my fellow admins. I'll start 
thinking about how to do it. Btw, my contrib/gnome-ssh-askpass2.c patch 
https://bugzilla.mindrot.org/show_bug.cgi?id=1393 does something similar 
to what you describe. As you know, it generates a random string and writes 
it to a fifo. A perl script reads the string and emails it to the user.

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

This must be addressed. I think Multiauth or 
https://bugzilla.mindrot.org/show_bug.cgi?id=983 could be modified to 
prevent this. For instance, stop overall authentication if pubkey fails.

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

On my to-do list. I know a little about how OpenSSH internals work but 
nothing about PAM innards.

> Thanks for writing this up and publishing it, Paul.  It's very
> interesting.
>
>      --dkg

Thanks for taking the time to review this idea.