OTP feature for /bin/login

[Tito]

On Monday 07 May 2012 21:13:16 Sven-Göran Bergh wrote:
> Hi,
> 
> and first of all a big thanks to Guylhem for the patch.
> I think the idea of bringing OTP to busybox is really
> great. It would certainly be useful in our projects.
> 
> 
> >>  This argument can be made for any _ONE_ custom authentication feature.
> >>  The problem is that if it's made for _EVERY_ custom authentication
> >>  feature, you have a bloatware nightmare.
> > 
> > Very true.
> > 
> > But at least one authentification feature not exposing the password
> > should be easy to include in a static binary.
> > Considering how simple OTP is, I believe it would be better to have it
> > right there.
> > 
> > Look at the code. It's not exactly bloatware.
Hi,
But it is not exactly standard neither.

> I agree PAM is a good generic switchboard for different auth solutions,
> but it soaks up some space (and complexity) on its own as well. Being
> forced to use PAM to gain access to a simple OTP solution would lower
> my interest in it.

I vote for PAM, this stuff in my opinion does not belong to busybox:

1) utilities/functions to handle /etc/shared_secred or /home/user/shared_secret
    are still to be added (other non standard stuff - more bloat)
    Unless you want to do it by hand, you need progs:
    a) add/del user from file
    b) change pass
    c) check the screts file for corruption
2) machinery to send PIN by SMS, email or whatever is still to be added
    (at least as hooks to call external binaries/scripts, so other non standard stuff - more bloat)
3) busybox already provides PAM hooks in login that allow you to do all this
     without adding more code and #ifdefs and config options
4) I cannot believe that showing PIN on the login command line
    is a good thing.
5) due to the small time windows aimed at I doubt it could be reliable
    in reality as I've seen mails and SMS being delivered after hours
    (when the OTP would be already invalid). Calling in with a 
    known tel number within let us say 30 secs could be a solution
    in terms of reliability but needs even more machinery yet to be coded
    and presumes that every system is able to recieve phone calls
    which is not the case. Http as suggested later on could be
   a viable solution at least for the possible timing issues.

Just my 2 cents.
Ciao,
Tito
> Some other thoughts as well:
> 
> 1) Using a separate /etc file (/etc/otp) to store the shared secrets
> gets my vote. This is a good way to have different shared secrets for
> each users. Furthermore, it applies for accounts that lacks a home
> directory as well.
> 
> 2) Would it be possible to leave the 2:nd channel (delivery of the pin)
> to a separate user supplied script? In that case it would be simple for
> the admin to setup the delivery as desired by eg. a simple shell script,
> SMS, HTTP(S), netcat magic, SMTP, etc.? This would be a very simple,
> and yet flexible and powerful approach.
> 
> Thank again! Let's find a solution to implement OTP the busybox way.
> Simple, flexible and yet powerful. I think that the original patch
> is pretty close and a good starting point. With a few tweaks, I think
> it has the potential to become a killer feature.
> 
> Brgds
> /Sven