HI, some thougths about about OTP. On Saturday 05 May 2012 20:50:47 Guylhem wrote: > Hello > > I received a private reply asking if it was similar to OPIE, so I will > first explain how OTP works : imagine for some reason (you go in > vacation, firewall, etc.) you can only access your machine on non > secured channels such as telnet or web port 80 in http mode only > (shellinabox)
This is rather curious, you have the secured channels behind a firewall and the non secured channels not firewalled? > You do not want to compromise your password, so you give instead a > password that will only work one time : in the next N minutes > timeframe. > If you know the precise "acceptable window" of your remote server and > if your times are synchronized, you can also give a password only > valid for say the next 5 seconds. Do you have to take into account legal time, time zones, hwclock deliberately set to future or past or nonsense or not so precise on the two boxes? > The One Time Password t is generated by your laptop or mobile (ex: OTP > for the N900) from a shared secret. Giving the OTP will not expose the > shared secret. If I understand correctly you need to have this shared secret but let us call it password on two machines rather than on only one, don't you double the risk of it being stolen, grabbed, read by some malicious user/software? What is the advantage vs. a normal password that is only on the server and in your head? The Pin you talk about later in the mail must also be stored on the server or does it change every time or is taken from a list? > Now for busybox: > > On Sat, May 5, 2012 at 4:08 AM, walter harms <[email protected]> wrote: > > feel free to post your code. please provide some information so we can > > evaluate it, e.g. > > how did you test your code ? > > I first made a standalone implementation, then ported it to busybox. > (the code is being reviewed by someone well versed in security - I > will pass the review result/fixes as soon as I get them) > > The tests were similar and quite basic : > I did set the pin to a given value, printed the list of acceptable > password and tested with randomly generated passwords along with the > right passwords. > I tried to login for unkown and given users with the right password > and a wrong password. > > There is no test suite yet, because it would require that the OTP > generator knows the shared secret. It is a first implementation and I > would welcome some feedback to change it. > > First, I was wondering where the shared secret should go - at this > time it is a compile-time #define Not a good idea as you cannot change it and maybe it could be read from the binary by every user with sufficient permissions. > to be a drop-in replacement for > /bin/login. It could also go into a separate file, and kept where? in the user's home dir or in /etc? > or into a field in > /etc/password so that each user could have its own shared secret, or > it could be a list of random values changing each day (the most secure > option) Not standard, could break other stuff and seems funny to me to keep a secondary password in the password file so that in the end OTP is just a password and in this case we could use directly the real password to generate the OTP. epoch+pin+realpassword = no need for shared secret > > For this last idea, I was thinking of adding QOTD support to inetd, > which could be used to publish yesterday shared secret (no longer > accepted), and thus help the OTP generator synchronize it list. It may > be security through obscurity (port knocking like), but a QOTD > followed by an OTP attempt could also be used in firewall tables to > "unlock" the telnet port. If you are willing to do all this setup for OTP/QOTD/port-knocking/time, why you just don't setup SSH rather than telnet on your machine? > > Is it acceptable to add a QOTD support to inetd? > > > are additional libraries needed ? > > No library are needed. Everything is implemented in the function. > I also create a generic "getpin" function should other apps in busybox > need to generate a random password of non repeating elements. > > Currently epoch/10 is printed next to the challenge, but could be > removed (the otp generator could connect to port 37 if there is a > worry that time is not synced). One more service to setup complexity grows. > Also, the PIN could be send by a different channel such as SMS. This is a good idea, require the user to ring or SMS from a KNOWN phone number int the next N seconds after having inputted the password. > > > special compiler options ? > > Nothing needed. Compiles with default Busybox options. > > > What is about hardware requirements ? > > As long as you can run busybox you are good to go. > > The use case when the option is enabled is as follows : > - if the user submits a known password, then accept it, > - if the password is unknown, see if it matches with a list of valid > OTP for the time window > - if it matches, then accept it. I would run this service on a different port and standalone so you don't need to mess with passwd/shadow files > The OTP can be generated by any MOTP capable application, such as OTP > for the n900, or various shell script available online. > I also attached a quick and dirty motp-gen written in C. I'm not use > how usefull it could be for busybox. > > The basic concepts of OTP are simple, but there are design issues, and > since it goes into /bin/login, it's better to be carefull :-) > > I welcome any code review. Considering it was done on a friday night, > I may very well have done mistakes. I will run further tests on the > code soon. > Also, the code may not be very optimized. > > It is my very first contribution to busybox, let me know if I'm doing > something wrong > > Guylhem > in motpgen.c : /* No \n in MOTP */ sprintf (motp, "%d%s%s", otpepoch, argv[2], argv[1]); check length and type of the args, and null terminate them to the permitted length, maybe null terminating motp (and/or zalloc) would be also safer. Zeroing argv[2], argv[1] and motp when they are no more needed could be also a good thing. Just a few ideas. Ciao, Tito _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
