Wednesday, March 06, 2013


[This is bad, and this is just the beginning of this blog post...]

Update March 29, 2013: SSL config is now at grade A! Congratulations!

(brandname) is issued by Entercard, a joint venture between Swedish Swedbank and Barcleys Bank Plc. The irony of a credit card company not having a PCI-DSS compliant website is amazing. The lack of knowledge concerning users' selection of PIN codes is obvious, the lack of proper security for e-mail based marketing is shocking.

I hope this blog post will be read, understood and acted upon properly ASAP by those in charge.

First of all, thank you to name withheld, who sent me the marketing mail received from Remembercard.

Please phish us.

The picture is my screenshot of the HTML formatted mail. It was sent out from, a marketing firm. The web version of the mail is stored at as well. All links go through No mentions of Entercard using as an external service provider for marketing e-mail at the websites of either Remembercard or Entercard

Banks, financial institutions and credit card companies are generally good at advising people not to click on suspicious links received by e-mail. This e-mail from Remembercard has pretty much every possible options included to make it appear as a phishing attempt, including a tracking-click-through login link using http to https.

There are good reasons why marketing/info/sales staff should work closely with security staff to ensure marketing complies with internal policies and good practices. This was just one of those reasons.

Users' selection of PIN codes.

We know people select easy PIN codes, and existing research documents this. From a sales/marketing perspective promoting same PIN across all your cards form one provider, as well as user selected PINs, is good. People want simplicity, banks & credit card companies want people to spend money.
But there's a line to be drawn here. 

Making such obvious PIN selection examples as those pictured above has a dangerous effect. People use examples, because examples are "good". I wonder if Entercard have even heard the term "keyspace reduction" before?

Remembercard / Entercard should go examine the following links:
Joseph Bonneau, Sören Preibusch and Ross Anderson, University of Cambridge

PIN Analysis, an excellent blog post from DataGenetics.

Take the cucumbers! An analysis of user selected PIN numbers (Youtube)
Howard Smith, Chief Hacking Officer, Oracle Corporation (UK), at Passwords^10

PCI-DSS compliance for websites

These are the minimum requirements for SSL/TLS configuration of a website, as considered by SSLLABS,  to be considered PCI-DSS compliant:

(Thank you @ivanristic), with some more interesting info to read at as well.

Now *THIS* is the SSLLABS result on March 6, 2013, for the login website of Entercard:

[The grade F is clearly visible. Click for the whole truth, and nothing but the truth.]
That is one looong screenshot, sorry about that, but its necessary in this case. Some nice supported cipher suites in there, the irony is absolutely fantastic when their login page says your connection uses secure SSL encryption.
Now in their defence, if I should defend them, would be to say that their website doesn't necessarily handle credit card transactions. On the other hand, I can't see that as an excuse for a near complete lack of good practice security. Shame on you Entercard, period! (Wild guess: there is an outsourcing provider in the background who *really* needs to be audited. Thoroughly this time.)

