Chrome 64 was released on January 24, and we are happy to announce that the n26.com domain is now hard coded in the source code of Chrome, Firefox, Opera, Safari, IE 11 and Edge browsers. This makes N26 more secure. But how?
What could’ve gone wrong
Here is the story of Bob.
Bob is waiting for his flight at the airport and wants to take 8 minutes to open his N26 bank account. Bob grabs his laptop, connects to what he thinks is the airport public WIFIs, and fires up his browser to access http://n26.com.
The webpage opens a registration form and Bob enters his email, password, and clicks submit.
Little did he know that he just got his credentials stolen. So what happened?
Bob was connected to a malicious WIFI network. He also didn’t enter “https” at the start of the URL.
Bob thought he would automatically be redirected to https, but he wasn’t. The attacker running the WIFI network intercepted his request to http://n26.com, and instead of redirecting it to https://n26.com, he changed the website to show a phishing page impersonating N26.
If Bob had entered https://n26.com, his browser would have fired up a warning page telling him that something was wrong maybe someone was trying to steal his credentials.
His browser would have spotted the invalid certificate for the n26.com domain.
The attacker could also redirect the insecure request from http://n26.com to any malicious domain (something that looks like n26.com), owned by the attacker, with a valid certificate.
What is HSTS?
HTTP Strict Transport Security (or HSTS for short), as defined by the IETF, is a security mechanism “enabling web sites to declare themselves accessible only via secure connections.”
HSTS deals with three threat classes: passive network attackers, active network attackers, and “imperfect web developers.” This last term is used in the RFC but we would rather refer to it as an implementation mistakes.
HSTS policy can be declared by a website with an HTTP header in its directives:
`Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`
The directive “max-age” lets us specify the number of seconds the user-agent will regard the policy, after the STS header field has been received.
The directive “includeSubDomains” signals the user-agent that the HSTS Policy applies to this host as well as any subdomains of the host’s domain name.
HSTS for n26.com
In October 2017, we started to implement HSTS on our main domain, n26.com. When a n26.com webpage is loaded, your browser will issue a policy to always load n26.com web pages securely through https, even if you specified http in the URL.
If the TLS certificate does not match n26.com, you won’t be able to override it in order to bypass the warning triggered by your browser. This is how we made mobile banking even more secure.
Preloading the HSTS policy
But, what happens if the customer visits n26.com for the first time and the HSTS policy hasn’t been issued yet?
We’ve solved this problem by adding the directive “preload” to the HSTS header. If you meet the requirements, you can request your domain to be added to the HSTS Preload List. This is a list of domains that have their HSTS policy hard coded in Chrome, Firefox, Opera, Safari, IE11 and Edge browsers.
The process to have your domain preloaded takes some time, as the changes will be added in the next release of each browser offering this security mechanism.
With the release of Chrome 64, visiting http://n26.com—even for the first time — will force a safe redirection to https://n26.com.
That’s how easy it is to make your connection as safe as possible.
Going further
- The Road To HSTS: YELP engineering team story on how they deployed HSTS.
- Broadening HSTS to secure more of the Web: From Google security blog.
- HSTS Preload List: State of the Union 2017: By Lucas Garron and Adrienne Porter Felt
Interested in joining one of our teams as we grow?
If you’d like to join us on the journey of building the mobile bank the world loves to use, have a look at some of the Tech roles we’re looking for here.
