Password security on the web is a troublesome issue. We have hundreds of web accounts, some of them with access to all our money, and it must be secure, not just from phishers and people snooping the web line, but from viruses and keyloggers that can take over our own computers or roaming computers we want to use to access password protected web sites.

The only way to be secure if you can't trust the very computer you're logging in from is to have a security dongle which contains the real secrets and does the logon negotiation, plus confirmation of any big actions like large cash transfers. People have carried login dongles for years, typically which have a screen with a constantly changing number (securid) or which can do challenge/response.

Most of the world is moving now to having a smart phone, in particular one with a standardized data protocol such as bluetooth. I propose a protocol so that web sites can, given a limited channel to the phone, do a login dialog with the phone. The computer would just be a conduit for the data, it would not matter if it were compromised, as the passwords would not be sent in the clear.

More thoughts... The phone itself would also require a PIN from the owner, at least once a day, and also when authorizing transactions over a certain amount. Ideally a fairly long PIN, perhaps one as long as a phone number (which people can remember) but not a guessable phone number of course.

One's home computer would have a bluetooth interface, so that any time you were at the computer with the phone nearby, you could quickly login to sites, with no risk of snooping or phishing. If at a computer with no bluetooth interface, there are a couple of options. First, the site could display a challenge number you would enter on the screen, and then the phone would display a response number you could type in. Or the phone could just display a number based on the time, and the site could confirm the number matches what it should be based on a shared secret in the phone and at the site. (Ie. similar to SecurID tags.)

Better, the site could, after you enter your userid, communicate with the phone over the cellular network, for example via SMS or equivalent. The phone, after confirming it is in your posession (with PIN number every so often) could respond, again with SMS or equivalent. I say "or equivalent" because the carriers would probably insist on getting in on the game, and want to charge a monthly fee to do this.

All of this could also be done by a PDA or other small device, even a small dongle with tiny screen and keyboard, but since everybody's carrying a phone and it has the smarts for this, the phone makes most sense -- and it has this ability to do the auth over the cell network.

If the computer you are using is compromised, however, it could take over your session after you login, and do whatever it wanted, such as transfer money in a hidden session. As such, sites that can transfer money or do other high security operations would want to re-confirm them on the phone. Your phone would beep and say, "Confirm transfer of $2,000?" and you would press a key to confirm this. For really high amounts you would need to re-enter the PIN, not just press a key. This would get annoying if you had to use the keyboard challenge/response, so the cell network transfer makes sense here.

All this could mostly be built today, if you have a phone that takes downloadable applications (J2ME, Brew, Symbian etc.) which can send and receive data packets or SMS. Considering how much value we are tying to our web passwords, it would be worth a small fee to cellular carriers.

In addition, the secrets in the phone could be backed up in another database, protected by a more powerful passphrase, so if you lost your phone you could transfer the secrets to a new one.

Since bluetooth has a good range, and you would not want to grant everybody within 30' the ability to login or do transactions as you, there would need to be some input from you on each secure transaction, such as the phone beeping and displaying lower-risk transactions, and needing a confirmation press for medium risk ones. (High-risk demand the PIN.) One could also require a password on the host computer, though if it has a keylogger, somebody could get that and then sit next to you and use it. The phone would know the identity of the host computer it connected to to perform transactions (with bluetooth) and get very excited if it simultaneously was asked to talk to more than one, though since bluetooth IDs can be faked this could still be defeated, so a basic key-press confirmation for all risky authentications is probably needed on both bluetooth and cellular network dialogs.

Since common use of this would be to place the cell phone on the desk next to the keyboard to hit confirm keys, there must be a defence against theives snatching the cell phone and running elsewhere (particularly with authorization over the cell carrier.) Fortunately most phones today can sense when they have moved, and could re-demand the PIN. This precludes use in vehicles, however (or if you disable it temporarily in vehicles creates a risk of snatch on the train.) Of course the PIN number would be an integral part of the authentication process, it would not be extractable from the phone. Ideally all the keys in the phone would be in tamper-resistent chips eventually.

We must also be on the lookout for cell phone viruses. They seem less likely than PC ones, though not impossible. However, you don't have to worry about the risk of using somebody else's PC as you do in an internet cafe situation.

The device can also have a USB plug or cable available (more common for a dongle, but also found in phones) so that you physically plug it in, though only when at home or office. Then you don't need to do the confirmation process as there is no risk of nearby radio hijack.