begin quoting David Brown as of Fri, Aug 29, 2008 at 06:08:44PM -0700: > On Fri, Aug 29, 2008 at 05:41:33PM -0700, SJS wrote: > > >Forget all that crap about having a filesystem and cutting-and-pasting. > > > >You could have this emit, without error, a sizable chunk of data > >encrypted with a private key. A large nonce, source IP address, > >etc. etc., plus a counter and/or timestamp... > > > >I never even thought about having the device pretend it's a computer. > >(Probably because I have some machines that Will Not Work With Multiple > >Mice Or Keyboards.) > > I wonder how likely kiosks and library-type machines would be to > allowing something plugged in that acted like a USB keyboard, and upon > pressing a button would send some kind of authentication data.
If they have an open USB port -- which is not always likely -- they probably don't take any special measure to prohibit such things. > >I'm a bit leery about their "one time passcode" phrasing. Still... cool. > > In its simplest sense, it could just mean that each password is only > valid once. Yup. "Single-use passcode" would be more accurate, but wouldn't invoke the visions of the "provably secure one-time-pad/one-time-password" that is a key bit of mummery from the more unsavory sort of vendors. > I'm familiar with the S/Key system. One disadvantage to it is that > for a given authentication, you have to give it a specific password > off of the list. The passwords are each password on the list is > basically the hash result of all of the following passwords. So, s/following/preceding/ ? > until you enter the next password, the host doesn't actually know what > the next password is. If you're carrying a list around with you, a selection of generated one-time-passwords would seem to be just as effective. Hm... except a successful S/Key intrusion would be detected by you when you tried (and failed) to log in with an "old" password. That's a nice feature, really. > I'm actualy not real sure why more people don't use S/Key as a second > factor. As a single authentication, it has problems, but when > combined with a real secret, it at least seems to have similar > security to a fob. An obvious weakness is that the list can be copied > and returned to the user. There are implementations for cellphones > and such. Performing the computation on a cell phone would help with the "copy the list" problem. And cell phones are getting smarter -- so the keyfob thing might just turn into a program you run on your cell phone. -- Surely there's an iPhone app for this already. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
