On Mon, 17 Oct 2011 21:50:41 -0400 Adam M Dutko <adutko@xxxxxxxxx> wrote: > > > These problems we are discussing are difficult. The somewhat > obvious part is that I think in the end no single solution will be the > best. Yeah, security is usually tradeoffs. ;) > Using a phone based solution is scary. I cannot understand why > one would want to base their security on a transient and expensive > device. Such devices are easily lost, easily damaged, and as crackers > are discovering, breakable, just like any other software based system. Sure, but also they are easily replaced and (almost) everyone has them. > These same reasons are why I believe "fobs," "tokens" or whatever you > want to call them, are also not an optimal solution. However, unlike > phones, they are inexpensive, disabled with minimal pain/inconvenience > as compared to wiping a phone, and although potential targets for > theft, not as big of a target as a much more expensive devices like > phones. Likely fob thieves would know what they are doing (which is > scary in itself), but they are most likely less numerous than > would-be phone thieves. Well, they are less expensive, but they are more pain. If you lost/broke your phone you could likely go get a new one down at your local telco store. If you lost/broke you yubikey, you would have to order a new one, wait for shipping. > The primary concerns I have about any system relate to how > easy is to "rebase" aspects of the solution when different pieces are > compromised; how expensive is the solution in terms of total cost > expressed in dollars (new phone or token), time (administrative, > transit, etc.) and resources (recreating the environment from > scratch). Sure. Tradeoffs. > Some of the suggested solutions rely on third parties so > minimizing these dependencies when possible is probably a good idea. Yes, this should be as close to 0 as we can make it. ;) > What happens if Oracle succeeds and Android is hosed in a few years > (highly unlikely but possible)? iOS has clients. ;) Blackberry even has OTP clients. > What happens when YubiCo dissolves? This would be a pain hardware wise. Until/unless someone started making clone hardware. Software wise it doesn't matter, it's all Open source. > What happens when Google pulls support for their OTP system (again > unlikely, but possible)? Google authenticator is open source. We have the code and always will. >What happens when solution x is compromised > like the recent RSA breaches? Adjust/mitigate. ;) > We obviously cannot predict the future, so I guess I'm > wondering what matters the most to those who will actively be using > the solution? Like Seth, and other mention, what groups are we > covering? and what can we require of each of those groups? Is it fair > to say if you want to be an admin you have to have the dough to pay > for a phone and pay for a service plan? I don't know, but it will > shape the demographic in certain, and possibly, unfortunate ways. Right. We need to decide this. I do think requiring a phone may be too difficult for some groups. > I also had a discussion > with a friend who does a lot of reverse engineering. He mentioned the > YubiKey hardware is trivial and that it would probably be more > difficult to reverse engineer the algorithms involved in generating > the OTP. yeah, someone could make clone yubikeys... All good info. :) kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
