OTP feature for /bin/login

[Guylhem]

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)

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.

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.

Now for busybox:

On Sat, May 5, 2012 at 4:08 AM, walter harms <wharms at bfs.de> 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 to be a drop-in replacement for
/bin/login. It could also go into a separate file, 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)

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.

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).

Also, the PIN could be send by a different channel such as SMS.

> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: motpgen.c
Type: text/x-csrc
Size: 1032 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20120505/c1adde36/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: correct_password.c
Type: text/x-csrc
Size: 5870 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20120505/c1adde36/attachment-0001.c>