Indeed, I'd like to read your comments on my blog. But in more recent weeks spam comenters have attempted to raid my site. For some time I've required people to sign up in order to be able to comment on my blog. As a consequence, spam commenters created a pile of fake accounts using a small number of email addresses to register (from China and India). Some weeks later they used these fake accounts trying to flood the site with nonsense that didn't make it to the articles but cluttered my mailbox. It became a nuisance and something had to be done.

For a time I considered to modify the code of my blog to make registration for people using these email addresses impossible. The blog software answers a registration attempt by sending out a confirmation email with a link containing random data. If these emails wouldn't arrive at the spammer's email inbox the problem was solved.

But honestly, I do not only wish to block outgoing mail to people, who have proven their ill-disposed behaviour to me, I'd also like to protect me from seeing anything they might try to send to me, too.

The easiest way to achieve this was to tell my mail server about these culprits. I created two files (recipient_blacklist and sender_blacklist) that contain email addresses (or domain names) of accounts used to register as a commenter, that subsequently were used to submit heaps of nonsense.

It goes without saying that you have to be very careful about what you put into this database, because a domain name entry will block all email originating from or going to this domain without exception. This time, it was exactly what I'd wish to happen. To prepare the blacklist databases, I had to use the following commands:

After adding the following line to my postfix configuration file "main.cf" and restarting the mail server, any attempt to use one of the listed email addresses resulted in a nice reject log in the logfile. I've never seen anything from these addresses since.

Having said that, I heartily invite everyone to contribute comments. I am committed to keep this a friendly place, where you'll find interesting information and valuable advice. And I'm prepared to write code that will update my spam commenter database, helping to chase them away effectively, as soon as possible.

Do you know how modern email protection works?
Not really? You are not alone.

For a simple picture of email encryption most people think of a box in which they place their message that can be locked with a single key. Once the message is in the box and the box is locked, it can safely be handed over to someone (the mailserver) taking care of the transport to the intended recipient. This simple picture is not too bad because, in a way, that's what happens. But on the other hand this picture is fundamentally misleading to understand how email encryption really works. In other words, the reality is different.

If you follow this simple model alone, and many of us have no alternative, chances are, that you will make dangerous mistakes when you use email encryption or that you simply don't know how to use it. And that is not your fault.

Let me help you understand the basic idea behind modern email encryption to get a realistic picture of how it really works. A picture, that can lead you to do the right thing and to know why.

Why is the simple picture fundamentally misleading?

Because modern email encryption has two very different boxes used to lock a message. You probably haven't heard of the other type of box yet. But the second one plays the most important role in the whole process.

The Ordinary, Single-Key Box

Of course, there is a place for the ordinary box in email encryption that can be locked with a single key. In the real world such a box would come with a pre-fabricated key attached when you buy one in the shops. But the single-key box for email encryption works a little bit differently. You can buy a single-key box without a key and pick any key afterwards in a way you like, because a key is only a very, very large number. Once you lock the box with the key you have deliberately chosen (and nobody knows which one you took) the internal mechanism of the box changes in a way that this box (once locked) can only be opened with the same key or a copy of the same key. The experts today call this box the AES-box and the number you've selected the AES-key.

Well, the message locked in the box is ready for travel and the recipient receiving your locked box will only be able to open it, if he has a copy of the key you used to lock it.

I'm sure you see the problem that arises here. How would your partner on the other side know the key? Without the key it will be impossible to open the box.

That's a really hard problem, because you cannot attach the key to the box or send it with another courier. The key has to reach your partner in a safe way, or all security is lost.

The Invention of a Double-Key-Box

Some three and a half decades ago three clever guys invented an entirely different kind of box that revolutionized the digital world. The new box opened up new possibilities that were unthinkable before. I admit, there is no real-world example of such a box and that may be the reason why most people don't understand what they do when they use this kind of box in practice. And we all do use it when we surf the internet. Believe me, everything we do today to secure our online life is based on this new double-key-box. Paying credit to the inventors, experts call the new box the RSA-box.

How Does the Double-Key Box Work?

