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.
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. 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.
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). Some of the suggested solutions rely on third parties so minimizing these dependencies when possible is probably a good idea. What happens if Oracle succeeds and Android is hosed in a few years (highly unlikely but possible)? What happens when YubiCo dissolves? What happens when Google pulls support for their OTP system (again unlikely, but possible)? What happens when solution x is compromised like the recent RSA breaches?
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.
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.
--
Take care!
-Adam
On Mon, 17 Oct 2011 21:50:41 -0400 Adam M Dutko adutko@oktud.com 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
infrastructure@lists.fedoraproject.org
-
Adam M Dutko -
Kevin Fenzi