Esphion

New liabilities - Or: Why anomaly detection has to be part of best-practices security

In an opinionated, but insightful article on The Inquirer web-site, an author mentions the case of a large financial organization, whose network was compromised by the recent Zotob worm. The article then goes on to discuss the liabilities that financial and health organizations may face when it is discovered that they had such a security breach.

Worm outbreaks as security events
Firstly, it is important to recognize that a worm infection in any corporate network is indeed a security breach: You cannot guarantee which backdoors or trojans are or were running on an infected machine. Thus, any data on that machine may have been accessed by some unauthorized outside party.

This means then that organizations in certain industries, in which regulations apply such as the Sarbanes-Oxley act, may face severe penalties for any such security incident. At the same time, these organizations are burdened with an IT infrastructure, which is prone to be buggy and with exploitable vulnerabilities popping up with either no or only very short advance notice. As we know, the patch-window is shrinking, which gives organizations less and less time to react, and may even be entirely absent in the case of a true zero-day exploit.

Claiming best-practices as defense
One of the key defenses that an organization has against any legal charges is to claim that whichever procedures and systems they had in place are commonly accepted as best-practice in the industry. For example, for the longest time, having firewalls was best-practice, and not much more was agreed upon for network security. These days, we know that firewalls alone are not sufficient, and defense in-depth is needed. For any large corporation, best-practice includes also timely patching and internal firewalls, just to name a few items.

All of these defense mechanisms, however, have a serious drawback: They are based on prior-knowledge. On rules and signatures, which have to be configured or loaded and kept up-to-date. Defending against the unknown, such as a zero-day worm, or a worm which takes advantage of a very recent exploit, is not readily possible with those traditional means of security.

Organizations need to improve their security architectures
I think it is only a matter of time before the various regulatory agencies realize that many organizations in critical industries and sectors are just not doing enough. For example, behavioral based anomaly detection has been around for a while. With truly intelligent solutions, such as those based on neural networks, these systems can rapidly detect outbreaks even of zero-day worms. With the right solution, mitigation signatures can be extracted in real-time, without having to rely on any prior knowledge. With that in place, networks can protect themselves rapidly. See here for more detail on how this can be done.

Anomaly detection is already part of the best-practices
Therefore, anomaly detection is a readily available tool, which is ready for main-stream deployment. The regulatory agencies will soon realize that there is no reason not to have those solutions as part of a best-practices security architecture.

So when will organizations learn that they need to significantly improve their security approach? The article says:

Here is when they'll learn, when someone notices that getting infected violates a whole bunch of laws, and that brings down the legal hammers on them.

It is not necessary to let it come that far. Organizations today already have cost effective and very powerful solutions available in the form of intelligent, neural-network powered behavioral anomaly detection systems. Deploying those in your network will lend a lot of credibility to any claim of following best-practices.

Juergen

 

What Zotob is teaching us - Or: The shrinking patch-window

InformationWeek today is running an article, in which they discuss how the currently active Zotob worm illustrates one key emerging fact about computer and network security: The so-called patch-window is rapidly disappearing.

The patch-window, of course, is the time between announcement of a vulnerability and the arrival of the first malware which tries to exploit that vulnerability. In that time period a vulnerable machine was therefore not likely to be exploited, and thus, this was the time period that the network or system administrators had to apply the necessary security patches.

Often, the authors of this malware actually derive the exploit code from reverse-engineering the patches, which are issued by the vendors. In the past, the patch-window was measured in weeks or even months. These days, as was the case with the Zotob worm, it just took a few days. Apparently, the authors of the malware are becoming more adept and efficient in constructing working exploit code and releasing it into the wild.

One could claim that even a patch window of a few days should be sufficient, since modern operating systems tend to provide convenient and easy-to-use patch mechanisms. However, that is simply not the case: Everyone trying to upgrade all the computers in a sufficiently large enterprise network will be able to attest to that.

