Update : 10/05/2013 - 4PM:  The community forum has returned - with site-wide SSL enabled.  Appropriate cookies are httponly & secure and protocol support, key transmission and cipher strength all pass with flying colours.  Superb.  It's still not immediately clear to the user that the username/password required for the forum differ to those of the main site - which could lead to confusion, but there's arguably no security risk there.  The register/login form actions however, should be explicitly set to HTTPS - so if another period of "routine maintenance" happened to disable side-wide SSL, the forms will not pass data across the wire using the current insecure protocol.

As I no longer have an account expired or otherwise, I'm unable to check if the most serious issues have been addressed with the main site.  Many pages (including the security page ironically) are still in mixed mode and the useless "secure" badges are still dotted about, so instinct tells me they're still working on it.

On that basis, this is probably going to be the last update to this article unless Experian decide to get in touch as promised.

Update: 09/05/2013 - 7PM:  The community forum has been taken offline for routine maintenance.
Update: 08/05/2013 - 12:10PM:  I've had no correspondence from Experian regarding this article - and I'm yet to receive the letter through the post explaining how secure the system is.  eDigitalResearch (who run the community area at CreditExpert) are now aware of this article.
Update: 02/05/2013 - 1PM:  Experian have now removed my details from the system - less than 24hrs after it was requested.  Thank you Victor.
Update: 30/04/2013 - 9:21AM:  Experian are now aware of this article.  I'll update this post if/when necessary.

Experian is the UK's largest credit reference agency; offering expert advice on how to protect & improve your credit rating.  They also offer...

23

... all for the princely sum of £14.99 per month (£6.40 of which provides £75,000 ID theft cover).

What are the risks of identity theft?

As Sir Francis Bacon once said, "knowledge is power".

The more personal information a fraudster can obtain, the easier identity theft becomes.  Once armed with this information, they can open bank accounts, apply for loans/benefits/credit cards or worse, obtain genuine documents such as passports & driving licenses in your name.

I've been the victim of ID theft, so you'll have to excuse the lack of sugar coating throughout this article.  For some, it's a minor inconvenience.  For others, it can quite literally ruin lives.  I can't even begin to explain the stress it causes.  From a financial standpoint, I walked away relatively unscathed - thanks in no small part to Lloyds TSB who were diligent enough to block subsequent payments.  The whole experience really was life changing - it prompted a complete change in direction for the firm (see "About" link) and provides the basis for each and every security-related article here.

They sell ID theft protection, surely they know what they're doing?

You'd hope so!  After all, the site is adorned with all the appropriate badges & privacy policies.

6

This next one is shown on pages without SSL!  Let the browser determine if SSL is installed correctly - don't fake it with tacky and ultimately irrelevant images.

implied_secure

If you've followed any of my previous articles, you'll know by now these "Norton/Verisign secured" & "Mcafee secured" badges are virtually worthless.

Let's take a look at their "security" page (click image to enlarge)

7_mod

"high level of online security", "we have also been through the rigorous ICSA security screening process"
Two issues with that statement...
  1. It's shown on a page running in mixed mode (ie - not secure) - note the IFRAME pointing to doubleclick.
  2. "we have also been through" implies it was a one-off test.

So, not a great start... but enough of the petty stuff, let's dive in and explore in detail.

SSL encryption and why it's so vitally important...

SSL encryption (or "in transit encryption") helps protect your information as it's transmitted across the wire.  It does NOT encrypt data before or after transmission - ONLY during.  For example, as you enter your credit card information, it remains visible in its plain, non-encrypted form.  If/when the data reaches its intended destination, it's decrypted and stored accordingly.

Without it, everything you enter on a site can be read, disseminated, stored or cached by anyone between the source and end points (you and CreditExpert respectively).

Speaking of credit card information... (click image to enlarge)

5

If you're savvy, you'll notice two serious problems here.

  1. The page is loaded without SSL.
  2. We're still logged in despite the lack of SSL.

