begin quoting Andrew Lentvorski as of Fri, Aug 29, 2008 at 02:33:07AM -0700: > SJS wrote: > >begin quoting Andrew Lentvorski as of Fri, Aug 29, 2008 at 01:42:45AM > >-0700: > >>I'm thinking about how you reuse the fob. You only want one of these > >>things on your keychain, after all. > > > >Ah! > > > >You're thinking of having one fob and, say, five different server > >that you might want to log into, but if one of the five gets cracked, > >you don't have to worry about the other four? > > > >Would you be adverse to having an input of some sort? > > Yeah, I would be adverse to that. Don't make me think.
So, one fob, N independent servers, no shared secrets, no input, and a short token. > Using a second factor is already annoying enough. I'm not terribly convinced that the "second factor" is doing much good -- you *still* can't loan your fob out without telling people your username and stem, so it's effectively just part of your username. > Also, please remember that I'm willing to burn *LOTS* of the server's > CPU/time/power to make this work. Given that you log in once in a great > while, even if the server has to do lots of computation, I don't really > care since it only has to do it *once* on login to authenticate the fob. Yes, but the problem is we don't want Eve or Mallory to be able to burn a lot of CPU time to do the same thing. > So, I'm willing to burn almost arbitrary server computation/time or > original configuration computation/time as long as it simplifies what > the fob has to do. ie. Having a nice big computer compute the > public/private pair and then just burn the relatively small private key > onto the fob is acceptable even if the public key has to be *gigantic* > and takes forever to create. The problem is the modulus -- it'll be friggin' huge. > The goal is to offload as much computation away from the 8051 as possible. My current line of thinking is to abandon the "token must be small" constraint. We have a USB device, yes? So make the widget look like a thumbdrive, with a readonly filesystem (or virtual CD) that has just one file. The contents of that file are the public-key encrypted timestamp (and nonce, perhaps) updated once a minute or so. When not plugged in, all the device has to do is keep track of the time. When plugged in, there's (hopefully) power, and the device can do the encryption, hex-encode (or uuencode, or base64) it, and store that in memory. To use, you plug in the fob, wait for the little LED to turn green, then open the file and cut-and-paste it into the waiting prompt. The server hex-decodes the string, then uses the public key to decrypt it, discards a nonce if any, and checks the time. If it's within some delta of "now", all is well. So, how does it break? Well, someone sniffing the wire could use the token to hit *any* of the N servers you're using this device for. So you encrypt the whole session... now you're forcing the attacker to mount a MiM attack, or to compromise your local machine. Y'know, the standard fallbacks. :) Best way to defeat *that* is to ensure you can trust the local machine; say, by bringing your laptop. But if you do that, ssh already does the job, and no keyfob approach is necessary. I really do think the 1 fob + N untrusted servers + no input set of constraints can stand. -- How about one virtual file for each server? Encrypt the server name too! Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
