Hello On Sun, May 6, 2012 at 4:02 AM, Tito <[email protected]> wrote: > The implementation explained in the article seems to differ a little from > what you propose but the "sheet of paper" weak point still remains
No - I do not pregenerate any kind of list of password. The shared secret is stored in the MOTP application of the cellphone and never leaves it. It is not displayed on the screen when calculating the challenge. > If I understood correctly what you propose: > 1) you don't use a list but the OTP is generated each time on the fly? yes > 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?) no they are identical > 3) time string from synchronized server/client to delimit the validity of OTP yes > 4) (one time?) PIN sent through different way e.g. SMS (could still be peaked > at tough, but if OTPIN it doen't matter) yes > 5) creating OTP using timestring+PIN+sharedsecret yes Just like google 2-way auth. > 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. IMHO a PAM module is overtly complicated. I noticed correct_password did also handle shadow password verification. Considering OTP just adds a little bit to the file size (and the code is not optimized yet - it could certainly be improved) it seems like the most sensible option to me. The basic function of OTP is to provide an alternative to the password when it should not be exposed. So I suggest the function goes in correct_password as a compile time option. In the worst case it can handle a /etc/otpshared file if there is strong demand to have a different OTP per user, or even per day (there isn't at the moment). Guylhem _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
