OTP feature for /bin/login

Fri May 11 18:20:38 UTC 2012

----- Ursprungligt meddelande ----

> Från: Tito <farmatito at tiscali.it>
> Till: busybox at busybox.net
> Kopia: 
> Skickat: fredag, 11 maj 2012 8:09
> Ämne: Re: OTP feature for /bin/login
> 
> 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.

Our current firmware image weighs 7.6MB and (apart from BB) it includes
Nagios Core, tcpdump, nmap, dropbear, RRDtool, SQLite, custom apps, etc.
Adding a few MB just for PAM does not attract me.

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

So? BB includes HTTPd, then it needs to have a browser as well??

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

Again, I do not see the need for any clients.
BB is very popular on embedded devices and that's where the
server (verifier) comes to play. OTP clients belong on desktops
(or smart phones) and there are already plenty of alternatives
there, so why bloat BB with an OTP client?

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