Hello On Tue, May 8, 2012 at 2:24 PM, [email protected] <[email protected]> wrote: >> The very fact that we're having a discussion about the redesign of >> this OTP system on the busybox list seems like proof enough that it's >> a very specialized need that does not belong on busybox.
A simple yet well behaving /bin/login is not a specialized need - not for an embedded system with static binaries. > Ok, this is an argument that hits. I have a very basic need and I do not want to add features that I don't see a strong interest for, to avoid bloat. MOTP generators are widely available (motp.sf.net, + the previous links for various smartphone apps) on all kind of platforms. There is no real risk of bruteforcing. It is a subset of a more popular implementation, doing away with per-user files for the sake of simplicity. IMHO it follows the spirit of busybox, so the current implementation was submitted since already covers most of the needs as it. It was also submitted for *feedback and discussion* because it could be easily refactored to provide a much better replacement to the current correct_password.c Add a /etc/ file as Sven proposed, and it will cover 99.9% of the need (sending the pin with a different channel and setting up different shared shared passwords per user or disable otp on a per user basis) > ... this would be a low intrusive enhancement of Busybox to allow > alternate authentications without need of enabling full pam api. This same file could be used when compiled without OTP, to do a specific auth on a per user basis (with custom scripts for special requirements - ex for root you want a OTP + a phonecall, etc) But what about adding OTP just as-it, without the /etc file, check users feedback, and complete it with the /etc file if there is a wide demand? Guylhem _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
