HTTPS on Your Landing Page Is Important

Another lesson is to always host the login section on a sub domain of the company which website you visit. A prime example not to follow is Citibank in Europe. My account is with citibank.co.uk, but when I login to my account I get redirected to online.citi.eu. How do I know that citi.eu belongs to Citibank? I have no relationship with citi.eu, that’s not the website I visited. How do I know I can trust it?<p>Microsoft is another major offender. When logging in, I get redirected 20 times between various domains, none of which in microsoft.com

It&#x27;s 2017, and my social media account is protected by a tamper-proof phish-resistant embedded-encryption U2F microcontroller dongle, in addition to a password of virtually unlimited length and charset. Meanwhile, my bank has a max password length of 12 and I can only use an alphabet of roughly 64 characters.<p>The future is here folks. And it sucks.

About 8 years ago Natwest had a policy of having a &quot;browser whitelist&quot; which was rarely updated. Each time a security update for chrome or firefox came out it would be 2 weeks before online banking was accessible, and using any pre-release versions were out of the question.<p>I complained and a member of the dev team phoned me up and after a long discussion about why this was madness he told me that it was better to use older browsers for important things such as online banking (like IE6 which was in their whitelist) because they&#x27;re tried and tested.

A bit side topic:<p>It seems that every time Troy interacts with a company on Twitter, they never seem to click on to who he is, until it&#x27;s probably too late and they look like fools.<p>It&#x27;s just so amusing to see companies trying to condescend to Troy, when he&#x27;s one of the most visible authorities on web security on the planet (not necessarily the most authoritative, but the most well known).<p>I occasionally get this when people try talking to me about computer science topics, when they don&#x27;t realise that it&#x27;s what I do for a living. I&#x27;ve probably done the same myself when talking to Doctors and other domain experts, I&#x27;m sure.

Probably not a good person to piss off.<p>Several months ago I recall a website owner posted a bug to Firefox saying he didn’t need HTTPs and that Firefox shouldn’t tell users it’s insecure. Within hours his database was pwned.

That edit, about NatWest buying up the example domain to &quot;fix&quot; the problem, gave me real good laugh. It&#x27;s interesting how simple mindedness can be so unexpectedly expected.

I&#x27;m not really surprised, UK banks are absolutely terrible in terms of their product and even worse in supporting clients having valid points. Another example would be MetroBank that recently changed password prompt to a masked password prompt (in addition to already existing masked PIN alongside) ignoring the research proving its a horrible user experience and in fact lowers the security or (not a bank, but still major company) Three mobile provider that asks your for your password while calling in for support. You heard it right, support representative asks you for your password to verify you are the account holder. There is no other way and no amount of explaining that it&#x27;s insane and won&#x27;t happen till I&#x27;m conscious was able to convince them to stop.

That feeling when you&#x27;re arguing with an idiot, and the idiot isn&#x27;t listening because he thinks it&#x27;s YOU who&#x27;s missing the point.

&gt;you could go register nuuolb.com right now<p>Not anymore!<p><a href="https:&#x2F;&#x2F;www.whois.com&#x2F;whois&#x2F;nuuolb.com" rel="nofollow">https:&#x2F;&#x2F;www.whois.com&#x2F;whois&#x2F;nuuolb.com</a><p>It seems NatWest has quickly gone to secure this major attack point in their otherwise chink-free armour. Does someone want to inform them about nwalb.com as well?

A great example for why we (the Google Web Developer Relations team) advocate for HTTPS everywhere.<p><a href="https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;fundamentals&#x2F;security&#x2F;encrypt-in-transit&#x2F;why-https" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;fundamentals&#x2F;security&#x2F;encr...</a>

Fun story, my once CC provider (the now defunct &quot;Egg&quot;) for a period responded with three A records for their main site (egg.com or something).<p>This is fine, except one of these A records was a 192.168.x.x address so their site didn&#x27;t work intermittently.<p>I called them to report it and they refused to listen. Claimed the site was worked as intended from their office and they wouldn&#x27;t escalate.

