
HTTPS on Your Landing Page Is Important - f2n
https://www.troyhunt.com/im-sorry-you-feel-this-way-natwest-but-https-on-your-landing-page-is-important/
======
cm2187
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?

Microsoft is another major offender. When logging in, I get redirected 20
times between various domains, none of which in microsoft.com

~~~
toomanybeersies
Microsoft's sign in is a real mess, I think in part due to having to make your
hotmail login that you made 15 years ago still work, along with the dozens of
other services that MS has acquired or integrated.

I've had a real shitter of a time trying to login before, with redirect loops,
or getting automatically signed out as soon as I sign in. Or accounts being a
"games for Windows" account, but not an MS account, or an Xbox live account,
so some other account. Often I've just found it easier to give up and make a
new account.

~~~
TuringNYC
Speaking of Microsoft's signin, I can no longer access my decade-old-held
Skype since their SSO integration. I've tried over and over and over and tried
every route possible. It is some edge case where the email was previously a
microsoft account and the password cannot be reset. I'm not the only one with
the issue. Shocking something like this doesnt get resolved for years on.

~~~
hobarrera
Authentication in Skype is awful. At one point, for reasons beyond me, I ended
up having two accounts:

* One account required me to log in with a username, and was associated with my main email address. * The other account required me to log in with my main email address.

In a way, they were both related to the same email, but different accounts.
This shouldn't even have been possible, but it seems that one was an old MS
account, and the other was an old Skype account. My roster ended up being
split half and half between the two.

------
exabrial
It'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.

The future is here folks. And it sucks.

~~~
MiddleEndian
Guess what! If your financial service restricts your password to letters and
numbers, it's most likely because they want you to be able to enter your
password on the phone.

So the passwords 'abc' 'ABC' and '222' are treated as equivalent. Try it out
for fun!

~~~
ozim
I don't want to enter my password on the phone, I have fingerprint or pin in
mobile banking app.

~~~
Frank2312
He meant over the phone, not on a phone.

Ex : I call my bank and I have to go through a menu leading me to the right
agent. Eventually, it asks for my password over the phone that I need to type
using the 10 numbers on a phone dial.

Good luck using your fingerprint there :)

~~~
ozim
For that i have separate numeric only password in my bank which is different
than my web login password. So bank is saving couple of bucks to reuse same
weak password that can be stolen on web and then used by attacker to
authenticate as me over the phone. What a crappy bank. I am just happy that
bank that I use is having all set better.

------
4rt
About 8 years ago Natwest had a policy of having a "browser whitelist" 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.

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're tried and tested.

~~~
TallGuyShort
Reminiscent of Amex's password policy (at least what it was a few years ago):
can't use punctuation in your password, because those keys are less frequently
used, and using them frequently in passwords will cause visible wear on the
keys, indicating to an attacker with physical access to your keyboard which
punctuation characters are in your password. Trying so hard, but failing so
badly.

~~~
toomanybeersies
"we require passwords to be a maximum of 8 characters, because if they were
longer, people would forget them, and would have to write them down"

I'm sure that has been said by some manager somewhere.

~~~
Klathmon
Not that it's an excuse, but I've personally seen many "technology averse"
people struggle with the changing "rules" about passwords.

When they started using computers, they were taught to NEVER write your
password down and to do things like replace letters like I with numbers like 1
for security.

Not only are those not true any more, but the opposite is recommended. Making
a unique LONG password is much more important, and writing it down on a sticky
note next to your monitor is arguably more secure from some threats than even
something like LastPass.

~~~
TallGuyShort
Well a lack of rules (but a list of recommendations, perhaps) would be a
solution there, not a maximum of 8 characters. Maximum password lengths just
screams out to me that they're not hashing and just storing passwords directly
in a database with a fixed-size column for passwords.

~~~
Klathmon
Oh I absolutely 100% agree, I just wanted to point out that sometimes a lot of
these seemingly crazy reasons come from somewhere, and that as developers that
might work with product managers like this, it's our job to help teach them.

