Hello On Mon, May 7, 2012 at 4:37 PM, Tito <[email protected]> wrote: >> > Look at the code. It's not exactly bloatware. > But it is not exactly standard neither.
It is. Take any android/ios MOTP application, and it will work out of the box. You only have to configure your app (give it the shared secret) then it's just a matter of clicking on generate pin: it will give you a pin allowing you to login on busybox with the current check_password code without exposing your password. (I compared the output to mtop.sf.net - check their otpverify.sh) The only thing not yet supported is a list of one-time passwords in ~/.otpw. As explained in the RFC, it is a special list, where codes do not need a pin and which will be pruned from the list as soon as they are used. IMHO, that's not necessary but it can be added. In that case, the passwords wouldn't have to be stored - a simple hash (like in /etc/passwd or /etc/shadow) could be used. However, I strongly suggest using a /etc file for users without home dirs. Typical use case : you want someone to send you a file by FTP, you give this person one of these passwords. They won't be able to reuse it later. Could be useful for devices makers who want to allow the user to do say a firmware upgrade or run a tcpdump, but who not want the user to repeat the operation without authorization (ie they would have to give them a second password also valid one time only) > 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 A command like tool to manage the /etc/otp text file could be added, but IMHO the admin could manage the file themselves. It's just a text file with semicolon separators and plaintext everywhere. > 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) The ones who will need so much customization will be able to write the script themselves. #!/bin/sh sendmail -... > 4) I cannot believe that showing PIN on the login command line > is a good thing. Without the shared secret, it can not be exploited. It's a safe default for someone who decided to compile with the option but didn't take time to configure /etc/otp. Anyone who wants anything else can create a script and use /etc/otp to say pin should be delivered that way. > 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 The admin decides which way is the best way to deliver PINs. An admin could also create a script to dial the user and read the pin aloud. It would just take a script. I remember playing with mgetty+voice to these kind of things around 1998 (playing back wav files, processing DMTF in menus, etc.) FYI, google 2-way offers that option. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