And if the ever shrinking patch-window is not enough of a concern, there is always the looming threat of a true zero-day worm, a worm that takes advantage of a previously completely unknown exploit, or an exploit for which no patch at all is available. This Witty worm was a great example of how real this threat is.

Johannes Ullrich, chief research officer at the SANS Internet Storm Center, is quoted in the InformationWeek article as saying: "Defense in depth is your only chance to survive the early release of malware." Defense in depths means that one does not simply rely on perimeter defenses, such as firewalls, but instead has security systems in place throughout the network.

It is our position that ideally, since signatures of an exploit are not available for zero-day threats, these security systems should not rely on signatures, or on any prior knowledge. Instead, behavioral anomaly detection can be used to great effect in those situations. For more details, may I also point out what I wrote here about where to deploy anomaly detection. Also see here about how those systems allow for the construction of a self-healing and adaptive network infrastructure, which can deal with those issues, no matter what happens to the patch window.

Juergen

Distributed computing for anomaly detection

Today I want to talk a little bit about some of the underlying technologies we use in netDeFlect, Esphion's network anomaly detection solution. There are some core technologies, such as neural networks, which enable us to detect network anomalies by means of a highly-trained, specialized artificial intelligence, which is present in each netDeFlect installation. Other core technologies include components for high-speed packet processing, sophisticated data structures for fast lookups of information and advanced visualization and reporting capabilities.

To provide a complete, powerful and flexible solution, a lot of different technologies had to be combined in an innovative way. One of the things I find very attractive, but which normally takes place entirely hidden 'behind the curtains' is our use of load-balancing for the CPU intensive task of analyzing network packets and the extraction of zero-day signatures.

Before joining Esphion, I worked in a company, which specialized in server load-balancing solutions. I was an early employee there, and developed much of their core technology. Some of the largest web-sites in the world used our load-balancing systems to keep their business running, and manage massive amounts of hits on their servers. Therefore, I am excited that at Esphion we were able to put load-balancing again to good use.

Extraction of fine-grained signatures
After netDeFlect's neural networks detect an anomaly, the system then aims to provide signatures of this anomaly to the network operators. This has to happen fully automatic, and within seconds of the onset of the anomaly. Having those signatures then allows the creation of filter instructions for various network devices. I talked here about how our solution, in combination with already existing network infrastructure, can result in a network security architecture, which is surprisingly resilient even against zero-day attacks.

It is important to note that we are talking about true zero-day signatures, which in no way rely on prior knowledge or a signature database. Using several sophisticated algorithms, we can rapidly extract those signatures out of life packet samples, thereby enabling network operators to instantly get a handle on such anomalies, and to instantly proceed with the mitigation of the anomaly.

The signatures we provide need to be fine-grained to the extent that it must be possible to filter out the bad traffic with only minimal or no impact on the legitimate traffic (see here for more information on this requirement). Since anomalous traffic may at first look exactly like ordinary traffic, this is not a simple task: The algorithms to perform this analysis are quite CPU intensive.

Balancing the signature extraction work-load
When our solution is installed in a customer's network, there is usually a centralized controller, as well as a number of agents (sensors, in effect), which are distributed across the network.

After an anomaly has been detected, and after all the necessary data and packet samples have been correlated, it would be easiest to simply run the signature-extraction algorithms on the central controller. However, such a design would not be scalable.

Esphion always has had a focus on innovation, which should be reflected in the practicality and usefulness, but also elegance of our solutions. Therefore, in order to accommodate the often CPU intensive extraction of anomaly signatures, our engineering team has implemented an underlying load-balancing mechanism. So, when there are traffic samples that need to be analyzed for signatures, the controller will properly distribute the work among the installed agents in the network. Thus, the overall work-load is split among the agents, who all collaborate under the supervision of the controller to arrive at the required fine-grained signatures.

