OTP feature for /bin/login

[Tito]

On Sunday 06 May 2012 08:22:49 Alexander Kriegisch wrote:
> Guylhem, 05.05.2012 23:50:
> > 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.
> 
> Some background info so Guylhem does not need to explain everything
> incl. the "hows" and "whys" from scratch:
> 
> For those who speak German, I found the old Heise article which
> initially sparked my interest in OPIE five or so years ago:
> http://www.heise.de/security/artikel/Einmalpasswoerter-fuer-den-Heimgebrauch-270884.html
> 
> Probably you easily find something in English, e.g. this (I have not
> read it though):
> https://www.linux.com/learn/tutorials/317972-weekend-project-one-time-passwords-for-extra-linux-security
Hi,
read both. The summary about OTP:

"Setup

You generate passwords by running otpw-gen at the command line. The program asks you to select a "prefix password" -- the reusable secret portion that you memorize -- then prints out an ASCII-formatted list of numbered passwords to stdout. By default, otpw-gen creates 60 lines' worth of passwords; this is designed to fit nicely onto a sheet of A4 paper. You can specify a different number of lines and columns by adding the -h and -w switches at the command line; how many fits on a page could take some trial and error. There is a maximum of 1000 passwords at a time, though, because OTPW uses three-digit numbers in its list.

The passwords on the list are generated using random entropy from the system -- gathered from the clock, system file access times, and other unpredictable sources. In the list, each password has its own number, followed by the eight-character password itself. Each is actually a base64-encoding of a binary string, but to avoid ambiguity, the difficult-to-read characters "0" (zero), "1" (one), and "l" (lowercase L) are replaced by punctuation.  For example:

001 ase4 5=XK
002 m8Hm G:fQ
003 rF6z iDhC
...
042 Sf9r 3NgY
...

The idea is that you should print this list out on paper -- immediately -- and never, ever store it anywhere on the computer. Carry with you at all times, never let it leave your sight, and you will be in good shape.

When the list is generated, otpw-gen also creates a file called .otpw in the user's home directory; each line inside it lists a password number followed by the RIPEMD-160 hash of the actual password and the user's secret (never stored or printed) password. That makes the .otpw file crack-proof on its own, and because it is stored in the user's home directory, no system-wide state is required. Whenever a password is used, the OTPW system blanks out the appropriate line in ~/.otpw"

This answers some of my questions  and shows that there is some kind
of standard:

1) file to store the OTPs:  ~/.otpw
2) it seems to be a PAM module and busybox supports it:
    CONFIG_PAM   Use PAM in login(1) instead of direct access to password
                           database.
    So I think it would be best to try to use the PAM module with busybox.

The implementation explained in the article seems to differ a little from
what you propose but the "sheet of paper" weak point still remains
and in a society where video surveillance cameras are looking at you
from everywhere unfolding a sheet of paper with 1000 OTPs
is as worse as having a keylogger on the machine.
In the german news of the last days there was a story just
about video cameras in a supermarket zooming at the female custormers
but well placed also to zoom at customers inputting their credit card 
pins.

If I understood  correctly what you propose:

1) you don't use a list but the OTP is generated each time on the fly?
2) shared secret on server and client (or memorized by human or on the usual
    sheet of paper. Are they the same or a private/public key pair?)
3) time string from synchronized server/client to delimit the validity of OTP
4) (one time?) PIN sent through different way e.g. SMS (could still be peaked
    at tough, but if OTPIN it doen't matter)
5) creating OTP using timestring+PIN+sharedsecret

The name sharedsecret is funny for me: how could be something
that is shared be secret at the same time ;-) .
In the end I vote for implementing it as a PAM module as this is the less
invasive solution and probably also easier to maintain.

Just my two cents.
Ciao,
Tito