Take a look at the highlighted lines - specifically MCCProfileForm:CreditCard:CreditCardNumber, CreditCardExpirationMonth, CreditCardExpirationYear.  There's our information - about to wing its way around the world.

I logged in using SSL - so am I still safe?

no_secure_flag

HTTP is stateless - so in order to identify and differentiate you from other visitors, your browser passes a unique cookie (known as a session ID) with every page view.  Rather than delve in to the technicalities of cookies - think of a cookie as another password, but one which is entered automatically when you navigate around a web site.  You wouldn't (or shouldn't!) enter your real password without SSL (for the reasons shown above)... and the same applies for the cookie.  If that cookie allows access to highly confidential data (names, addresses, credit history, credit card info etc), it should only be passed around in a secure environment.  If the site is willing to send that cookie without encryption, what's stopping anyone copying it and becoming you - bypassing the username/password requirement?  There's nothing you can do to protect yourself against this type of negligence... but running a mile is probably a good start.

Those "secure" & "Norton secure" badges don't seem so helpful now.  Your browser provides irrefutable proof it's anything but secure - if you know where to look.

If you're really savvy, you're probably wondering if the form action posted to an SSL-secured location... (click image to enlarge)

3

No.  Damn!  Where's the number to cancel my card?

So, what just happened?

hops (click image to enlarge)

My information has just hopped through at least 18 locations - with no encryption -  from Virgin Media's infrastructure, to Above.net (UK), then Above.net (US), then AT&T (US again) and time-out's aside, ultimately landing at CreditExpert's US server.  That isn't a "high level of online security" - there's no security whatsoever.

It's not just credit card data they're willing to transmit this way!  Your entire profile & credit history is at risk. For obvious reasons, the reference number, email address & phone number have been partially removed from the images.  (click image to enlarge)

1

Are passwords stored securely?

Given the nature of their business, you'd certainly hope so.  There's no clear information surrounding their password storage mechanisms - but we can make an educated guess based on the constraints they impose on your chosen password.

password_safety

Secure password storage is a topic in itself - but given the context, allow me to run the basics past you.

  1. Never, EVER store passwords in plain text.
  2. Never encrypt passwords unless they're hashed first.  Straight encryption implies it can be decrypted - which is just as bad as storing it in plain text.  You should never need to access a user's password.
  3. Always use a secure hashing algorithm.  Keep Moore's law in mind too - what was considered secure at inception could be considered weak today.  Consider bcrypt/scrypt or 60,000+ iterations through PBKDF2 w/HMAC-SHA256 or higher.  The slower, the better - mindful of the constraints of your infrastructure.
  4. Always impose a minimum character limit - but NEVER a maximum.
  5. Don't restrict what characters a password contain - there's no justifiable reason for it.
  6. Never allow dictionary-based passwords - or those contained in so-called "common use" files.
  7. Always apply a unique CSPRNG (cryptographically secure pseudo random number) salt to each password - so no two passwords result in the same digest.

So, let's consider what the red error message means by carrying out a series of hypothetical tests.

Test #1 (very weak security)

Let's assume they're using plain old SHA256 - no key stretching, no CSPRNG salt.  The database field has a maximum length of 64 characters.

A user chooses a password of: my_password_for_creditexpert (28 characters in length)

If we go ahead and apply SHA256, we end up with this digest:
26238fd85d5475be057bddf4ab490e05bf79b06075349a60f9e288b0a561efce

The length of the digest is 64 characters.

Test #2 (weak security)

Let's assume they're still using SHA256 but this time, we prepend a static 8 character salt (#2*Aa93£).  The database field has a maximum length of 64 characters.

A user chooses a password of: -}^js&PI|<bW$INGkZQ],+=v]u+i;nE!5}NEjHn)o~y)20<1=Wt4m8Gtzb (60 characters in length)

... which after salting becomes ...