As a result, our solution has a built-in scalability, since it grows with the network in which it is installed. I think we have a powerful, elegant and intelligent architecture, which benefits the network operators, because they always get zero-day signatures within just seconds of the onset of an anomaly, no matter how big their network is. This scalability allows us to analyze anomalies faster and in much greater detail, thereby discovering information about anomalies that otherwise would remain hidden.

Juergen

Worm detection - You need to do it yourself

Recently, as outlined in this CNET article, several research teams have published papers in which they explain that intelligent worms can avoid being detected by the large worm-detection and early warning networks. Those networks are run by various security organizations, such as SANS, but also by some commercial security companies.

The details are explained in that article. In essence, those networks use honeypots and the monitoring of activity on unused IP addresses to detect worm activity or capture worm samples. Both approaches can be detected with different techniques.

So, as a consequence, it should be possible to write a worm, which escapes detection of those networks long enough, to make sure that no signatures for that worm can be produced and published before it has already reached critical mass. This is yet another example of why signature-based systems are leaving an organization vulnerable for too long, in the face of potential zero day threats.

Worse yet: A fast spreading worm, such as SQL/Slammer, for example, does not even need to bother with avoiding the worm detection networks, since it will have reached all possible targets faster than any signature can be published anyway.

This just goes to show that for proper worm protection, one cannot rely on third parties to publish signatures in time. If you want to keep your network safe, you need to deploy your own worm protection, right into the middle of it. An intelligent system, such as Esphion's netDeFlect, will be able to detect a worm outbreak immediately, and provide signatures and filter instructions, even for zero day worms, that can be used to stop the worm before it gains momentum in your network.

Juergen

Don't assume - Or: Why intelligent anomaly detection is needed

The Worm Blog recently pointed to an interesting paper, in which the detection and incidence handling of an SQL/Slammer outbreak in an enterprise is discussed. Remarkably, the enterprise actually had a reasonably secure setup. They knew about the new worm, thought they had a handle on it, and still were compromised.

This real-life incidence report represents a great example of why prior assumptions can lead to massive security failure. Note that all signature based systems rely on prior assumptions (the signatures). Also note that many security architectures are built on prior assumptions. When you read the paper, you can see that the assumptions made by the security staff are actually quite reasonable. Yet, these assumptions eventually led to failure, which just goes to show that additional intelligence in the network is needed.

The paper contains a lot of background information about the Slammer worm, as well as the network setup of that enterprise. If you don't want to read the whole thing, I would like to point you to the chapter 'Identification' which starts on page 19 and ends on page 21. If you just read those three pages, you can take away some very important points:

1. Perimeter-based security is insufficient.  A worm outbreak can happen from any point, even from within the network, as in this case.
2. Assumptions about the direction of the attack (from the outside to the inside) meant that IDSs were deployed only for one-way monitoring, missing the scans from within the network. Assumptions are bad.
3. Most importantly: Intelligence is needed when analyzing the network traffic. After long, fruitless debugging and trouble shooting sessions, one of their engineers finally noted that the network traffic profile looked different. An intelligent anomaly detection solution would have had this information instantaneously.

All in all, it took the business some four hours to conclude with certainty that they had been compromised and were fighting a worm outbreak. Four hours, in which servers were slow to respond, had to be rebooted frequently, and during which their tech-support had to field numerous calls by customers, complaining that the services were slow.

Contrast this with the situation as it would have presented itself with an intelligent anomaly detection system in place:

