5 ms·

The problem I see with this solution is that it would require a plugin to be installed on your browser in order for the browser to have access to the fob. This

by cjfont 15y ago

The problem I see with this solution is that it would require a plugin to be installed on your browser in order for the browser to have access to the fob. This alone is enough to discourage a lot of people from using it. Also, you wouldn't be able to log into a public terminal.

pyre 15y ago
He seems to be advocating that the solution is built into all levels of the stack: OS drivers, native browser support (i.e. no plugins), etc.
- shoota 15y ago
  Using a TPM to ensure that only trusted software is accessing the fob as well. We're still a little ways off from a completely cryptographically secure software stack.
ChuckMcM 15y ago
In the ideal world, the spec would be open and anyone could implement it in their service (be it a browser or other). For most operating systems we're talking about something that looks like a device connected over a serial port. The Android service is pretty straight forward and I've played a bit with ideas on an old G1 which had a serial port hidden in the USB port, not sure about iOS. Computers like laptops etc its very straight forward (for both wireless and wired solutions). "Also, you wouldn't be able to log into a public terminal." Actually depending on capability (no pun intended) I could easily see 'read' access being usable without the key but recognize the issue there. The real 'issue' if you will is universal appeal/buy-in which is to say if anyone can use it then you will get some early adopters who will provide support as a differentiating factor and that can drive adoption into more slowly changing markets. Because it has to be everywhere to be effective it won't be a big money maker (this is where a lot of VCs stop listening :-) basically the barrier to implementing it has to be 0 and the value to the implementor has to be non-zero. Given how thinly marginallize 'security' fixes are, this margin won't leave anything for the manufacturer in terms of on going revenue so the key itself has to define the value for the company. (I've actually thought a lot about this :-) So to your point, for early adopters the experience would be to get a 'key' and to install a plug-in and then enabled sites and services would be secured. Pretty easy sell to an enterprise if their only cost is the 'fob cost' and there isn't some giant consulting revenue stream attached to it. For big companies it has to be completely implementable (once the key infrastructure is set up) in a way that is custom (and probably private) that enterprise. That gives their IT folks confidence and it makes the risk low. For more general engagements like PayPal or Facebook its a bit different. On things that are appifyable (if that makes sense) there is a potential for differentiation (look at how the World of Warcraft Authenticator stuff was worth it for them to implement). The key for me is that the existing way of doing things is under attack and it will eventually succumb, when it does there is a tremendous opportunity there.
- joebadmo 15y ago
  This sounds like a lot of necessary infrastructure. Widespread smartphone adoption seems more likely to me.

by cjfont 15y ago

pyre 15y ago

He seems to be advocating that the solution is built into all levels of the stack: OS drivers, native browser support (i.e. no plugins), etc.

shoota 15y ago
Using a TPM to ensure that only trusted software is accessing the fob as well. We're still a little ways off from a completely cryptographically secure software stack.

ChuckMcM 15y ago

In the ideal world, the spec would be open and anyone could implement it in their service (be it a browser or other). For most operating systems we're talking about something that looks like a device connected over a serial port. The Android service is pretty straight forward and I've played a bit with ideas on an old G1 which had a serial port hidden in the USB port, not sure about iOS. Computers like laptops etc its very straight forward (for both wireless and wired solutions). "Also, you wouldn't be able to log into a public terminal." Actually depending on capability (no pun intended) I could easily see 'read' access being usable without the key but recognize the issue there. The real 'issue' if you will is universal appeal/buy-in which is to say if anyone can use it then you will get some early adopters who will provide support as a differentiating factor and that can drive adoption into more slowly changing markets. Because it has to be everywhere to be effective it won't be a big money maker (this is where a lot of VCs stop listening :-) basically the barrier to implementing it has to be 0 and the value to the implementor has to be non-zero. Given how thinly marginallize 'security' fixes are, this margin won't leave anything for the manufacturer in terms of on going revenue so the key itself has to define the value for the company. (I've actually thought a lot about this :-) So to your point, for early adopters the experience would be to get a 'key' and to install a plug-in and then enabled sites and services would be secured. Pretty easy sell to an enterprise if their only cost is the 'fob cost' and there isn't some giant consulting revenue stream attached to it. For big companies it has to be completely implementable (once the key infrastructure is set up) in a way that is custom (and probably private) that enterprise. That gives their IT folks confidence and it makes the risk low. For more general engagements like PayPal or Facebook its a bit different. On things that are appifyable (if that makes sense) there is a potential for differentiation (look at how the World of Warcraft Authenticator stuff was worth it for them to implement). The key for me is that the existing way of doing things is under attack and it will eventually succumb, when it does there is a tremendous opportunity there.

joebadmo 15y ago
This sounds like a lot of necessary infrastructure. Widespread smartphone adoption seems more likely to me.