You can put a message into the box and lock the box with one key that you own. But once you've locked the box with this key you cannot open it with this key again, it remains locked. The only chance to get the box open again is to use a second key, which is a totally different one but which is related to the key used to lock the box. Both keys form a tightly bound pair where one key can undo the locking done by the other.

For email encryption those double-key-boxes are used to make sure that only one person is able to open the box, the recipient of your encrypted message.

But there was a problem, do you remember? You cannot send the key across the world together with the locked box.

Well, actually you can, and the message in the box will remain secure, too.

Sounds like a miracle? No, not at all, we now have double-key-boxes.

Imagine, you can make copies of your keys very easily. After all, keys are only large numbers. For email encryption to work properly, all you have to do is, make a key pair and circulate copies of one of your keys to everyone who may wish to send you an encrypted email. There is no risk in sending one key (the public key) out into the world so that everyone can get a copy. As long as the other key (the secret or private key) remains secret, all is fine. The secret key, on the other hand, has to be guarded as carefully as the crown jewels. If it falls into the wrong hands, all is lost (again).

What is really going on?

Before we can start to encrypt a message we have to get the recipient's public key. If we don't have it, we cannot do anything. I suppose you know why? To prepare our message for safe travel, we want to use a double-key-box and lock it with the recipient's public key. In doing so we make sure that the only person that would be able to open the box will be our partner, because only he has the corresponding secret key.

And what would he find inside the box after he has opened it? I bet you will be convinced that he will find our message inside. But no, actually he will find a key for a single-key-box in which we have placed our real message for travel together with the double-key-box. With this clever trick we have solved the problem of safe key transmission.

But only if we have used the correct public key to lock the double-key-box. If we happen to select the wrong public key, we are going to make a dangerous mistake. Not only will we give someone else the ability to open the box unintentionally, but we also prevent the intended recipient from reading our message. We are doing the complete opposite of what we intend to do, and we do not recognize that we've done something terribly wrong.

I hope, understanding the crucial part of the double-key-box will help you to avoid such terrible mistakes when you use email encryption in future. Now that you've come to terms with the basics of email encryption you will be immune to making silly mistakes, so go ahead and use email encryption.

Certainly not, if you store credit card information or passwords in clear text on the servers. Recent data theft disasters have shown, that it is not enough to operate a "secure server" and leave all customer's information unencrypted on this server. Because if you think your secure server is invincible, all your customer's data is at risk, the moment it turns out that the secure server is not as secure as you thought.

What's even worse, your customers have entrusted you with their data believing that operating a secure data center will be sufficient to protect their personal data from falling into the wrong hands. It's time to destroy this false belief.

Almost everything you'll learn to know about why you can trust an online shop or an online service provider boils down to the fact, that they make every possible attempt to secure their servers in the data center with all available bells and whistles of modern technology. But there is very little information - if any - about how they treat your data when it is stored on their secure servers online.

Of course I honestly value every effort to make online servers as secure as possible, but on the other hand I am convinced, that securing your online servers alone is not good enough. Let me explain.

A secure server is not invincible

Today most online services use a scripting language and a database server (think PHP plus MySQL for instance) and sensible information goes into a database. Usually the access to this database is given to every program that knows about the database password and normally runs on the same computer.

   It's a complete miracle to me, why after a default installation of some online shop applications the database password is stored in a file that could be read by any user on the system. It seems to be a commonplace belief that the server running the online shop is invincible, and therefore it poses no problem to store a database password in clear text without any additional protection. As we should know by now, secure servers are not always invincible and storing customer data unencrypted is a very bad idea. Not every online service is that careless about database passwords and it's easy to restrict access further, but today it seems to be the norm to dump the responsibility for the protection of customer data onto the administration personell in the online data center.

I wish to make the point, that we have to create online services in a way that if something goes wrong - despite the care to prevent this - customer data inside the online service is still protected against exploitation by intruders. And I'm convinced that such a protection is not only possible but absolutely essential if customers want to use online services securely.

Security and Convenience - Choose one.

As a consequence I'm sure that we have to correct another common misconception. You cannot have both, security and convenience in the online world. Forget it, you have to dump your notion of an easy, hassle-free, automatic and secure online service. Choose one or the other, you cannot have both.

