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. 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. 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
