No matter what bad news we hear about passwords – leaks, security breaches, compromised security – passwords provide a very good protection when used properly. The real weak link here is the user. If users could remember long and random passwords, the “problem of passwords” would be much, much smaller. The hype would disappear and the real issue – how internet companies store passwords – would become much move visible.

If we could remember passwords like v(tb_FbxzX63Le^Ud*qh or _xzeg7rACv!4W#KfB9Pa then hackers would stand no chance as large-scale attacks would disappear. Password security would be actually much better than what, for example, biometric methods can provide.

Strong Passwords

The problem is that nothing we users can do can protect us from the weak implementation of password security on a server. Even if you choose a very secure, unbreakable password, nothing can protect you from someone just reading it from a server for which you use it, if it is stored in plain form.

Proper design, good implementation, and thorough testing (including penetration testing) significantly reduce the risk of a web service being hacked but these measures can never be entirely sufficient against a targeted attack. Security of any web service must be based on multiple layers of security – “defence in depth” is the term some use. When implemented correctly, security incidents can be contained and the service restored fairly quickly.

Databases with passwords in plain form make containment much more difficult because attacker instantly compromises security of all users of the web service. You could argue that a server being directly attacked is an extremely unlikely event, but recent and repeated incidents on a very large scale (affecting millions of users) tell different story.

Case for Plain Form Passwords

There are situations when passwords (or PINs) have to be stored in plain form. These cases however seem to be quite rare, and extreme security measures have to be implemented in order to protect the integrity of the whole service.

A typical example is handling of PINs for credit and debit cards. PINs must be generated and then stored in banks’ mainframes so that they can be verified when we want to pay for a Sunday cream tea. At the same time, the PIN must be printed out so that we can receive it in a PIN mailer when we request a new payment card. Another complication is that cards may actually be personalised by a third party which specialises in card manufacturing, rather than the bank itself.

In this case, the security of PINs must be very tight and plain text copies of PINs are deleted immediately after printing. Also, these systems are not connected to public computer networks – like the internet.

In fact, if you can store the encryption key in a way that prevents its compromise, you will have created a very secure password management system – I will look into this in more detail in a follow-up post. Still, it doesn’t mean that passwords should be emailed to users when they ask for them!

Case of Companies House – 2012

Companies House says:

 (If you already have a company authentication code, we will send you confirmation of this code by post.)

The company authentication code is sent by post to the company’s registered office address (RO), normally sent within *5 working days.

The Authentication Code is the electronic equivalent of a company officers signature.

Two codes are required to access and submit data via the WebFiling Service, a Security Code and the company Authentication Code.

I started thinking a bit more about how Companies House handles passwords. They must have a fairly complicated and possibly expensive system (if implemented correctly from a security point of view) as they communicate final passwords in two forms:

• Electronic – using emails; and
• Printed – by sending letters (we are trying to verify now whether passwords are simply printed in a letter or if a form of PIN mailer is used.)

It is possible that these two methods use completely separate back-end systems, but the fact that both electronic and printed communications are plain text deliveries suggests that they are in fact one and the same.

So are passwords on their servers stored in an encrypted format? Let’s do a simple analysis of options. A symmetric encryption algorithm would have to be used, and for that to work, the encryption key has to be stored somewhere so that the server can encrypt and decrypt passwords when they are needed. There are three options to store the key:

• Code – the key is “hardwired” into the application that reads and/or stores passwords. This is a bad approach for long-term management as it is difficult to change the key.
• Configuration file – there is a configuration file readily available for the application so that the key is available when required. This option is easier for key changes – assuming the database can be re-encrypted. It is a better option than the first, but it is potentially easier for attackers to get access to the key.
• Cryptographic devices – one can use specialised cryptographic devices (HSMs) that use and store keys securely. However, HSM devices and their operation tend to be very expensive and require specialised knowledge.

When we take a closer look at the email password reminders sent by Companies House, we can find a direct link to an open source email software available from here. This suggests a low-cost in-house system implementation.

There are still several options open for the actual handling of passwords. They can be stored in plain text, encrypted with an application key, or protected with database encryption. Unfortunately, whatever the option is, it would not protect very well against an insider or a sophisticated attack against a password database.