openssh unix dev - Feb 2008 - [PATCH] Out-of-band challenge (OBC) authentication method

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.

You can use a regular email account, a pager, cell phone or other email 
capable device to receive the challenge. However, by using a physical 
device you can receive a one-time authentication secret isolated from 
your workstation.

OBC can be used in conjunction with the "Multiauth" patch 
(https://bugzilla.mindrot.org/show_bug.cgi?id=1435), to create a 
two-factor authentication system; Multiauth allows you to require two or 
more authentications for a successful login. Combining OBC with 
Multiauth creates two physically separate authentication factors 
equivalent to a commercial two-factor token. For instance, requiring 
public key and OBC authentications creates physically separate factors.

See README.obc for configuration and installation information
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-4.7p1-kbdint-obc.patch
Type: text/x-patch
Size: 32846 bytes
Desc: not available
Url :
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080205/06b9d576/attachment-0001.bin

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url :
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080206/218564e1/attachment.bin

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.