On Thursday 10 May 2012 22:28:49 Sven-Göran Bergh wrote: > Hi, > > ----- Ursprungligt meddelande ---- > > Från: Tito <[email protected]> > > Till: [email protected] > > 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
