« December »
Locations of visitors to this page

Powered by blojsom

Radovan Semančík's Weblog

Thursday, 4 December 2008
« Pragmatic Software Architecture: For the First Time | Main | SOA vs WOA »

Ben Laurie is discussing the nature of passwords. He claims:

If your password is unphishable, then it is obviously the case that it can be the same everywhere. Or it wouldn’t be unphishable. The only reason you need a password for each site is because we’re too lame to fix the real problem. Passwords scale just fine. If it wasn’t for those pesky users (that we trained to do the wrong thing), that is.

I can see where Ben is leading us. Using a device that can take password and convert it to some form of more secure authenticator or protocol exchange. Well, that could work. But there's a catch, as always.

The password itself may be very difficult to phish, because it is never shared with anything but the secure device (under Ben's password utopia). However, the device communicates with the rest of the world using some kind of "secure" protocol. This protocol interaction may be vulnerable to man-in-the-middle attacks. And it surely will be, unless two mechanisms are in place:

  • The device must verify the identity of the authenticator party, the web site that accepts authentication. Think about the lesson of Needham-Schroeder and compare that with Otway-Rees. If this is not done, following attack is possible: The attacker Mallory can just pretend he is authenticating user for user's usual daily dose of gossip (read: social site). But the attacker will get the authentication challenge from user's Internet banking application feed that to user's secure device and lure user to provide valid authenticator for Internet banking. The user will think that he is entering password to read the gossips, while he in fact will be authorizing transfer of his savings to support Mallory's Luxury Vacation Charity Fund.
  • The device must bind the authentication to the actual communication. Think about how certificates are used to generate the session keys in SSL/TLS. If this is not done, then it is trivial for Mallory to just wait while user executes proper authentication and then hijack his (authenticated) connection. The user may not even notice, as Mallory may pretend network failure. Or Mallory can let user do whatever he does and wait for a logout command. He will silently discard the logout, but pretending it happened. When the user leaves, Mallory can easily afford to buy a new house in Mediterranean.

Unless these attacks are prevented, the whole system will still be inherently vulnerable to man-in-the-middle attacks. No kind of secure device can solve all the issues (although it can improve the situation a bit).

I see the solution like this: User is authenticating to his communication device (computer, mobile phone) with any appropriate combination of I know / I have / I am. When the device is persuaded about the user's identity, it will relay that authentication to other systems. That may be strong authentication, not necessarily based on passwords. This forms a chain of authentication that can have quite a lot of links. However, to get a secure system, use must inevitably believe that the device that displays information for him (workstation, notebook, mobile phone) is operating as expected. Failing that all attempts to secure anything are useless. The bad news is that we are far, far away from that.

Posted by semancik at 11:11 AM in security

Add your comment:
(not displayed)
Generate another code

Please enter the code as seen in the image above to post your comment.
Your comments will be submitted for approval by blog owner to avoid comment spam. It will not appear immediately. Also please be sure to fill out all mandatory fields (marked by asterisk). This ... ehm ... imperfect software does not have any error indication for missing input fields.


[Trackback URL for this entry]