OTP feature for /bin/login

[Tito]

On Thursday 10 May 2012 22:28:49 Sven-Göran Bergh wrote:
> 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.
Hi,
libpam0g on debian is a 250kb package
libpamruntime is 1278 kb including all docs and locales
libpammodules is 1016 kb  including all docs, locales, manpages and all modules
(but I suppose that you will need just a few modules) 

so it could be stripped down to a reasonable size.

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

It should be included for the same reason we have e.g.
ftp server and client. You are thinking just about your needs here,
or you ship a complete implementation or don't ship it all,
nonetheless I still believe this stuff is not so commonly used
that it needs to be in busybox.

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

But you have to add the hooks to busybox's code
for this to happen.
 
> > 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.

And on the client side? Hardcoded?
 
> 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

Ciao,
Tito