I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
Originally published at Kerry Linux, a small business focusing on secure online services hosted and managed by Kerry Linux and also helping businesses to use open source software to its full extent. Special services at the moment are an online billing service for professionals and a booking engine for hotels and B&Bs.
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.
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 personnel 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.
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.
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.
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.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Kerry Linux © 2011-08-22 Kerry Linux
C++ is just an abomination. Everything is wrong with it in every way. So I really tried to avoid using that as much as I could and do everything in C at Netscape. (Jamie Zawinski)