Article - A Solution to Phishing

Michael Silk ( version: 1.0.0, released on: 23rd of November, 2004 )

Introduction

For those who don't know what Phishing is, read this (it isn't very long) ...

Solution

Now that you are up to speed, we can discuss a proposed solution. The idea is to use a "one-time password-based" system. As we know, Phishing works by receiving your username and password. However, what if your password is only valid once and is then reset?

At first, this will seem silly as then the user will need to remember thousands of passwords, and will have to write them down each time ... and anyway, how does this prevent Phishing?

Well, the implementation I had in mind was one such as:

1) User navigates to: http://test-bank/ Eg:

Hi, please enter your username: [ jones ]

2) Upon receipt of username "test-bank" emails Jones his password. The email should contain the password linked to a page that facilitates login for Jones specifically.

Eg:

Hi jones,

We received your login request at 12:24 PM

today (the 23rd of November, 2004). Please

paste the following link into your browser

(or simply click it) to login.





https://test-bank/login/?id=3451&password=...





Sincerely,

Test-Bank Team.

This password should also expire after a small timeout ... say 10 or 15 minutes. The login website and the email can both advise of this.

3) Jones clicks the link and his password is immediately reset. Jones can continue to use the system until he exits or it times out.

... and there we have it.

Advantages:

1) The user (Jones) doesn't have to remember a password for your site. All he has to do is remember his username. And generally, the username can simply be an email address. Which he should already remember, or at least have written on his business card :)

2) Phishing is impossible because Jones does not know his password until he requests login. A Phished site needs to ask the user for his password. Jones can't provide that information until he receives the email and the email links to the correct site anyway, so Jones never has the opportunity to put the password anywhere else.

3) The password expires either immediately upon login, or within 15 minutes of it's issue. Hence, even in the case the password is tracked and observed (via transfer to website as it will be non-ssl), it will be of no use to the attacker.

4) Quality of passwords is up to the site and they can be 256-bit or another number you feel comfortable with. Because the user doesn't have to remember them you are free to make them as complicated as you like. I'd recommend you use a good quality random number generator, perhaps even one as described and shown in "Really random numbers".

Disadvantages:

1) Email sent to jones will probably not be encrypted. An email system that supports PKI-based emails could help here. However we can note that this isn't a major issue if the email is acted on by the user rather quickly. Even if the email is acted on slowly the bank can inform the user that their password has already been used (not expired) and that someone else may have accessed the account.

2) Substantially different user experience. The experience users receive at a website that implements this will be quite different from the normal experience. However, with a little bit of education, users can be coaxed (maybe) into realising that this solution is better for them.

3) Email access required at time of login. This isn't a major issue, but might be for those people that enter their companies email but cannot access it (or don't know how) from home. This, again, is an education issue that the site must raise with the user at the time of registration. This shouldn't be particularly difficult to overcome.

Conclusion

This solution seems pretty good, if you can live with the different login system. Let me know your thoughts on it by sending an email to: michaelsilk@gmail.com.

Implementation Notes

It is critical that the password generation is not predictable. It should not be based on the username, nor should it increment per reset.

It is also critical that you expire an unused password after a relatively short time-period so that the user cannot leave or place their password in an unsecured area where it can be observed and used. (As mentioned, the transfer of the email is not secure so it can be observed by others in the same network as the target).

It is not required that you keep a list of previously-generated passwords as the randomness of your generation should be such that the likelihood of this occuring is not worth an attacker trying this vector.

Please also see: http://michaelsilk.blogspot.com/2004/11/followup-on-solution-to-phishing.html

Also the following posts on the SecurityFocus mailing lists cover most concerns and their discussions:

http://www.securityfocus.com/archive/107/382371

http://www.securityfocus.com/archive/107/382379

http://www.securityfocus.com/archive/107/382508

http://www.securityfocus.com/archive/107/382563

http://www.securityfocus.com/archive/107/382709