OTP feature for /bin/login

[Sven-Göran Bergh]

Hi,

----- Ursprungligt meddelande ----
> Från: Tito <farmatito at tiscali.it>
> Till: busybox at busybox.net
> Kopia: 
> Skickat: onsdag, 9 maj 2012 22:52
> Ämne: Re: OTP feature for /bin/login
> 
> On Wednesday 09 May 2012 21:38:26 Sven-Göran Bergh wrote:
>>  >>  This should be easy to fix either in the current implementation 
> of PAM
>> 
>>  > 
>>  > Ha, ha.
>>  > There are reasons why I'm (slowly) rewriting the world instead of
>>  > contributing to other projects. One of the main reasons is that most
>>  > people write code of HORRIBLE quality and I'll take no part in 
> that.
>>  > PAM is no exception.
>>  > 
>>  > 
>>  >>  or by writing a replacement for the main PAM code that can use 
> the existing 
>>  > module
>>  >>  code
>>  > 
>>  > Maybe, but the workings of PAM are inherently complex. I'd rather 
> design
>>  > a simpler API.
>>  > 
>>  >>>  [ to have executables instead of shared objects as atoms ]
>>  >>  No, this is just as broken and probably is full of security 
> problems
>>  >>  to be considered. Running child processes is anything but 
> transparent
>>  >>  to the calling program.
>>  > 
>>  > Huh ? Who said anything about child processes ? I was talking about
>>  > something like the checkpassword interface (see
>>  > http://cr.yp.to/checkpwd/interface.html ), but enhanced to provide the
>>  > functionality that OTP and other auth schemes need. No child 
> processes,
>>  > just chain loading.
>>  > 
>>  >>  or else have a local "pamd" that does all the 
> authentication work
>>  > 
>>  > That's another viable solution indeed. But people might not like 
> it
>>  > because it's not transparent.
>> 
>>  I actually have hard to believe this is the busybox mailing list.
>> 
>>  Several PAM replacements are discussed, some as complex as the original,
>>  some a bit simpler. Don't get me wrong I would love to see a *simple*
>>  PAM replacement. Until that replacement is in place and has proven
>>  itself worthy, lets focus on the patch supplied by Guylhem.
>> 
>>  First it was turned down because "this belongs in PAM".
> Hi,
> In fact it already exists http://motp.sourceforge.net/pam_mobile_otp-0.6.1.tgz
> (some info also at http://www.worksinmymind.com/blog/?p=1083)
> plus "motp-manager", a shell script to simplify user management
> (http://motp.sourceforge.net/motp-manager.sh)
> and there is even a Android client (http://motp.sourceforge.net/Mobile-OTP.apk)
> and for PalmOS and for J2ME phones and  a Web App for every device with
> a Javascript enabled browser.
> 
> PAM_module_exists + we_have_the_hooks_for_PAM = use_PAM_IMHO

IMHO PAM does not make any sense on a BB system. What is the minimal
footprint of PAM _including_ all its dependencies?? Enough too render
it useless when you care about size. Consequently, I couldn't care
less about what PAM modules that exists or not. There is no way I
will use them any way.

>>  When pointed out that PAM is bloated and complex, several innovative
>>  ways of replacing it are discussed.
>> 
>>  IMHO the patch follow the bb spirit. It is lean, simple and supply a
> 
> "BusyBox combines tiny versions of many _common_ UNIX utilities into a 
> single small executable. "
> 
>>  powerful feature. Furthermore, it is not mandatory!
>>  CONFIG_FEATURE_LOGIN_OTP is disabled by default.
>> 
>>  As pointed out earlier there may be some minor tweaks needed, and we
>>  have already touched on most of them. Until I see a PAM replacement
>>  that is lean, simple and secure I would love to see the patch
> 
> So far there is no patch, just a proof of concept that needs polishing.
> I think that the code should be moved out of correct_password
> to its own file (but obviously Denys is the boss, he will decide),  
> It is also unclear to me if the client side motpgen should also
> be included in busybox, maybe along with other programs

I do not see any reason to include the client utilities in BB.
What Guylhem proposes is to include the _verifier_, i.e the
server part. As you already pointed out there are already
several clients out there.

> to send SMS, make phone calls and read PINS on the phone.
> I wonder also if the motpgen should be made multiplatform
> due to the number of different OSes out there.

Same here, no reason to include any of this in BB. Since
anyone may choose their different way of delivering the PIN
back to the user. A few lines script will do for most cases
and that is for the admin to take care of.

> There is the issue about the shared_secret in motpgen,
> should it be hardcoded or do we need to carry a piece
> of paper to remember it.

Guylhem suggested to skip the lists with PIN-less one time
passwords, and I agree. I do not see that as a central part.
What attracts me is the simple verifier and a flexible way
of configuring the delivery of the PIN back to the user.
That is all!

When it comes to the shared secrets I think the proposed
/etc/otp will do. To start with I could live with a root
only file that is not managed by users.

I think that many of the reactions to the OTP patch confuse
it with an entire OTP framework: client, server, all kinds
of delivery utils, etc. It is not! It is just the most
essential part of the server needed to generate the PIN and
verifying the response. Nothing else, lean and simple.

/Sven