Tag: security

2

Security isn’t a dirty word, Blackadder

I’m often surprised at just how some websites treat their users when it comes to security.

As any decent website developer knows, one of the basic tenets of application security is that you should never store a user’s password in an unencrypted format – and you shouldn’t really be storing a password in an encrypted format, either. The correct way to deal with storing a password is to use a password hashing algorithm (note: “password hashing”, not just “hashing”)

I’m not going to pretend that I’m perfect at this. It took me an embarrassingly long time to stop using MD5 for hashing passwords in my code (although, in my defence, it was at least salted and not just a straight hash) but I caught up with the zeitgeist and all’s well again. Of course, it seems these days I do most of my work with existing frameworks and applications, so don’t really have to worry too much about that kind of thing any more.

The fact that there are so many frameworks and other tools out there to help devs with this kind of thing just makes it all the more upsetting when I see someone doing it so drastically wrong. Someone like whoever it was that developed KidsPass.co.uk

For those unfamiliar, Kids Pass is a website aimed at parents that offers many discounts and other offers on things to do with their little’uns. It’s not a website aimed at children, which is just as well because with password security as poor as theirs that would be absolutely terrifying.

What’s wrong with it?

The only thing right with it is that the website uses HTTPS, although even that isn’t as good as it could be (it uses an obsolete key exchange, in this case RSA)

Let’s start with the sign-up process:

Nothing too horrific there. You’ll note that it doesn’t ask me for a password, and also that it asks for credit card details. The latter there isn’t that unusual, but with how they deal with password security the thought of them having my card details fills me with the sort of dread that I feel if I ever find myself having to watch The Only Way Is Essex.

When you successfully pay for your membership, Kids Pass send an activation link that you use to complete your registration. More on this below.

Should you wish to continue, it is at this point that you choose your password. Which they then email to you, unencrypted, in plain text.

Still, that doesn’t necessarily mean that they store the password insecurely, right? Could just be that they send it to you after you submit it (which is still horrible from a security standpoint) and then hash it before saving it to their database. Fortunately, there’s an easy way to check.

Ah, the old “forgotten your password” trick

If you forget your password, a decent website will give you a link to click on where you enter your email address or username, and it will send you a “token” to that email address that can be used precisely once to change your password to something else. A truly great website will make the use of that token time-limited as well, usually 24 hours.

What Kids Pass do is this:

(note: I have changed my password for the purposes of this image, I’m not that silly)

Yep, they send you your password – as a reminder – completely naked and unencrypted. Sending passwords like this is bad enough, as SMTP (the method used to send email) is completely and utterly insecure, and could quite easily be pulled out of the ether by an attacker.

The real danger though, is that they are clearly storing those passwords either in plain text form, or in a way that they can be decrypted. The latter is better than the former, but not by much because it wouldn’t take a skilled hacker with access to their server long to figure out how the decryption process works, and when that happens they may as well not be encrypted.

I’ve sent emails and tweets to Kids Pass about this before (back in December), and have had no reply whatsoever.

Let’s go back to that activation process

When I first started writing this post, the goal was to talk about the lax password security – but in the process of writing it and performing the various actions contained within, I discovered something far more serious. Remember the activation link that they sent me earlier on? Well, it contains a unique identifier that ties the activation link to your registration, and the activation page looks like the below:

Note: I’ve removed my activation code, changed its format and redacted any personal details from the screenshot above.

The problem with this is that the activation code is entirely predictable – it’s not a 32 character token like many websites use, and all you need to do to access other people’s personal data is change the code in the URL that the link takes you to. It would be horrifically easy for someone to abuse this and harvest personal details – names, email addresses and postcodes.

This is unacceptable – not only is it a serious violation of the basic principles of information security and the Data Protection Act, but it’s inexcusable for a developer in this day and age to have not thought this through to that degree.

It should not be trivially easy to get access to other people’s personal information.

Oh, and about those credit card details

Because they collect credit card details directly on-page through their site, unfortunately there’s no way for me to identify who they use to process card payments. The server does do some sort of validation on the card details, as it spits out an error if I use an obviously fake card number, or a test number (4242 4242 4242 4242 for example)

The submitted number will clearly end up on their server somewhere though, be it in memory or in a logfile somewhere. Hopefully they don’t store the card details on the server for manual processing later on, or indeed for any reason whatsoever – because if they do, I shudder to think about how they’re storing them based on the revelations above!

They’re not the only ones

I wish they were, but of course they’re not. It’s frighteningly common – just take a look at Plain Text Offenders.

Sort it out, Kids Pass – before you have a serious security breach.