#2*Aa93£-}^js&PI|<bW$INGkZQ],+=v]u+i;nE!5}NEjHn)o~y)20<1=Wt4m8Gtzb

If we go ahead and apply SHA256 now (including the salt), we end up with this digest:
6e5f09dc7465bfe475ec4bc256777656b68e0f6f72042f788519676666133179

The length of the digest is also 64 characters.

Regardless of the length of the input password, the output digest is always 64 characters in length (sha256 only).  You'll also note that our input password is riddled with special characters - the output digest however, is not.  In short, you can enter any character into a hashing algorithm - so if the algorithm can handle any character, why impose a restriction on the user's password?

Also, if the end result is a constant length... why would anyone restrict the length of your password?  The answer lies in the last test.

Test #3 (no security)

Let's assume there's no security at all - everything is stored in plain text.  The database field has a maximum length of 20 characters.

A user chooses a password of: my_password_for_creditexpert (28 characters in length)

Now, there's a serious problem.  The database cannot hold 28 characters - it can only store 20... so your password would be truncated to "my_password_for_cred".  The next time you try to login, it will compare...

my_password_for_cred with my_password_for_creditexpert

... and because the two don't match, you can't login.

What about the restricted characters?

As we've already seen, if the password is hashed properly - special characters are not a problem.  If, as in test #3, they're stored in plain text - the developer has to consider if your password contains any characters which could circumvent the security of the application... known as SQL injection.  Although not required, many developers often refuse to accept so-called "dangerous" characters in an effort to increase their security - to your detriment.

So to cut a long story short - there's absolutely no reason to restrict a password unless it's stored insecurely.  Even the weakest security algorithm (test #1 & #2) allows any length password and any character to be used.

Before you take to the community forum to complain...

Experian have at least made an effort to secure the main site - which is more than can be said of the forum.  In order to access the forum, you need to register.  Just look at the information you have to provide...

[print_gllr id=425]

Name, email address, country, username, password, age (full DOB), gender, region, nationality, employment status, marital status, how many children, their ages, your occupation, combined household income, your educational background, your relationship with CreditExpert (existing customer, trial etc), when you signed up, your reason for signing up (debts, declined for credit, worried about ID fraud (lol)) and postcode.

Crikey!  That's a lot of personal info... just what a criminal would need to steal your identity.  So... where's the SSL encryption?  You guessed it - there isn't any.

I don't use the forum very often, am I safe?

Well, that all depends on your memory.  If you're a modern day "rain man" and never forget a password, you might just be OK.  If however, you often find yourself reaching for the nearest "forgot password" link, you're in trouble.  If you follow good security practice (which of course, you do ;) ) and use different passwords for every site, your username & password to access your credit file are different to those on the forum - but therein lies the problem.  The login procedure for the main site is SSL encrypted (at last!), however the forum is not.  If you inadvertently enter the main site's username & password in to the forum, you now have two problems.
  1. You're not logged in - because you used different details.
  2. Your other username & password is now floating around in plain text - and should be changed immediately.

If the criminal has your username & password, it's game over.

Have you reported it?

Yes - as soon as the results were verified.

I've made & received several calls, spoken to various members of staff via email - even left a message at head office.  The end result - well, I can't tell you.  The emails are confidential, and they wouldn't allow the recorded call to be made public - but suffice to say, I won't be renewing my membership any time soon.

Summary

I have no confidence in Experian's ability to handle my information safely - these flaws are not only very dangerous, but incredibly simple to fix.  If you value your identity, I'd strongly advise against using their services until an investigation reveals why such amateurish mistakes are being made.  Perhaps more importantly, it should be much easier to report these issues - if they ever crop up in future.

Thankfully, Experian aren't the only credit reference agency in the UK - you have Equifax & CallCredit to fall back on.  Personally, I use CallCredit via Noddle.  The site appears to be robust and well designed - but they too use implied security images!