Hello On Tue, May 8, 2012 at 1:56 AM, Tito <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
