Ctrl.blog

Imagine a privatized nationwide authentication system used to access government services, confirm contracts and online payments, and everything else. Now, imagine that the system was designed to be extra friendly to imitation and credential theft (“phishing”). Here’s everything wrong with Norway’s BankID authentication system.

Norway’s banks jointly own and operate BankID. Citizens use BankID for everything from logging in to government services like taxes and health care, to digitally-sign private contracts, applying for loans and credit cards, and more on the private market.

The authentication scheme has multiple layers and uses a secondary authentication factor, either using a one-time code generated by a key fob or a tap in the BankID app on a trusted device. To log in with your BankID, you need to enter your national identity number — similar to a U.S. social security number — or your phone number, and your BankID password. The latter is often the same as your bank password, although your bank probably requires BankID anyway.

The problem with this solution is when and where you’re expected to enter your legally-binding credential details. A merchant or service provider embeds BankID directly onto its webpages through an inline frame (“iframe”). Your web browser will only display the domain and encryption certificate details of the top-level webpage, e.g., the merchant’s domain.

There’s no way of telling whether you’re giving your authentication credentials to BankID through a legitimate iframe or handing it off to masquerading criminals. A top-level webpage can also intercept keystrokes and clicks on any embedded iframes. Iframes simply weren’t designed to be used in a security-critical context!

Web browsers have largely focused their anti-phishing efforts on ensuring that their address fields can’t be faked. You can trust that the name you see in the address field is the website you’re visiting. You can thereby trust that you’re communicating with the right company or service.

The industry at large has focused on teaching its customers to check that they’re on the expected website before entering their credentials for that site. In an ill-advised effort to make the transaction seamless, BankID has inadvertently disregarded all the established best-practices. BankID’s customers are thought to trust anything that looks and acts like BankID, regardless of where on the web they encounter it.

The E.U. Payment Services Directive (PSD2) requires that all online payment transactions are carried out with Strong Customer Authentication (SCA). SCA is better known as “multi-factor authentication“ in the broader world outside E.U. regulatory texts. Norwegian debit- and credit card issuers have outsourced this task to BankID. So, whenever you’re making a purchase anywhere on the web, you’re presented with the BankID authentication iframe on the website of the merchant or service provider.

Upon receiving their BankID, consumers must sign a contract where they promise not to share their BankID credentials with third parties. Yet, the service’s design and implementation details make it impossible for people to verify who they’re handing those details over to.

I contacted BankID BankAxept (the company behind BankID) for comment on the issues discussed in this article. I initially didn’t hear anything, but I received a reply after Erlend Oftedal brought up the same problem on Twitter.

[It would be] advantageous if all communication with the user happens with bankid.no visible in the user’s address field. [We’re transitioning to this solution] and most sites with BankID currently use it. […] We still need to work on transitioning all sites to this solution, but the work is underway.

I’m happy to hear BankID is working to improve its system. I’ve only seen this alternative new solution used on a handful of websites, whereas I engage with the less secure iframe-based solution everywhere online.

Regardless of BankID’s future plans, I don’t understand how an authentication-as-a-service provider could ever have designed and put the original iframe-based solution into production. BankID should never have asked its customers to trust and provide their login details anywhere but “bankid.no”.

Someone should have pushed the big red button at BankID before this got released into the world. You don’t need to make much effort to make a good-enough replica of the BankID iframe to fool people. I’m well aware of the problems, yet even I am reduced to blindly trusting that anything that looks like BankID on any website is legitimately BankID.

While spell-checking my email to BankID BankAxept, I received an email with a link to a phishing campaign that led to a perfect impersonation of the BankID iframe. It wasn’t even an iframe, just a form on a webpage with a border. Not that anyone could tell the difference anyway. It was “good” to get a timely confirmation that others have recognized and are actively exploiting the system’s weaknesses. Report phishing SMS/emails! Don’t just ignore them!

BankID could make its authentication system more challenging to imitate today without requiring every third-party payment processor and intermediary website to roll out updates. For example, the iframe could be changed to only contain a “Log in with BankID” button. The button should open a separate window under the trusted bankid.no website where the user would enter their authentication credentials.

Upon completion, the new window could communicate the authentication result to the iframe on the merchant website, close the new window, and return the user to the originating website. Throughout the process, customers could rely on their browsers’ built-in domain verification systems to ensure they didn’t share their credentials with a third party.

The above suggestion should be (relatively) easy to implement and deploy in the existing ecosystem. I’m sure there are good reasons why they’re not already doing it. However, BankID needs to get on top of this problem before its customers fall victim to BankID impersonation and phishing. BankID has already undermined and damaged the whole industry’s push to get people to verify the domain before entering their passwords!

BankID’s near-monopoly on authentication services in Norway will fall if its customers lose trust in its systems. Get it together, guys!

Please remember to report instead of ignore phishing campaigns that land in your inbox! You might recognize a phishing campaign, but others can miss the signs you spotted.

Disclosure: I work for the web browser vendor Vivaldi Technologies. A part of my work involves ensuring the reliability of the browser’s security indicators.