Hello On Sat, May 5, 2012 at 4:42 PM, Tito <[email protected]> wrote: > This is rather curious, you have the secured channels behind a firewall > and the non secured channels not firewalled?
Sorry this might be a bad example :-/ I was thinking about someone at work behind a company firewall where maybe only outgoing port 80 and port 23 are opened, along with deep packet inspection to avoid ssh listening on port 80. Or add port 443 to the list, but with the server decrypting the SSL and reencrypting it as its own certificate authority that is installed in the client browser, to allow inspection of encrypted data. Or maybe you prefer to use telnet because you don't have a ssh client. Or you are using a computer where you fear a keylogger might have been installed. In any of these cases, you do not want to expose your password. OTP is just that : a throwaway password you can use as an alternative in any case you don't feel comfortable exposing your password. > 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? As long as you know the time the server use and use it too, everything goes. At the moment I display the epoch as a work around hwclock issues. You can also query the server time by any way you like (telnet on port 13, 37, ntp...) > 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? If your cellphone is stolen or your server is hacked you may have other issues :-) Joke aside, having the shared secret without knowing the pin is worthless. It is not a password by itself. Yet with the pin, it becomes one. Which is why the pin should be generated as randomly as possible, and delivered by a 2nd channel if possible. Something similar is used by google 2-way auth : the pin is sent by SMS to the user MOTP is not as good as 3 factor auth, but it's better than a plain text password. > What is the advantage vs. a normal password > that is only on the server and in your head? Let's say you are using telnet or a network I have setup, or ssh on a public machine where I have a keylogger. tcpdump or the keylogger will give me your password, which I can reuse it as much as I want. But if you know the timewindow of your server, with careful timing and a dedicated client, MOTP can reduce than to one second. I will not be able to get your password in time to use it. Basically, MOTP protects your password against passive listening and replay attacks. > 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? No, the pin is generated. It changes everytime. I was only suggesting that the shared secret to be in a list since as you mentioned a single shared key is a vulnerability > and kept where? in the user's home dir or in /etc? I don't know. Everything can be done. At the moment IMHO the cleanest way would be like for shadow passwords, in a separe /etc file > epoch+pin+realpassword = no need for shared secret Unless you don't want the real password to be sniffed - or are you saying to create the md5 with that? Then this requires storing the real password in clear text or with some reversible encoding. Not a good idea. In this case, the password would then become a shared secret! > 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? I'm just throwing ideas around. The data exchanged will still be in clear text, but at least your password is secure. > 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. It works the other way - in google 2-way auth, for example the pin is sent by SMS. > I would run this service on a different port and standalone > so you don't need to mess with passwd/shadow files Alternatively, the shared secret can be a compile time option. Even if it is in cleartext in busybox binary, it only serves to protect the user password. It allows you for example to telnet for a quick reboot when your ssh daemon is down. > Just a few ideas. Thanks for the feedback! I suggest you check RFC 2289 for more info about how MOTP works, and the general design. motp.sf.net is also interesting. Some iphone and android apps are listed on http://www.clavid.com/index.php?option=com_content&task=view&id=124&Itemid=157 Guylhem _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