I sincerely hope & believe Entercard wil take actions ASAP. Others may learn and benefit from this as well. 


  1. It seems weird to me that they can fail so completely when at least Swedbank, and Swedish banks in general work a lot with security. Their internet banking sites all use real 2-factor authentication etc, unlike a certain other large country.

    Good post though. Hopefully someone within the company will take notice.

  2. Well, I stopped expecting good security, and started assuming the worst instead soon after I started doing pentesting fulltime. That was in 1998. :-)

  3. A blog post about self-chosen pin and phishing is interesting. Your exposure of a netbank ssl weakness is not. Being a pentester since 1998 you know very well how a responsible disclosure of a security weakness should be done. Why didn't you do that? Publishing the weakness in a blog and "hope this blog post will be read, understood and acted upon properly ASAP by those in charge" is howtofail as a pentester. For other readers:

  4. 1) Usually I prefer to know who is behind "Anonymous". Just like in any other media, it is difficult to fight 'ghosts'. I do publish all comments unless it is pure spam, even if it harsh criticism of what I've done.

    2. You ask me why I didn't do responsible disclosure. How do you know I didn't? Well, you could be an employee of one of the companies mentioned. In that case I would have expected a formal statement from a named official, permitted to speak in such a situation, not through a anonymous comment to my blog.

    You could of course also be one of those (few, I hope) who doesn't like me personally, at a general level, and you are just making assumptions about me. That's a bit harder for me do something about, especially since you remain anonymous.

    3. I didn't to this testing as part of a pentest engangement, I did this on my spare time, no pay, nothing. It's like a public written customer complaint, although I'm not a customer, and probably won't be either.

    4. I am very well aware of responsible disclosure, thank you. What I am 'disclosing' is not a 0-day vulnerability. It is not a hidden vulnerability I've discovered, neither is it a design flaw. It isn't necessarily a violation of the PCI-DSS requirements either (as I stated in my blog post). Without becoming a customer (which I am not), OR doing a pentest that would require a written agreement for the tests necessary to verify it, I cannot make claims this website needs to be PCI-DSS compliant. And as you've read, I do not.

    What I am pointing at (not disclosing) is a webserver with a SSL configuration that is either completely misconfigured from the very beginning, or has been completely forgotten soon after installation. I say that based on experience and gut feeling, not direct knowledge of their operational environment, capacity & knowledge.

    The server supports 40-bit encryption (, which indicates one of these options:

    - The server was configured before 1996 (see 40-bit encryption article), and haven't been updated or reconfigured since then.


    - Those who designed/installed/configured the SSL certificate / policy are not the people who should do such work.

    (ITIL processes, quality management etc could be pointed at here as well, but it's late, and I'm going to sleep soon.)

    5. What I AM "disclosing" is information that is publicly available, without any need to conduct any kind of illegal or lets say questionable testing. I am merely saying "Hey, this publicly available information isn't good, and somebody should do something about it!"

    6. I did not inform Entercard before publishing my blog post, but I did inform them through public channels at the very moment I published it. And I published it during standard office hours, giving them an opportunity to read & take action if they found it necessary.

    I'll end this comment by saying that I DID think thoroughly before posting this online. What I am disclosing about the SSL configuration should usually represent a few hours work to fix for a competent technician. Add to that proper change management, testing, quality control, service level agreements for downtime etc, I'd say 2-4 weeks to fix. Online attacks against weak ciphers (as an example) are NOT techniques commonly used to breach confidentiality or integrity of a SSL secured website. Client-side trojans are, making SSL encryption irrelevant in most cases.

    The combination of current threats against the current configuration, time typically needed to either reconfigure, reinstall or relocate the services, as well as several other factors led to my decision to publish. I have no doubt this blog post has reached the people in charge, but I do not expect any type of thanks, recognition or other type of reasonable feedback.

    I can live with that. I just hope it gets fixed, for the protection of their customers and the company themselves.

  5. Apple have finally configured SSL support for iTunes. Of course people tested their implementation ASAP using SSLLABS. Of course this is just my assumption, but I'm pretty sure no "responsible disclosure" was done to Apple before posting this Twitter status. I have no doubt the attack surface & potential consequences against Apple is WAY higher that to Entercard, providing a better context for my choices regarding disclosure.

  6. You may find that over-reponsible disclosure is a good thing in a tiny country with a small, but highly IT-focused environment where basically every company is engaged in business with each other. $0.02. :)

  7. If public disclosure of already publicly available data becomes a bad thing to do....We've lost. :-(

  8. have done a story based on my blog post, available here (in Norwegian):

    Summarized: they admit lack of QA at the external marketing company in this case, and claim that the reason for their grade F SSL config "is due to customers with older platforms".

    Since things are now getting fixed, I'll say no more.

  9. I've rechecked using SSLLABS on Friday March 29, 2013, and their SSL config now receives a PCI-compliant grade A:



All comments will be moderated, primarily for spam. You are welcome to disagree with my posts of course.