Anyone want to hear a joke? Go to the financial ombudsman homepage [1]...<p>Bare in mind, on their complaints page you can download a complaints Word document, fully capable of having embedded VB script [2].<p>Also, it took them _months_ to sort out an issue where they would only check for 3 numbers (pin) and 3 letters (password), always asking for the first, second and third characters.<p>Also-also, I remember a while back not being able to access my card (for about a day) because a single engineer accidentally corrupted their main database.<p>[1] <a href="http:&#x2F;&#x2F;financial-ombudsman.org.uk" rel="nofollow">http:&#x2F;&#x2F;financial-ombudsman.org.uk</a><p>[2] <a href="http:&#x2F;&#x2F;financial-ombudsman.org.uk&#x2F;consumer&#x2F;complaints.htm" rel="nofollow">http:&#x2F;&#x2F;financial-ombudsman.org.uk&#x2F;consumer&#x2F;complaints.htm</a>

Maybe someday browsers won&#x27;t accept http connections by default (except for a few domaines defined for test purpose, or for some specific tld like .local)<p>Only then we can have 100% of the web encrypted.

Well, the bank seems to be stuck in the past...<p>10 years ago it was best practice for ecommerce shops to serve non sensitive pages (pages without forms or user data) without HTTPS to reduce the server load (HTTPS connections are a little more expensive than HTTP).<p>Nowadays, even the economical driven ecommerce shops got it that is better to just serve everything via HTTPS. It is very sad to see a bank (which should really know better) arguing that way.

Natwest is RBS - there is no point interacting with them - useless. Same with many UK household names, once they reach a certain size you are not a person and what&#x27;s in your head is of no interest to anyone.

&gt; Alarmingly though, nw0lb.com is still available as is nuu0lb.com and it-doesnt-matter-because-that-isnt-the-point.com.<p>I can just imagine NatWest: &quot;Oh, is that the problem? Ah, ok, well, let&#x27;s just go get that domain then. Sorted!&quot;

A Bank! There is no excuse.<p>The thing about domains is that so many companies register companyname-someotherwords.com for legitimate use that if you are suspicious about the domain name you&#x27;ll get little done. Azure is a case in point.<p>What if browsers record &quot;tainted follows&quot;? E.g. you visit http. Once you click a link, anything linked from there onwards is not trusted. No http post information is sent to the server without a hard to get around warning page.

Monzo [1], Starling [2], Atom [3] and Tandem [4] all manage to have HTTPS landing pages. If they can, there isn&#x27;t any excuse for the more established banks not to as well. Hopefully their mobile apps use HTTPS for everything too?<p>Apparently 35% of all UK banks have insecure landing pages. [5][6]<p>[1] <a href="https:&#x2F;&#x2F;monzo.com" rel="nofollow">https:&#x2F;&#x2F;monzo.com</a><p>[2] <a href="https:&#x2F;&#x2F;www.starlingbank.com" rel="nofollow">https:&#x2F;&#x2F;www.starlingbank.com</a><p>[3] <a href="https:&#x2F;&#x2F;www.atombank.co.uk" rel="nofollow">https:&#x2F;&#x2F;www.atombank.co.uk</a><p>[4] <a href="https:&#x2F;&#x2F;www.tandem.co.uk" rel="nofollow">https:&#x2F;&#x2F;www.tandem.co.uk</a><p>[5] <a href="http:&#x2F;&#x2F;blog.softwareverify.com&#x2F;list-of-uk-banks-that-are-secure-by-default&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blog.softwareverify.com&#x2F;list-of-uk-banks-that-are-sec...</a><p>[6] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;softwareverify&#x2F;status&#x2F;940961044633149440" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;softwareverify&#x2F;status&#x2F;940961044633149440</a>

I think the main point is to explain this kind of issue to non tech people.<p>A bit of programming, but most importantly, general concepts required to understand this kind of issue should be common knowledge.<p>For me it falls in the same category as the people putting an IP camera to watch their son sleep and broadcasting it to the whole internet. This kind of issue should be understood by them.<p>In this case, if the &quot;banking manager&quot; was aware of how security works, the issue would not have presented itself in the first place.

NatWest is also guilty of storing passwords in plain text: their login page says &#x27;enter the 5th, 8th and 12th character of your password&#x27;

The fact that there is no HTTPs on a brand&#x27;s landing page is no reason to annoy PR dudes on twitter though.<p>I think the attitude here is kind of douche.