1. An infected machine emerges somewhere within the network.
2. The intelligent anomaly detection solution recognizes this immediately  (note that Esphion's netDeFlect can even detect slow-scanning worms in seconds).
3. Alerts are sent to the administrators, packet samples are presented and ACLs are suggested, automatically, and within seconds of the onset of the attack.

Only seconds have elapsed from outbreak to detection, analysis and start of containment. Is this fast enough? It is, as I had discussed here.

So, in conclusion, the paper presents an excellent case why any organization, which really wants to protect their uptime and assets, should consider the deployment of an intelligent anomaly detection solution, right in the middle of their network.

Juergen

Anomaly detection is not the same as baselining

Sometimes, when we discuss our anomaly detection solutions with potential customers or analysts, we notice that there is still a lack of knowledge out there about the power and nature of intelligent anomaly detection. Often we are asked: "Is anomaly detection not just a fancy name for baselining?" Of course it is not, but it is understandable why many people would think that. After all, the first systems which claimed to be able to detect anomalies on the network were indeed based on baselines, or worse, on manually specified rules. And even today there are still systems out there, which try to utilize baselining to detect network anomalies.

We believe that this technique is very much flawed, and that an intelligent approach to anomaly detection is needed. This is why we employ artificial intelligence, by using specialized neural networks in netDeFlect, Esphion's anomaly detection solution.

But let me outline this issue in more detail.

Baselining: What is it and what are the problems?
The idea of baselining is simple: Observe the network and record certain statistics about the network. Then find averages, minima and maxima for those statistics. After that is done, continue to observe and raise an alarm if the observed statistic deviates out of the established range.

For example: Let's say you observe the packet rate on your network for a week. You find that during that week you see a maximum rate of X pps. You can then monitor to see if the packet rate ever exceeds X, which might be indicative of a DDoS attack. If X is exceeded, you can sound an alarm. In effect, X has become the baseline, on which you base continuous anomaly detection.

This is a very simple example, but illustrates an important point about all baselining techniques: They rely on historical data. In other words, the network has been observed, and something that was typical about the network during the observation period has been retained and is used from now on.

The problem then is obvious: If the behavior of your network changes for legitimate reasons, then such a baselined system will not be able to differentiate between an anomaly that needs to be investigated and a normal, legitimate increase in network activity. An additional disadvantage is that anomalies can only be detected for the baselines which have been established.

There are many variations and advanced techniques which have been developed over time, in order to make baselining more suitable to deal with a real and changing world. However, the core problem always remains: Reliance on historical data, which inevitably leads to false positives, or missed anomalies.

Using intelligence, rather than historical data
While there is always a place for baselining as a supportive technology, the core detection of anomalies has to be much more intelligent than that. We are using specialized neural networks with great success. Neural networks, as you know, mimic the way in which the human brain works. This is the level of intelligence that is needed to be good in the field.

These neural networks look at the traffic in an entirely different way. Rather than comparing current data with historical data they look at how the traffic interacts, and how different types of traffic relate to each other. The neural networks allow us to look into the network at this very moment, without any concern for what it was like in the past. They enable us to examine how things are changing not just if they are different from something that was observed a while back.

This intelligence allows the neural networks to produce accurate results, even if the overall network usage profile has changed, for example when new applications have been enabled, or the user base has increased. A baselining system has graet difficulties with a situation like this. A truly intelligent system, just like an experienced network engineer, does not.

Juergen

More problems with flows

A few weeks ago, I wrote about the need and advantages of being able to generate fine-grained signatures of network anomalies. In that article, I also mentioned that those anomaly detection solutions, which are based on flows (for example Cisco's Netflow) are quite powerless when it comes to the generation of signatures, since they do not get any insight into the actual packet payload or even headers. I concluded that for effective signature generation, one needs to have a packet-based solution, which can see all the data all the time, not just some meta-summary of the network traffic.

However, there are additional significant disadvantages of a flow-based approach to anomaly detection, which I would like to elaborate on today.

Firstly, where do those flows come from? They are generated by third-party network devices, such as routers or switches. This has several interesting consequences:

1. The routers and switches need to perform CPU intensive calculations for every packet they see, in order to properly accumulate the flow-information.
2. Routers and switches need to set aside a significant amount of RAM, in order to store the flow table.
3. Routers and switches may suffer heavily under certain attacks. What does that mean for flow generation?
4. Exported flows are send over the network to some collector. How much traffic is that?

You observe, you change
In quantum mechanics, there is something called the uncertainty principle, which (in drastically simplifying words) states that you cannot observe something without changing it. The mere presence of an observer or test equipment changes what we observe.

Back in the world of network anomaly detection, we know that it is a non-trivial task for a switch or router to generate flow records. By consuming significant CPU cycles and memory, enabling flow-generation changes the behavior of the switch or router, usually by making it less responsive and pushing it somewhat closer to the edge of its capabilities.

For an anomaly detection solution, which is based on flows, the flow-generation needs to be enabled on the routers or switches. Just like stated in the uncertainty principle, our attempt to observe the network has itself a significant impact on how the network performs and behaves. The mere fact that we are observing is changing what we hope to see.

Not overloaded, yet?
The third point made above states that many anomalies or attacks, such as DDoS or worm outbreaks, can have a significant impact on network infrastructure elements, such as routers or switches. By having the resource intensive flow-generation enabled, those elements are even further taxed, thereby making them more likely to break under times of increased stress.

Of course, if the source of the flow-records disappears into the tar pit of CPU overload or the sunset of frequent reboot cycles, where does a flow-based anomaly detection solution get the flow-records from, that it needs to have any kind of visibility? As it turns out, flow-generation taxes the most heavily used resource on your network even further. To add insult to injury, its eventual failure then leaves the anomaly detection solution entirely blinded.

In general it is not a good idea to rely on the availability of network infrastructure, if one wishes to monitor possible attacks on that very infrastructure.

Increasing the severity of the anomaly
The fourth point made earlier refers to the mechanism by which a flow-based anomaly detection solution gets the flow-records: Over the network. This is usually not the high-capacity 'public' network, but instead an internal management network. Unfortunately, this network, or the management interfaces of the router or switch, may be maxed out by the additional load.

Consider that a typical flow record is a few dozen bytes in length (depending on Netflow version). Consider further that a DDoS attack may generate packets that are just 20 to 40 bytes in size, and that they can be crafted to each represent a new flow. Thus, the amount of flow record data is almost as big as the attack traffic itself. And all of this gets unloaded over the management interface of the router. Clearly, this is not practical, since here again, a resource is taxed more heavily when we are already under attack.

Sampling as a solution? Not really...
In short: With flow-generation enabled the effect of a network anomaly on the network infrastructure is multiplied, making the job easier for an attacker.

Some vendors of flow-generating devices offer sampling to eliviate this problem. In the case of sampling, only every nth packet is considered for the generation of flows. Clearly, this reduces CPU load and the number of flows that are exported. However, this also dramatically reduces accuracy. For example, if only every 100th packet is sampled, then flows that are a few dozen packets in length are likely to appear as only one packet. This makes them indistinguishable from flows that really consist of only a single packet. Average flow-length, however, is an important indicator in the state of the network. With sampling this data is lost. Besides, entire conversations between hosts may slip through the cracks, if sampling is enabled.

Clearly, sampling is only a stop-gap measure, which does not truly address or even fix the fundamental weakness of flows: A tradefoff between accuracy on one hand and massive resource impact on the network infrastructure on the other hand.

Packet-based anomaly detection
How does packet-based anomaly detection address those problems? For the most part, the problems simply do not occur at all.

For starters, a packet-based anomaly detection solution, such as Esphion's netDeFlect, can happily feed raw packets off a fiber tap. While the uncertainty principle still applies, of course, it does so on a much lower level: The signal in the fiber is slightly changed, but only to a degree that the interface hardware can easily deal with and compensate for. There is literally zero impact on the router or switch itself. No additional CPU cycles, no additional memory. In fact, the router or switch is entirely unaware that the traffic is listened to via a fiber tap.

A popular deployment alternative for a packet-based solution is to utilize a mirror or spanning port on the router or switch. This does have some impact on the device. However, mirroring or spanning is performed on the data plane (ASICs), rather than the control plane  (CPU) of the device. Therefore, the impact is typically negligable, compared to the generation of flow-records, and does normally not involve the CPU of the router or switch at all.

Finally, no data needs to be exported across the control network from the infrastructure device to the anomaly detection solution. This means that the magnitude of the anomaly or attack is not inadvertently multiplied by the export of an excessive number of flow records.

Conslusion
A packet-based solution continues to see all packets, no matter how overloaded the network infrastructure devices are. As long as there are packets on the wire, they can be seen, counted, analyzed and reported on. Therefore, the accuracy of the packet-based approach is not only much higher, but is also accomplished with a greatly reduced overhead and impact on the network.

Juergen

A better alternative to full-drive encryption?

One of the few blogs I am reading regularly is the one by Bruce Schneier. In a recent entry, he mentions a new hard-drive, which provides full encryption of all contents. However, I think that encrypted container files have several advantages over fully-encrypted drives, like the one he is mentioning.

As a laptop user, I am certainly very much interested in securing the data on my drive. However, I have always viewed full drive encryption somewhat skeptically. I much prefer to use a software solution, which created an encrypted container-file, but which can be mounted like a file-system. Essentially, these programs install as drivers, which ask for a password and then make the file-system inside of that container file available to you, just like any other new drive. Under Windows, for example, a new drive with its own drive letter would appear. Everything stored in that drive is automatically encrypted. All of this happens completely transparently to the applications on your computer. Once you unmount the encrypted 'drive' again, the drive letter disappears and all you have left is that container-file, which is of course encrypted.

Some examples of these programs are DriveCrypt, or Jetico's BestCrypt. Personally, I use BestCrypt. I really like it, because my laptop is dual-boot: Linux and Windows. BestCrypt allows me access to the encrypted data from both sides, which is nice.

There are two key advantages, which I see with the encrypted container files:

1. Backing up your important data is amazingly easy. In fact, for me a complete backup of all my e-mail, addresses, calendar and documents is done in a single drag-and-drop operation, without the need for any additional backup-management software. How? Just drop that single container file onto the office file-server, and it is all done. Since the file is entirely encrypted, it does not even matter if anyone else has access to it.
2. I can give my laptop to tech-support, without having to give them the password to the encrypted partition. If your entire drive is encrypted then nothing will work, unless that password is provided. Even your own tech-support or system administrator will not be able to fix your machine or work on it, unless you stay with them to type in the password after every reboot, or if you tell them the password. And even more: The admin may come across some of the confidential information you have on your drive, while helping you. Since the drive is unlocked in its entirety, this is quite possible. However, with the encrypted partition / container-file, you just unmount that partition and all the confidential data disappears. The admin can work on your laptop all they want, they still won't see the data. Not even by accident.

For those reasons, I personally prefer the software solution with encrypted container files. I understand that there are possibly some things to consider, like the location of temporary files, for example. But with some care, those issues can be addressed.

Juergen

Where is the right place to deploy anomaly detection?

A network-based anomaly detection (NBAD) system can detect network events, which are beyond the capabilities of traditional network security systems, such as IPSs and firewalls. Some areas of specific strength for NBAD systems are distributed denial of service (DDoS) attacks, worm outbreaks, or other such anomalies manifesting themselves in the network traffic. When we talk to our customers, we recommend placement of our NBAD solution, Esphion netDeFlect(r), based on what concerns them most.

For example, if a web-hoster wants to protect their network from incoming DDoS attacks, it is important to place the NBAD system outside of their firewalls. Why? Because a firewall may filter some of the DDoS traffic. A stateful firewall will not allow any packets to pass through, which do not belong to an already established connection. An exception may be made for those packets that start a new connection, such as TCP-Syn packets to port 80, in case of a web-hoster. Since many DDoS attacks use randomized source addresses, and may use packets other than TCP-Syn on port 80 (just to continue with the simple example), the packets used in the flood may actually be blocked. It is easy to see that this is not a sufficient defense, since the access links are already filled up, or the firewall may be overloaded. For the web-hoster, it is important to detect the attack quickly, and to get detailed filter recommendations, which can then be passed on to the upstream equipment for more efficient filtering.

If the NBAD solution would have been deployed behind the firewall, it would not have seen the anomalous traffic at all in this example. Therefore, if you want to detect incoming DDoS attacks, the anomaly detection solution should be placed outside of the firewalls, where we can be sure that we get complete insight into all the traffic.

The story is entirely different for someone concerned about the detection of worm outbreaks in their network.

As I discussed in previous postings, a worm may appear in the network at any time and at any place. The biggest threat is what has been known as the dissolving perimeter. With the dissolving perimeter, we cannot rely solely on perimeter defenses, such as firewalls and IPSs. The ubiquity of mobile devices, or extranet connections that need to be provided to business partners, or the presence of wireless access points - all of this causes more and more poorly defined demarcation lines between 'trusted' and 'untrusted' parts of the network space.

In my posting about network self-vaccination, I tried to point out that we need an adaptive security system, which can detect if something happens within the network and that allows the network to adapt and defend itself. Therefore, if the detection of worm outbreaks is important then the NBAD solution should be deployed deep within the network. That is where a worm will start to scan or spread, and that is where it needs to be detected. The same firewall that might block incoming DDoS traffic might also block outgoing scans of the worm. Therefore, an NBAD solution that is placed outside of that firewall will only have limited success in detecting an internal worm outbreak.

To sum it all up: NBAD is a great way to detect some of today's most pressing network and security impacting events. However, choosing the right place to deploy them is important: For DDoS attacks, deploy outside of the firewalls. For worm outbreaks, deploy deep inside of your network.

Juergen Brendel
CTO
Esphion Ltd.

Writing down passwords?

Recently there has been a renewed discussion about password security. The latest surge of interest was caused by a comment from Microsoft's Jesper Johansson, who recommended that people actually write down their various passwords. I think there might be a better way, though.

We all require a large number of passwords on a daily basis, and for obvious reasons are not supposed to use the same password for everything. Therefore, we need to remember a large number of strong passwords.

Writing passwords on a piece of paper has long been frowned upon, and many corporate security policies explicitly prohibit this practice. But according to Mr. Johansson, it is better to have complex and strong passwords than simple and weak ones. Since complex and secure passwords normally are difficult to remember, people need to write them down. If we prohibit them from writing them down then people will not use them, and revert back to the simple ones. And simple passwords are vulnerable to dictionary attacks. In his latest blog entry, even Bruce Schneier chimes in with support for this idea. He recommends we keep this list of passwords in our wallet.

This makes the wallet a single point of failure, of course. Personally, I think the situation can be improved, without using paper.

I use unique passwords for all sites and accounts, and yet, I never need to write them down, and I don't even need to remember them. All I remember is a hash function. When I need to log in somewhere, I take the name of the site I am logging in, apply my hash function and get a unique identifier, which I use as a password.

Here is an example to illustrate this:

Let's say you are a PayPal user, and want to log into your account.  The name of the site is 'paypal.com'. Let's take an extremely simple hash function as an example:

Take the site-name, extract the first, last and middle letter, count the number of letters in the name, capitalize the last letter if the number is even, and append that to a special filler string "rD7eI".

'paypal.com' consists of 10 characters, with the middle (in integer arithmetic) being 5. So, the three letters are 'p', 'a', and 'm'. The overall number of characters is even, and thus we capitalize the last letter: 'M'. What we get then for 'paypal.com' is this password: rD7eIpaM

Now this is pretty random looking.

What did I have to remember to arrive at this password? My hash function, which may contain one or more of those random looking filler strings. But that is all.

The secret is the hash function, and it is the only secret that needs to be remembered. To make this a secure system, though, the hash function should be a bit more complex. Otherwise, if one of your many passwords is compromised, an attacker may be able to reverse engineer your hash function. Realistically, this is only a risk if the attacker manages to compromise several of your passwords, though.

With a little bit of thought, it should be possible for most of us to come up with a personal hash function, which produces very random looking results.

Juergen Brendel
CTO
Esphion Ltd.