But maximum lengths (that aren't measured in kb) are a monumentally stupid
thing, as are most other password "rules" (No, disallowing words in your
password is not a good idea...)

Provide a minimum length, and check passwords against common password lists,
and use a damn good hashing algorithm with a process in place to easily allow
upgrading that hash.

------
toomanybeersies
A bit side topic:

It seems that every time Troy interacts with a company on Twitter, they never
seem to click on to who he is, until it's probably too late and they look like
fools.

It's just so amusing to see companies trying to condescend to Troy, when he's
one of the most visible authorities on web security on the planet (not
necessarily the most authoritative, but the most well known).

I occasionally get this when people try talking to me about computer science
topics, when they don't realise that it's what I do for a living. I've
probably done the same myself when talking to Doctors and other domain
experts, I'm sure.

~~~
madaxe_again
This being NatWest the penny probably still hasn’t dropped, and they’re
probably trying to get him arrested for “hacking our internet”. I doubt
they’ll actually implement a change. The general approach in the UK has been
to not blame banks at all for poor security, and to punish anyone who finds a
security issue severely.

~~~
ZoFreX
NatWest are particularly terrible. Last time I checked, in-branch they were
still using Internet Explorer to visit an http (not https) site on their
intranet to launch via Java Web Start a thin client to log in to their (I
assume) mainframe to actually do things.

There's a number of places in that chain of events that something could go
nastily wrong, despite them owning every part of that chain.

~~~
sp8
I was in branch the other week and they were doing exactly that... from
Windows XP. Staff member told me they were upgrading to Windows 10 soon and
they couldn’t wait.

------
leesalminen
Probably not a good person to piss off.

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.

~~~
nanoscopic
Are you suggesting that Troy Hunt is involved in illegal pentesting ( pwning
their db )? I really doubt that. He is an industry professional.

The problem is not pissing off Troy Hunt; but more that they are advertising
that their website is vulnerable and that they don't care.

~~~
drspacemonkey
I think it was more that Troy Hunt is incredibly high-profile in the security
arena. If he blogs that your site security sucks, some of his readers will
prove it.

------
freeflight
That edit, about NatWest buying up the example domain to "fix" the problem,
gave me real good laugh. It's interesting how simple mindedness can be so
unexpectedly expected.

~~~
quickthrower2
Actually that is a smart thing to do in it's own right, as long as they
quickly move to https.

~~~
yjftsjthsd-h
Not even predicated on HTTPS; owning more domains helps combat some obvious
forms of fraud. Though, really, I agree that HTTPS is more important.

~~~
quickthrower2
> Not even predicated on HTTPS

Sorry that's what I meant. Both moves are smart. Doing both is smartest.

------
tachion
I'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's insane and won't happen till I'm conscious was able to convince them
to stop.

~~~
tolien
> Three mobile provider that asks your for your password while calling in for
> support

When I got a new nano-SIM (in 2012, one hopes they've changed this since),
they didn't check any ID and only needed a postcode and date of birth to move
my account to a new SIM.

~~~
IneffablePigeon
When I went in a couple of months ago to do the same thing (_slightly_ more
complicated situation - I had two accounts but only one SIM card and had
topped up the wrong account), the store manager told me he couldn't help me
and handed me their store phone dialled to their call centre (!).

The man on the other end of the phone was totally unable to solve my problem
and in the end just gave me £10 of free credit on the account I'd meant to top
up. He didn't ask for any ID or verification at any point, except for the
serial number on the SIM card. It was a pretty bizarre customer service
experience.

------
konschubert
That feeling when you're arguing with an idiot, and the idiot isn't listening
because he thinks it's YOU who's missing the point.

~~~
ethbro
The important thing for all of us to remember, is that in any given
conversation _we_ may be idiot.

Until I'm sure the other person doesn't know what they're talking about, I try
and assume they're right.

~~~
Twirrim
> The important thing for all of us to remember, is that in any given
> conversation we may be idiot.

Alternative take, particularly pertinent to this situation:

The person handling twitter is _not_ a technical person, but a customer
support person who handles hundreds of dumb questions, day in, day out, from
customers who have no clue what they're doing but will often throw technical
terms around.

Expecting solid technical answers from a general twitter account for a
business is beyond absurd.

~~~
heartbreak
The only expectation was an escalation.

------
ivanbakel
>you could go register nuuolb.com right now

Not anymore!

[https://www.whois.com/whois/nuuolb.com](https://www.whois.com/whois/nuuolb.com)

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?

~~~
zodPod
Gives me an idea! Why not go buy up a bunch of these types of names then tell
them that they look similar to their login url. THEN when they come to try to
buy it they find you own it and then charge them an arm and a leg for the
domain?!

~~~
cdancette
That's typosquatting and it's not very ethical. It's also in a grey legal
zone, you might get sued for this.

So I would advise you not to do it.

~~~
npgatech
Do you have any examples of "You might get sued for this"?

~~~
berbec
There is the horrible example of the nice computer company that had called
itself by a certain name. [1] They registered their domain in good faith and
conducted business. Later, a multi-million dollar car company decided they
wanted the domain for the name they choose after Datsun and lawyered up on the
mom-and-pop computer company.

1: [http://nissan.com/](http://nissan.com/)

~~~
toomanybeersies
Well they've made the most of their situation by putting ads on the page.

I can also get "complex web design" for $100 per hour from them. Judging by
the quality of that site, I might pass.

~~~
heartbreak
It’s an old site, looks like an old site, and only recently (last 5 years or
so) started running ads. It has been 15 years since the lawsuit was first
filed.

~~~
toomanybeersies
It says copyright 2016 on it...

~~~
justinclift
No, it says "Copyright © 1994-2016 Nissan.com". The layout and copyright
indicates it was probably created ~20 odd years ago, and hasn't received
significant updates in years.

The "2016" likely means they do minor/trivial updates now and again. Maybe
it'll get a "2018" in the next 6 months or so too... :)

~~~
EADGBE
Shhh... don't tell them about `new Date()`

------
kaycebasques
A great example for why we (the Google Web Developer Relations team) advocate
for HTTPS everywhere.

[https://developers.google.com/web/fundamentals/security/encr...](https://developers.google.com/web/fundamentals/security/encrypt-
in-transit/why-https)

~~~
blakesterz
Why is it you (or someone there) chose "Secure" in the address bar rather than
something like "Private"? It seems like the people who don't understand what
httpS means at all see "Secure" and think "oh this site is safe/secure" no
matter what this site is, like if it's a phishing site. I'm not one to be very
pedantic, but "Secure" up there really doesn't mean "Secure" at all. I know
what it means, but people falling for dangerous sites don't get that at all. I
don't really know what the best word is, but "Secure" seems like not the best
choice there.

[Edit] Thank you to those people who had some honest replies, not sure why
this got down voted, it was an honest question. When you go to the "Learn
More" page on Chrome it doesn't even say "Secure" it says "Information you
send or get through the site is private."

~~~
kaycebasques
Words are hard. Anyone got an idea for a better word? Send your ideas to the
security-dev mailing list (at least, I think that's the best forum...):
[https://groups.google.com/a/chromium.org/forum/#!forum/secur...](https://groups.google.com/a/chromium.org/forum/#!forum/security-
dev)

~~~
ryandvm
How about all it really means? "Encrypted"

~~~
rocqua
HTTPS means more than just encryption. There is also authentication and
integrity guarantees in SSL.

~~~
berbec
But the extras beyond encryption are definately not guarantees. [1] HTTPS
means encrypted HTTP. Everything else is "I trust the certificate authority to
provide oversight and verification." It may just be me, but I don't trust the
fine, upstanding CAs we have now-a-days. 1:
[https://stripe.ian.sh/](https://stripe.ian.sh/)

~~~
rocqua
Authenticity indeed is only guaranteed if you trust the CAs. Though it is
still nice to know that getting a false cert isn't trivial.

However, message integrity is a real benefit of SSL that doesn't need CAs.
Consider the original article. In this case encryption doesn't matter and
integrity does.

Without message integrity, considering the login link has a known location and
value, using bit-flips one might be able to change the login link (depending
on the kind of encryption used).

This message integrity is getting to be a much more important part of https.
There are a lot of things that you don't want other parties able to change.
Maybe even more things than you don't want them to be able to read.

------
wlll
Fun story, my once CC provider (the now defunct "Egg") for a period responded
with three A records for their main site (egg.com or something).

This is fine, except one of these A records was a 192.168.x.x address so their
site didn't work intermittently.

I called them to report it and they refused to listen. Claimed the site was
worked as intended from their office and they wouldn't escalate.

------
bArray
Anyone want to hear a joke? Go to the financial ombudsman homepage [1]...

Bare in mind, on their complaints page you can download a complaints Word
document, fully capable of having embedded VB script [2].

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.

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.

[1] [http://financial-ombudsman.org.uk](http://financial-ombudsman.org.uk)

[2] [http://financial-
ombudsman.org.uk/consumer/complaints.htm](http://financial-
ombudsman.org.uk/consumer/complaints.htm)

------
cdancette
Maybe someday browsers won't accept http connections by default (except for a
few domaines defined for test purpose, or for some specific tld like .local)

Only then we can have 100% of the web encrypted.

~~~
f2n
It's moving that direction. As it stands, any website can opt-in to this
behavior for future visitors with HSTS[0], or even for first time visitors
with HSTS preload[1]. And Google has been doing HSTS preload on their .google
TLD for several years, and recently rolled it out to their .foo and .dev [2]
TLDs

[0]
[https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

[1] [https://hstspreload.org/](https://hstspreload.org/)

[2] [https://security.googleblog.com/2017/09/broadening-hsts-
to-s...](https://security.googleblog.com/2017/09/broadening-hsts-to-secure-
more-of-web.html)

~~~
scott_karana
I was excited until I realized that HSTS Preload is just a hardcoded list in
the Chrome source!? Ugh, that's sort of disappointing :(

Couldn't something like a TXT record also address this, but on a cross-client,
scalable fashion? Like how SMTP with SPF or DKIM works right now.

(And yes, I know DNS also has trust problems!)

At the very worst, a central, programmatic source of truth, like DNSBL and
company... just like how Google offers their "malware sites" hash table for
all to use.

~~~
pfg
Using a TXT record for this purpose would achieve nothing. Just like an
SSLStrip attack would strip [https://](https://) links and redirects, an
attacker can simply block or spoof the DNS response. This doesn't add anything
that you don't get with regular header-based HSTS.

DNSSEC has no practical impact on this due to a lack of adoption both on the
domain and end-user resolver side. (Not to mention that it's a terrible
protocol.)

Note that the HSTS preload list is not only used by Chrome, but practically
all major browsers. For all intents and purposes it currently is the central
source of truth. I imagine if the size ever becomes a problem, browsers will
switch to a mechanism like Safe Browsing to distribute the list.

------
JepZ
Well, the bank seems to be stuck in the past...

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).

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.

~~~
dazc
In the UK there are major ecommerce sites still on HTTP.

~~~
mprev
Major sites, really?

~~~
dazc
marksandspencer.com very.co.uk asos.com next.co.uk

and many more.

~~~
Jaruzel
Other than shopping privacy, who cares? As long as the checkout and account
management pages are https, then I don't see the big issue here.

I'm just not one of these people who think there are armies of people at the
NSA/GCHQ spying on me. I'm also against forcing every website in the world
onto https. Doing so will significantly raise the bar of accessibility for
tinkerers and makers. If I had a webcam that showed the world whether my
coffee put needed refilling[1], are we all saying (on this thread, and troy
hunt) that it needs serving over https because the privacy and security of
coffee watchers is such a closely guarded secret that they need to be secure
in their coffee pot watching habit?

By all means, https up important pages and sites, but lets not make it
mandatory to the extent that http is no longer supported by browsers.

As an aside... a Barclays bank advert running in the UK at the moment is
showing users that 'a padlock in your browser bar ensures that you are safe
and that the site you are visiting is who you think it is' \- which is utter
bullshit, all a padlock tells you is that site owner has spent 5 minutes
setting up LetsEncrypt - it in NO way confirms that they are who they say they
are, and it's this lie that Joe Public are being sold right now.

\---

[1] Apparently this was a thing once ;)

~~~
cesarb
> As long as the checkout and account management pages are https, then I don't
> see the big issue here.

How do you arrive at the checkout and account management pages? By clicking on
a link. If the whole site isn't encrypted, the link can be modified to point
to false checkout and account management pages. HTTPS is not only for privacy,
it's also for integrity.

~~~
Jaruzel
How far do you go down the chain? At some point you'll hit a layer that the
internet has no control over - the users machine. You can https every page on
every site if you want, but if the users machine is compromised, then it's not
going to help one bit.

ALL https says is 'hey i'm encrypted' it doesn't PROVE to the end user that
it's really who it says it is. Extended Validation was supposed to fix this,
but that ended up as an evil money grabbing exercise by the CAs so that didn't
get the adoption it needed.

Until there's a secure validation banner at the top of the browsers that
contains an unfakeable and unbreakable 'this is who I am' statement, then
https is just a sticking plaster/bandaid over the whole problem.

And for those who say 'https prevents man in the middle attacks' \- no it does
not. There are several network level devices that by design
decrypt/review/encrypt/spoof-cert traffic to clients (WAN Accelerators and
Corporate Proxies being good examples) something that can only be overcome by
Security Pinning the Certs to IP addresses... but again hardly anyone does
that either.

~~~
cesarb
> And for those who say 'https prevents man in the middle attacks' \- no it
> does not. There are several network level devices that by design
> decrypt/review/encrypt/spoof-cert traffic to clients

These network devices (middleboxes) can do that only if the client lets it. As
you just said, once the client is compromised, all bets are off. HTTPS by
design protects against a compromised network, not against a compromised
client.

------
logingone
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's in your head is of no interest to anyone.

~~~
dazc
This can, sometimes, work in you favour though since it is possible to get a
county court judgement against these organisations for trivial reasons because
the original claim isn't responded to.

------
wyldfire
> Alarmingly though, nw0lb.com is still available as is nuu0lb.com and it-
> doesnt-matter-because-that-isnt-the-point.com.

I can just imagine NatWest: "Oh, is that the problem? Ah, ok, well, let's just
go get that domain then. Sorted!"

------
quickthrower2
A Bank! There is no excuse.

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'll get little done. Azure is a case in point.

What if browsers record "tainted follows"? 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.

------
arthurfm
Monzo [1], Starling [2], Atom [3] and Tandem [4] all manage to have HTTPS
landing pages. If they can, there isn't any excuse for the more established
banks not to as well. Hopefully their mobile apps use HTTPS for everything
too?

Apparently 35% of all UK banks have insecure landing pages. [5][6]

[1] [https://monzo.com](https://monzo.com)

[2] [https://www.starlingbank.com](https://www.starlingbank.com)

[3] [https://www.atombank.co.uk](https://www.atombank.co.uk)

[4] [https://www.tandem.co.uk](https://www.tandem.co.uk)

[5] [http://blog.softwareverify.com/list-of-uk-banks-that-are-
sec...](http://blog.softwareverify.com/list-of-uk-banks-that-are-secure-by-
default/)

[6]
[https://twitter.com/softwareverify/status/940961044633149440](https://twitter.com/softwareverify/status/940961044633149440)

~~~
ZoFreX
> Hopefully their mobile apps use HTTPS for everything too?

Well, HSBC's didn't: [https://threatpost.com/banking-apps-found-vulnerable-to-
mitm...](https://threatpost.com/banking-apps-found-vulnerable-to-mitm-
attacks/129105/)

------
kuon
I think the main point is to explain this kind of issue to non tech people.

A bit of programming, but most importantly, general concepts required to
understand this kind of issue should be common knowledge.

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.

In this case, if the "banking manager" was aware of how security works, the
issue would not have presented itself in the first place.

------
MarkMc
NatWest is also guilty of storing passwords in plain text: their login page
says 'enter the 5th, 8th and 12th character of your password'

~~~
dan1234
Who's to say they haven't just hashed each individual character of the
password?

~~~
MarkMc
Does that offer any real protection? I could try each possible character until
I find the hash.

~~~
NickLamp
You are correct. He was joking

------
antoineMoPa
The fact that there is no HTTPs on a brand's landing page is no reason to
annoy PR dudes on twitter though.

I think the attitude here is kind of douche.

------
a_c
There need to be a public directory for these websites. Something similar to
[https://haveibeenpwned.com/](https://haveibeenpwned.com/). Something like is-
this-site-stupid.com.

Ridiculous password policy, http home page, virtual keyboard for password,
loading javascript from http and what not..

~~~
ancarda
Perhaps something like
[https://securethe.news/sites/](https://securethe.news/sites/) but for every
website, not just news sites?

~~~
a_c
Thanks for the link! Yes, would love to have one for every website. And
visitor can input a website for "stupidness"

------
AngeloAnolin
What's concerning here is that they could have easily bought a certificate and
configured it to their site.

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.

Hate to say this, but whoever made that decision as a course of resolution
should be axed.

------
thorin1
Scotiabank, one of the biggest banks in Canada, has the same issue:

[http://www.scotiabank.com/ca/en/0,,2,00.html](http://www.scotiabank.com/ca/en/0,,2,00.html)

Didn't find any contact to report it. Is Twitter really the right place?

------
jwilk
Note that [https://personal.natwest.com/](https://personal.natwest.com/) has a
valid certificate, but it redirects back to HTTP. :-(

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

------
jacinabox
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're trusting
(and have a plausible way to check who it belongs to) but that is not the real
world.

~~~
syncsynchalt
Agreed, every page should be encrypted.

And the user shouldn't need to check the certs - if the CAs are trusted (yes
there are problems there) then the domain name is enough.

------
OliverJones
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're a company infosec person.

~~~
syncsynchalt
Could be worse; could be @taviso.

------
sandov
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?.

------
jimnotgym
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

------
erikb
I thought we are on "all pages should be HTTPS" since 2010 or something?

~~~
syncsynchalt
It looks like some markets have gotten the message more quickly than others.

------
harel
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've
ever used.

------
philipwhiuk
I'm so glad I bank with Nationwide who seem to do this right.

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

~~~
yjftsjthsd-h
What is the point?

~~~
SAI_Peregrinus
An insecure page can be MITMed. The landing page is insecure. The links from
the landing page to the login page can be redirected by an attacker to go to
the attacker's login page. Links on HTTP pages cannot be trusted. NOTHING on
HTTP pages can be trusted.

------
nanoscopic
What is the exact problem here? Who would be doing a MITM attack on someone
and how?

It doesn'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.

I could see that it could be done by using a bad/spoofed wireless or a public
network connection somewhere. That makes sense. I don't do that though; I only
use my own secure home network in a wired fashion when accessing my bank
account.

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'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?

My point here is that while I agree what the bank is doing is bad practice, I
don't see how it would affect me in any way.

~~~
jackweirdy
Don't think about _you_, think about the layman. Who probably has a WiFi
router from 5 years ago with outdated firmware that their ISP can't be
bothered patching.

~~~
nanoscopic
The layman clicks on links that say "you have a virus; download this tool to
remove it". They then click 'Yes I authorize' to verify that the downloaded
program should be allowed to corrupt their machine.

I fail to see how the bank changing their website to HTTPS is going to save
the average Joe.

There are so many websites and things that operate over HTTP that make our
machines vulnerable, that I think it is foolishness to use a link that could
be MITM to begin with.

That is, it seems to me, that if you simply avoid ever using wireless there is
no danger of MITM. I could see that XSS could be done on some sites with ads,
and that would be worsened by lack of HTTP.

Is it as simple as "Don't use wifi. Use adblock. HTTP/HTTPS then no longer
matters." ?

~~~
yjftsjthsd-h
This sounds a lot like "we can't protect average joes from themselves, so
let's not bother adding protections"? Sure there are always other attack
vectors, but that doesn't excuse ignoring the ones that are easy to fix.

------
bribroder
So more specifically, HTTPS on pages where you log in is important, not
necessarily on your landing / 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?

~~~
i80and
This is exactly the opposite of what the article states.

The HTTP landing page serves a link to the login page. This link could be
modified by a hostile network to another site. The fact that the login page is
served over HTTPS is immaterial for this attack.

~~~
pmelendez
Honest question...

Under that attack, wouldn't be the same whether you are using https or not? If
you are in a hostile network with a compromised DNS, Couldn't the domain be
phished too? Meaning that a valid certificate trusted by a fake CA would be
used by the browser?

~~~
wayfarer2s
> valid certificate trusted by a fake CA

I don't think that's possible. A fake CA can't issue out valid certificates
because you wouldn't trust their certs to begin with -- it's all about trust
and if you know they are a fake CA, then you would never trust them or
anything they issue. It's like if a known counterfeiter claims to be selling
legit products, you probably wouldn't trust them.

~~~
ashelmire
A compromised, but legitimate CA is a vector of attack in this case. Any CA
can be compromised by nation-states through legal coercion, and all of them
probably have some vulnerabilities that have yet to be found. There are also
new CAs that are not yet trusted, and sometimes old ones that are on their way
to being delisted.

So you need an up-to-date list of trusted CAs (which most of us are relying on
google for, in this case), which means trusting google at the very least (a
company that compiles and sells your data, and is also based in a nation that
issues secret warrants and orders to tech companies). It would be pretty
surprising if this wasn't already a vector of attack being actively used (the
fact that a trusted list needs to be maintained suggests that it is).

~~~
PeterisP
While there are ways to compromise CA's (e.g. like you say, by nation-states
for their intelligence goals), it is important to think about the appropriate
risk profile.

For a NatWest customer accessing their internetbank, the expected, quite
frequently observed risk comes from organized phishing teams pulling off mass
semi-automated scams. For an attacker _that_ , getting a certificate signed by
a fake CA is unrealistic, and the concerns that you list aren't going to
change anything since they're not going to do that anyway. On the other hand,
getting a misleading certificate signed by a real CA and passing it off as the
real thing is entirely feasible by this type of attacker, so fixing _that_ is
important.

Nation-state hacking, censorship and advanced persistent threats aren't what's
causing the most damage/problems to most people on the internet right now, the
multitude of random criminals is the largest issue. If you have to worry about
a CA "compromised by nation-states through legal coercion", then this by
itself means that you have a very different risk profile than pretty much
everyone else; and the risk-reducing activities that make sense for you
shouldn't be expected to be relevant for others and vice versa.

------
paulddraper
Troy is way overstating the case.

You want to know if the login page is NatWest?

Click on the Login link and look at the browsers security bar.

If it says "The Royal Bank of Scotland Group Plc [GB]" and that then entity
with which you do business, great.

It seems as if Troy would be just fine with HTTPS rather than HTTP, but DV
validated certs aren't what you want anyway with a financial institution.

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).

~~~
theptip
Unfortunately EV certs are not bulletproof:

[https://arstechnica.com/information-
technology/2017/12/nope-...](https://arstechnica.com/information-
technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-
think-it-is/)

For ~$170 apparently you can get an EV cert for "Stripe, Inc" (by forming a
company with that name).

Even aside from that fact, users are very bad at knowing what a secure site
looks like. I would wager that if most users clicked "login" and didn't see an
EV cert, but instead saw "<padlock> Secure" (i.e. a non-EV HTTPS connection),
they would not notice the difference.

Troy is right to kick up a fuss about this; this is a significant attack
vector (anyone on a wifi network can MITM your banking login URL), and it's
more egregious because of how easy it is to set up HTTPS.

~~~
paulddraper
Domain names don't solve that either.

For one tenth that cost, you can register stripeinc.net and get an SSL cert.
Yay!

Domain registration is available instantly for anyone, anytime, and it can be
phished at least as easily as anything else. [https://www.xn--
80ak6aa92e.com/](https://www.xn--80ak6aa92e.com/) looks pretty legit in
Firefox.

~~~
swvjeff
Sure, but that's just more reason to use HTTPS across their entire domain and
would help prevent users from being phished as easily. If I enter "apple.com"
I expect all links on that page to point me to the correct location. A MITM
attack from a non-HTTP page could easily alter the page and link me to
[https://www.xn--80ak6aa92e.com/login](https://www.xn--80ak6aa92e.com/login)
instead.

