Followup on "Solution to Phishing"

Just a quick note..

I left a few disadvantages out :)

a) Username/email disclosure.

It would be appropriate, from a user's point of view, for them to get a message confirming whether the email address or username that they typed in was correct or not. If they were to receive no such message they may sit back and wait for the email to come and never receive it hence getting quite annoyed :)


b) Security of the system is "pushed off" onto the security of your email box.

Because your password only ever arrives by email (not phone, or physical letter, as some banks do) you (the user) really need to make sure you have secure access to your email at the point you request a login. If you don't, someone else will get access because no other information is required other then the email click.

A solution to this becomes obvious - ask additional questions once clicking the email. This could work well, but, of course, isn't perfect as suddenly a Phisher could gain this information by providing the link, with a fake password, retrieving the additional information from you and then saying "Oops, password timed out".

We can note, however, that in this situation the phisher would be required to also have access to your email account; which the typical Phisher doesn't have (but a Phisher from your office might ...).

Hence, the ultimate implementation of this solution is to encrypt the email public/private style and you initiate the decryption via a program external to your email program (i.e. smart card, usb device etc). This would prevent email interception.

PS: Your email provider obviously can't implement this solution :)

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

Article - Really random numbers

Michael Silk ( version: 1.0.2, released on: 16th of August, 2004 )

Random numbers are used in almost all encryption algorithms to generate encryption keys and random pad data. Unfortunately, the random number generators (RNG's) provided by most programming SDK's do not provide adequate security.

Goal
To provide a system to obtain "real" random numbers and use them for our security purposes.

Background
Random number generators provided by your typical programming SDK will use the current time as a "seed" to an algorithm which will produce random-looking results. The combination of a seed plus an algorithm to produce such results is known as a pseudorandom number generator (PRNG).

The downside to these generators is the seed. In this case, time. The time is a very predictable entity, and hence not appropriate for any security application. Recognising the predictability of the time, these PRNG's have been improved and modified to gather seed data from a variety of sources. These mulit-source gathering PRNG's are known as "Secure" RNG's due to the proposed unpredictability of their inputs.

All the input to these generators, however, comes from your computer. Due to this, these algorithms can become predictable, depending on the environment.

The Solution
In response to this concern, websites have been created that provide real random numbers on request. By real I mean numbers generated by some (as yet) unpredictable method. The sites I will discuss in this article are:

• Random.org,
• Quantum Random Numbers, and
• HotBits

All of these sites contain in-depth descriptions on how their particular bytes are generated so I will not repeat that information here. I do suggest, however, that before you use the classes provided in this article you take a look at each of the sites and see for yourself the methods they use.

Note: All code provided in this article is in Java and developed under version "1.4.2_03".

Both "Random.org" and "HotBits" provide bytes over HTTP, however "Quantum Random Numbers" are available only through FTP (and the author of the site has provided an API to access to perform the requests). To encapsulate this I created an interface, DistributedRandom and one main super-class called HTTPDistributedRandom.

I have implemented subclasses of these and packaged them up as a 'Distributed Random' library; you can download it here: Distributed Random Pack.zip. Note that the pack also includes the library provided by "Quantum Random Numbers" called "libqrng-1[1].1beta.zip".

I have left the classes relatively bare; they only contain methods to get the bytes and do not do any buffering. It would be appropriate to implement a buffering strategy within, or around, these classes depending on your usage patterns. Please also note that there are some important notes in the source code (prefixed by "note:") so please read them before using them.

Before we plan on using the numbers gathered from each source for security purposes, we need to identify some risks associated with this approach:

• The source may suffer some sort of failure and no longer produce random numbers
• The source may be logging the numbers it generates, and to whom
• The source may be compromised and sending specially crafted numbers

In response to these risks on an individual source I created a class called ReallyRandom. This class attempts to gather a request for bytes from the three listed sources (in fact, it takes an array of DistributedRandom's so it can be any number of distributed sources) and then combines them. The combination method used is a simple XOR of each byte from each source.

The XOR operation gives us a byte array whose contents cannot be known to any of the sources unless they have the bytes generated from other sources. This means that if one source (or two, or three) are logging the bytes that they generate they still cannot discover our resulting byte array. Of course, if all the sites are in cahoots with each other, then we may be in trouble :)

While this combination protects us from the possibly-evil purposes of the sources, it also protects against one source occasionally distributing "bad" random numbers. If a source, for one reason or another, happens to have some form of failure the other sources will compensate.

That comment leads to the question of: How do you identify "bad" random numbers?. Well, luckily there is a nice tool (with full source) provided by the author of "HotBits". The program is called "ent" and you can get it here: http://www.fourmilab.ch/random.

Depending on your environment it may be appropriate to pass the numbers that you generate through the tool (or your own implementation of the algorithms) to see if the results you are getting are truly random. If a certain result is not random, it could indicate a substantial failure in the systems and you could discard that set of bytes and try again or stop processing completely, or whatever is appropriate for your situation.

Problems
Although it is a nice solution to have your random bytes delivered via the these sites there are problems. Most obvious is that none of the sites (currently) provide access to the bytes via SSL. Hence, if your attack model contains an adversary from within your network who would be able to view the bytes as they come in then this solution is not for you :)

Another risk with a local attacker is that of DNS lookup. If your local DNS server was modified to point the various domain names to "evilhq"'s IP address then you are in trouble again.

Conclusion
We have successfully found a method of gathering up real random numbers in preference to the pseudorandoms provided by most of our programming SDK's.

However we have realised that this may not be an acceptable solution if we are concerned about a local attacker.

In the end it is up to you to decide if a distributed source of randoms is an appropriate solution and if the risks outlined apply to your situation; but if you are prepared to accept the risks then these free services may be the perfect solution.

Please note, however that these sites (at least Random.org and HotBits) do not provide unlimited bytes. HotBits imposes a 24-hour limit of an undisclosed number of bytes (discussion of this is in the source code) while Random.org requests we check a buffer to see if it is greater than 20% full before we perform a request. So please, don't overload these free services with requests for bytes.

Feedback? Contact me here.

Welcome Message

Hello, and welcome. This site is intended as a publishing spot for security-based articles written by me: Michael Silk.

This is a temporary site and you should not come back and check it ... if there is anything interesting here you will be notified via a mailing list :)