I was interested to hear about a company here in the UK called ALLOW Ltd., offering marketing database management under a “we’ll get you off lists, then pay you to go back on at your pleasure” basis. That sounds a fair deal to me, so I decided to sign up for it.

“Our technology is built using some of the best and most secure tools in the industry. We have partnered with infrastructure providers who handle some of the most sensitive data in the UK (such as medical and financial records). Both the digital and physical security measures we have implemented are amongst the strongest available anywhere. This includes full encryption of all data at all times, full implementation of secure socket layers, security certificates and physical restriction of access to the data, our servers and our offices. Our systems have been fully penetration tested (that means we’ve asked people to try and break in).”

(There are other suitable assertions in various places – they even have a set of ‘principles’ about safeguarding data.)

Unfortunately, this promise is rather undermined in several ways – after noticing the first couple, I did a little digging to see what else was exploitable.

Here’s the final part of the joining process, where you choose a username and password combination:

The text I’ve cropped too eagerly says “Choosing a secure password is an essential part of protecting your personal information”, or thereabouts. I duly chose a complex password that fitted the requirements, and to my surprise it was rejected. I tried another, and it was rejected; then a third and a fourth. By trial and error I worked out what was going on:

1. The password must contain only the listed special characters, not just include one of them.

That’s a bit of a problem, because even assuming a basic ASCII set, 15 characters are unavailable to users; 80 are left, so that’s about a 15% fall in the available combinations*. Not a good start.

More concerning is the presence of a “security question” field. It’s used for resetting the password in the event losing it, but this technique for recovery has long been ridiculed – the shared secret is often common knowledge amongst friends, and sometimes (as in this case) the available questions are fairly easy for an attacker to find the answer to in public records or solicit from the victim without arousing much suspicion:

2. The security questions available include “First pet’s name” and worse, “First school name”.

It’s pretty pointless enforcing stringent password requirements, and then bypassing them with something so susceptible to a dictionary attack.

I was pleased to find that failing to log in to an account more than a few times results in a temporary lockout, which should deter casual brute force attacks. But I wanted to know how that security question would be used, so I ‘forgot’ my password and followed the links to reset it. Here’s the form:

Actually the first form, not shown here, initially just asks for a username, giving an error message if it isn’t registered, and here’s another problem:

3. The password reset process confirms the existence, or non-existence, of a given username – half the credentials required to log in – to any visitor.

I’d be prepared to take a bet that most users will choose “What was the name of your first school?” as a security question. The first pet you have is often at such a young age you can’t remember it clearly; the name of the street you grew up on might change a couple of times if you moved house. But first school I attended? I’ll never forget that, so it makes most sense to use as a ‘backup password’. It’s also the best one for an attacker to try and find out from public sources.

But that aside, as you can see the password is not generated at random and communicated to the real account holder out-of-band, in the manner of many other sites. Instead:

4. A new password is immediately set to a value already known by the attacker.

Once inside, an attacker can also change the security question or answer, or both, so you can’t even regain your account by telephoning the company – unless you can convince them you’re genuine, in which case the “security question” was a total waste of time anyway. I awarded some marks for notifying the user by email that the password has been changed, but immediately docked them again because – bingo! You’re now a victim of identity theft!

Let’s assume you’ve been locked out, the security question has been changed and you want your account back. ALLOW don’t let you telephone them; you either have to dig around and find an address to send an email, which we all know can be intercepted, or (and you’re encouraged to) contact them through a form on the site. You’ll probably include some personal details, because you want to convince them of your real identity; indeed, two of the options on the form are “I’ve got a question” and “Something doesn’t work”. I sent my findings through this very form, under the latter heading, and to my surprise:

5. Despite promises of “full encryption of all data at all times, full implementation of secure socket layers”, the contact form is transmitted to ALLOW in the clear, with no protection whatsoever.

So now anyone listening in your connection knows all about you too: your ISP, any of the peers along the route, the deep packet inspection advertisers if your ISP is less than reputable, and the neighbour who connects to your wireless and slips you a fiver every month for the privilege. Nice work, privacy specialists.

(For the record:

• I have sent these findings to ALLOW and await a response have a response.
• Yes, this scenario is unlikely, but it doesn’t fill me with confidence about the rest of their business activities.)

* please feel free to correct my maths. It was never my strongest subject.