OTP feature for /bin/login

[Guylhem]

Hello

On Tue, May 8, 2012 at 1:56 AM, Tito <farmatito at tiscali.it> wrote:
> So if you plan to allow users to change their secret
> this file would be readable by all, better store the secret
> in the users directory than, there it is somewhat protected
> and you don't have all the trouble about concurrent
> secret changing attempts.

Possible- yet a useland tool to change /etc/otp would also be possible
- just like the passwd command.

I don't know what is the best option, even if would tend say a
/etc/otp file would be better for user without a homedir or which
should not be able to read their own pinless one-time passwords (ex:
FTP user)

Maybe both ~/.optw and /etc/otp?

I would tend to say none since I'm not sure that it will be very
usefull for many people.

It can still be added later if there is a strong demand.

> You guess the time if the server is syncronized with some ntp
> service, you can peek at the shared secret if you have another
> account on the server or some malicious software on the client

How exactly do you peek at the secret if the file is root readable only?

By malicious you must mean 0wn3d. That's quite different. You can't be
protected from a compromised device. Ex:  If I 0wn your phone and you
use key-based ssh without a password, game over. If you use key-based
ssh+ a password, I'll just install a keylogger and wait.

> you snoop the pin e.g. man in the middle attack if sent by http

If someone is is 0wning your cellphone or doing a MITM and accessing
root-only file on your servers, you may have other worries than
protecting your login password with OTP.

Ex: If I was this person, I could also simply grab the password
hashes, try them with a rainbow table and be done with it.

> or brute force it, 4-5 digits are max 99999 (if only numbers).

Sure, only a million - that's the weak point of using 6 digits only,
and even worse - it could be further reduced by the possible time
window which makes multiple challenge response acceptable -say 10 for
a 1 minute time-window.

But the challenge to be given is 6 hex chars extract of the md5, and
md5 strongly increases entropy - if you go that route, guessing the
shared secret or the pin won't be necessary : it will not help due to
md5 characteristics, and 16^6 is quite a lot to brute force.

Even if you reduce that by the very generous time window allowing 10
valid combination (from 10 valid pins) at once, considering that your
bruteforce has to succeed *within* the time window or will have to be
restarted from scratch, it is still (16^6)/10 ie 1.6 millions password
to be tested, with a timeframe of 1 minute- and if you have no match,
then you have to try again.

A simple wait of 2 seconds between login attemps seems enough to turn
the risk to negligible, along with a connection limit per IP.

If you are still worried about potential abuses, simply make the
challenge twice as long (you'll have to tweak your MOTP client) and
that'll be 281'474'976'710'656 or 28.1 trillions password to be tested
every minute. That will not be called brute forcing but DDOS'ing :-)

Personally, I think I'm safe until md5 is compromised in a way than
knowing a part of md5'ed string will allow one to infer what the final
md5 looks like, thus reducing the number of possible matches.

To the best of my knowledge, this doesn't exist at the moment, even if
collisions are easy to make. Of course, it may happen some day. But
until exploits can be revealed (and considering the widespread use of
MD5, not only for OTP, that'll be widely publicized) there is no need
to worry.


Guylhem