IPT is separate from the operating system and works using special digitally signed applets. Users can associate a particular PC with a particular service account (the service must support IPT). The user will then need to generate a one-time password to login to the account. It’s difficult to tell from the information given, but it appears that IPT would use an operating system utility to display the one-time password to the user.
IPT should produce significant security improvements as it stops people from choosing bad passwords, and it makes it harder to steal or phish passwords. As long as the registration process is sufficiently strong, IPT should be attractive to enterprise customers.
It is not possible to judge from the information currently available how open IPT is. Does it comply with the OATH standards for one-time passwords? Can it be used in non-Intel devices like iPhones? If it can’t, I don’t see how it will ever escape the enterprise ghetto.
IPT will probably not be able to address the problem of malicious code on the user’s PC. It will still be possible (albeit decidedly non-trivial) to write malicious code to call the IPT API or intercept a call or response; and it will be possible for malicious code to take over the user’s session once authenticated. Man-in-the-middle attacks (such as using a password generated for one site on a different site) may also be possible, depending upon the design of the system.
IPT was announced almost simultaneously with a scheme from Google to provide 2-factor authentication based on SMS messages sent via a user’s phone. Google’s approach should be as secure as Intel’s, it should be cheaper, and it should be more open too.
It’s hard to see any overwhelming advantage to the Intel approach from the user’s point of view. But from the IT department’s point of view, it should make it easier for them to exclude users from bringing their own (i.e. non-Intel) devices into work. And that may be the real point of the mechanism.
John Arnold, Jericho Forum Board Member