OTP feature for /bin/login

Tito farmatito at tiscali.it
Tue May 8 12:38:38 UTC 2012


On Tuesday 08 May 2012 08:37:05 you wrote:
> 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?

If you will allow users to change their secrets then the file
must be rw like /etc/passwd, unless you use su/sudo
or a setuid binary (or use the users' homedir).

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

As your are talking about a not so secure connection
from a pc that you do not own with let's say windows
(e.g. from an internet cafè) to be on the safe side
you have to assume the machine is owned.
I don't believe you would use your credit card
from said machine.

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

As the history has shown there were apps for android
looking at user data and for example the community
repositories for the N900 are not very much audited
and the package installer runs as root.
 
> 
> 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.

Ok, so we are safe from bruteforce, now to make things viable
we still need a multiplatform motpgen fro the client at least linux,
windows, mac, android or maybe java or browser based?
All added to busybox ;-) ?
It would also be good to move the otp stuff out of correct
password to his own file and add only ifdeffed hooks there
in the relevant places, this would improve readability and
mantainability.

Ciao,
Tito


> 
> Guylhem
> 


More information about the busybox mailing list