Back in February, I took a look at the state of TLS (“HTTPS”) security on Norwegian banking websites. The results were very varied. Seven banks have since then improved their security and three are still vulnerable to known security flaws.
The updates results are sorted by security ratings from Qualys. The best rating being A+ and the lowest being F. Qualys’ ratings reflect strict security recommendations and best practices. The banks’ own servers broadcast the information that make out the tests.
This list only contains ratings who have changed since my original article. Check the original article for the full list.
Banks who have improved their ratings since February
- BN Bank (up to A from F): Have added support for TLS 1.2, Forward Secrecy, and secure renegotiation. Have removed support for older ciphers and patched known vulnerabilities.
- Bank2 (up to A from C): Have added support for TLS 1.2, Forward Secrecy, and secure renegotiation. Have removed support for older ciphers.
- Eika Gruppen (up to A from C): Have added support for TLS 1.2, Forward Secrecy, and secure renegotiation. Have removed support for older ciphers.
- Bank Norwegian (up to A from B): Have added support for Forward Secrecy. Have removed support for older ciphers.
- Sparebanken Vest (up to A from A-): Have added support for Forward Secrecy.
- Danske Bank (up to A- from B): Still doesn’t use HTTPS by default nor does it support Forward Secrecy.
- Verdibanken (up to B from F): Still has no extended validation, support fewer old ciphers, have no support for Forward Secrecy.
Two banks made the effort from boost their grade up and out of the F category and into either A and B. Two banks moved from C to A, and two from B to A or A-. All except Danske Bank now uses HTTPS by default. Good work on improving your security all around!
No change for the better
Some banks must have been busy in areas other than online security. ITavisen took my article and contacted each of the low-graded banks (in Norwegian) for comments. They got some non-committal answers from some banks and complete dismissals from others. These are the banks who haven’t updated since my original article back in February:
- Gjensidige (F): Does not accept modern TLS 1.2, and does accept weak RC4 ciphers. Vulnerable to the POODLE attack. No Forward Secrecy.
- KLP (F): Does not accept modern TLS 1.2, and does accept weak RC4 ciphers. Vulnerable to the POODLE attack and attacker-in-the-middle attacks because of insecure renegotiation. Weak SHA-1 certificate chain. No Forward Secrecy.
- Nordea (F): No HTTPS by default. Does not accept modern TLS 1.2, and does accept weak RC4 ciphers. Vulnerable to the POODLE attack. Weak SHA-1 certificate chain. No Forward Secrecy nor secure renegotiation.
It’s good to see the list is much shorter now than in February. However, if you are considering where to do your banking: choose from the options in the first list and not this one.
Understanding the risks
The test results listed here are from the front page — the metaphorical main entrance — of the banks’ own websites. From their bank’s front-page, a user is linked to a login form to perform their online banking. This login form is often hosted on a different domain and server (by a different contractor.) Security on the login form servers haven’t been tested here. It’s the front-page’s security that can become the weakest link in an otherwise flawless security chain. Why would anyone attack what is often a more secure server — the login page/server — if they can hijack the link to the login form and present their own form instead?
Danske Bank and Nordea don’t use HTTPS by default. They are easy targets for attacker-in-the-middle (AITM) attacks as they offer no protection at all. The other banks with low ratings and known vulnerabilities requires more effort to attack.
In a AITM, the attacker would intercept traffic going to bank over a public Wi-Fi network (café, airport, school, etc.) or over the Internet (a more sophisticated and targeted attack.) The intercepted traffic could be redirect to a server under the attacker’s control or altered in-transit to modify the login link. Most visitors would likely not react to being directed by their bank to mybanklogin.com (the attacker’s site) instead of login.mybank.com (the bank’s site.) The malicious page could be made to look like the bank’s actual login page and visitors would proceed to fill in their login details as normal. The attacker’s site could get a certificate for their site so it would look secure.
The banks that don’t take simple steps to mitigate the security risks at their main entrance reveal a lot about their internal security policies. If the main entrance is unguarded or poorly guarded, what does that say about more sensitive systems?