That does not mean that secure online services have to be a pain in the neck but it certainly means that some procedures that have been introduced to make a customer's online experience "smooth", "seamless" and "easy" have to go if an online service that stores credit card information will ever be secure. Without knowing why, online customers will always think that some (unknown) data center professional is the right one to fight security problems, because after all they are in charge to make sure everything runs well. So it's vital that the ordinary online customer knows why some features of online services cannot remain the way they are today.

In their efforts towards making the online customer's life as uncomplicated as possible some vendors have started to encrypt their customer's sensible information. That's fine. But if you store the encryption key in a file next to the encrypted database, it's a little like locking your door and hiding the key under the door mat. This clever idea was born out of necessity, of course. As online customers demanded automatic payment from their online services there had to be a way that a program on a secure server could access the encrypted data (CC info for instance) without the intervention of a human being. The idea of storing the encryption key in some way on the server had been invented originally to ease the pain of the online customer.

If a customer wants to sign up to a service in the middle of the night (very convenient) the customer's data can either be stored in clear text (a bad idea) or, if it has to be encrypted, the key must be available to the web server program on the secure server (another bad idea). Surely, if you go fighting a bad idea with another bad idea, you'll never end up with a secure online solution.

Before you come to the conclusion that there cannot be a secure online service, let me tell you what I've learned during the last couple of months, while I tried to learn something from the data theft disasters and created a secure online service for small businesses, the secure online bills.

Secure Online Bills

An online service has to protect a customer's data even if there is an intrusion into the secure server, this is the fundamental principle that determined the design of my online service. It's really not easy to follow this principle at all times, because while I coded the system, I tried not to burden the user with avoidable inconveniences. But writing every single line of code myself made it clear to me that there have to be some decisions that will make the user's life a little bit more complicated. And it is inevitable, if the system should be secure.

I know, the last thing a customers wants is complications, "easy" is the marketing word not "complicated". But it became clear to me that there had to be more human intervention in the process if it should ever become more secure. So it is not complication that is inevitable. It's the introduction of the human factor into the process that makes it more reliable and secure.

What we need is more human intervention and less automation. I'm sure that if you begin to see, why it is necessary to rely on the informed decision of a human being instead of an automated web server process, the loss of convenience will become totally irrelevant. Making online services more human is the way to go, that's what I've learned from coding a secure online solution.

For instance, if you sign up for an online service and expect your login details to arrive via email within the next few minutes, your data cannot be secure, because the encryption key must be somewhere under the door mat. This is fine for demonstration purposes, and I use it myself for the secure booking service demo, but it's not good enough for the real thing, where customers rightly expect their information to be protected.

An online service cannot be secure when signing up is a matter of seconds. In fact, the setup of a secure online service requires manual work (of a human) on a server and of course some communication between the interested customer and the responsible person at the online service provider. The reason is simple, if the encryption key cannot be hidden under the door mat, it must be entered into the system from the outside in the moment when the encrypted information is needed. Using the system in a secure way requires preparation that cannot entirely be automated or, let me say, should not be automated at all, if you don't wish to encounter unpleasant surprises along the way.

What about lost passwords ?

Storing passwords in a database with the key under the door mat, no! Once the system is secure the database can only be re-encrypted with a key coming from outside the system. If you think the secure server should be able to reset your account easily, you're wrong. This would only be possible with a second emergency key stored on the server under a second door mat. No, the solution is to contact the service provider and make him use his emergency key which is safely stored outside the system to re-encrypt the database. That means, you'll have to wait until a human being does something useful for you. Is that too much of an inconvenience? I don't think so. Don't expect a server to do it instead. Get rid of this belief.

And if that takes time and costs money, be happy that your problem is being taken care of securely. And stop searching for a dirt-cheap, automatic way to have your negligence corrected without having to talk to a real human being.

Maybe you've tried to get the new firefox 4 to display applets by using the good ol' libjavaplugin_oji.so with no success. It took me a while to discover that newer versions of firefox require a different plugin called libnpjp2.so which is located in a totally different place in Sun's JRE tree.

Create a symbolic link in your plugins directory (either /usr/lib/mozilla/plugins or in your home directory in $HOME/.mozilla/plugins) and your firefox 4 should be able to display applets.

Why did nobody tell me?