There need to be a public directory for these websites. Something similar to <a href="https:&#x2F;&#x2F;haveibeenpwned.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;haveibeenpwned.com&#x2F;</a>. Something like is-this-site-stupid.com.<p>Ridiculous password policy, http home page, virtual keyboard for password, loading javascript from http and what not..

What&#x27;s concerning here is that they could have easily bought a certificate and configured it to their site.<p>Instead what they did as preventive measure is to buy the domain name that Troy mentioned as one of the possible vector to spoof their site.<p>Hate to say this, but whoever made that decision as a course of resolution should be axed.

Scotiabank, one of the biggest banks in Canada, has the same issue:<p><a href="http:&#x2F;&#x2F;www.scotiabank.com&#x2F;ca&#x2F;en&#x2F;0,,2,00.html" rel="nofollow">http:&#x2F;&#x2F;www.scotiabank.com&#x2F;ca&#x2F;en&#x2F;0,,2,00.html</a><p>Didn&#x27;t find any contact to report it. Is Twitter really the right place?

Note that <a href="https:&#x2F;&#x2F;personal.natwest.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;personal.natwest.com&#x2F;</a> has a valid certificate, but it redirects back to HTTP. :-(

I followed out this logic, and concluded that all pages on a site have to be encrypted, because someone may try to navigate to the login page from any page on the site. If the attacker can intercept one page they can lead the user to their own site (possibly even HTTPS, but with the wrong certificate). In a perfect worlds users would always check which certificate they&#x27;re trusting (and have a plausible way to check who it belongs to) but that is not the real world.

Yes, not only your landing page should be getting HTTPS; instead all websites should have had HTTPS already, this will gave the users&#x2F;customers a sign of safety and trust.

A tweet from Troy Hunt is like a telelphone call from Brian Krebs: a sign your day is not going to get better, if you&#x27;re a company infosec person.

It would be acceptable for your local Chinese food restaurant to serve their landing page without https. But a bank? of all things? A FUCKING BANK?.

I wonder how GDPR would change this attitude? If Natwest were to lose some data after May 18 and it was possible to show that they were warned about the problem by a reputable professional, then they are more likely to get fined, one would presume. Maybe this legal liability is what $bigcorp needs

I thought we are on &quot;all pages should be HTTPS&quot; since 2010 or something?

I&#x27;m so glad I bank with Nationwide who seem to do this right.

Not defending the practice of not securing your landing page in 2017, but for balance I must say that NatWest has probably the best banking mobile app I&#x27;ve ever used.

it-doesnt-matter-because-that-isnt-the-point.com

What is the exact problem here? Who would be doing a MITM attack on someone and how?<p>It doesn&#x27;t seem to matter to me if my ISP is MITM, because someone inside the ISP would need to cause that. If my ISP is forced to MITM by government etc, I am in trouble anyway.<p>I could see that it could be done by using a bad&#x2F;spoofed wireless or a public network connection somewhere. That makes sense. I don&#x27;t do that though; I only use my own secure home network in a wired fashion when accessing my bank account.<p>If people are able to spoof my network connection, they could interfere with non-https software updates on my machine, which would let them replace the root certs of my browser potentially, in which case https wouldn&#x27;t matter. Is the assumption here that all software updates on my machine are happening via https and only the bank website is a danger?<p>My point here is that while I agree what the bank is doing is bad practice, I don&#x27;t see how it would affect me in any way.

So more specifically, HTTPS on pages where you log in is important, not necessarily on your landing &#x2F; homepage? I am not disputing that may be a good idea, but it seems like the main complaint is that users are submitting credentials on an HTTP page?

Troy is way overstating the case.<p>You want to know if the login page is NatWest?<p>Click on the Login link and look at the browsers security bar.<p>If it says &quot;The Royal Bank of Scotland Group Plc [GB]&quot; and that then entity with which you do business, great.<p>It seems as if Troy would be just fine with HTTPS rather than HTTP, but DV validated certs aren&#x27;t what you want anyway with a financial institution.<p>It seems far more likely that you care about the entity you are working with (Royal Bank of Scotland), than the domain of the referring page (personal.natwest.com).