HTTPS on Your Landing Page Is Important(troyhunt.com)
troyhunt.com
HTTPS on Your Landing Page Is Important
https://www.troyhunt.com/im-sorry-you-feel-this-way-natwest-but-https-on-your-landing-page-is-important/
306 comments
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.
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.
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.
I had this problem, too. I fixed it by deleting my non-Skype account & waiting about 60 days.[1] Changing the email of the non-Skype account might have worked, too, but I didn't need two accounts & didn't mind waiting.
[1] https://support.microsoft.com/en-us/help/12412/microsoft-acc...
[1] https://support.microsoft.com/en-us/help/12412/microsoft-acc...
I have a similar Skype issue. I have ancient Skype accounts with usernames, and my email address linked, but now use a Microsoft account for Skype with that same email address. Nobody can find and add my current account - whenever they search for my email address, all of my old usernames appear. I always have to add other users instead.
Very frustrating - fortunately I don't use Skype regularly but it's always an exercise when somebody asks for my username.
Very frustrating - fortunately I don't use Skype regularly but it's always an exercise when somebody asks for my username.
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.
* 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.
I managed to merge my Skype and Xbox Live accounts, and couldn't get them separated again.
The steps I found to unlink within the XBox UI didn't work, futher research now leads me to the following discussion which I am about to try: https://answers.microsoft.com/en-us/outlook_com/forum/oemail...
Edit: it looks like this was possible in the past (basically deleting the Skype account?), but not anymore.
The steps I found to unlink within the XBox UI didn't work, futher research now leads me to the following discussion which I am about to try: https://answers.microsoft.com/en-us/outlook_com/forum/oemail...
Edit: it looks like this was possible in the past (basically deleting the Skype account?), but not anymore.
I wanted to sign up for Office 365 a while ago. First thing that bothered me was the password limit of min 8 and max 16 characters (plus all the capital, special character, etc sacrifices you have to make). Second, after I signed up, you get a recommendation to switch off automatic password expiry!
What the hell MS?
Microsoft login is still the very old Hotmail login dating back to 1996 or so. The Hotmail mail and account system got rebranded several times like MSN, Live, Outlook, Microsoft ID, etc.
Well, a login system is a very central part, and other websites suck too, like Amazon still uses the old account login page since 1996 too. But Microsoft redirects way too often, it is worse.
Well, a login system is a very central part, and other websites suck too, like Amazon still uses the old account login page since 1996 too. But Microsoft redirects way too often, it is worse.
I hear you.
I was pulling my hair out the other day trying to find my Microsoft credentials in LastPass. I was searching for "microsoft", "office", "outlook" etc. until I finally found them under "live.com".
I was pulling my hair out the other day trying to find my Microsoft credentials in LastPass. I was searching for "microsoft", "office", "outlook" etc. until I finally found them under "live.com".
I also have an @live.com email. I think "live" was one of Microsoft's many failed services rebrands. Remember windows live messenger, windows live photo gallery? Lol
And before that, the grandiose ".Net passport"
Microsoft's account system has had at least five different names; it's just "Microsoft account" right now, but it'll likely be called something different in a year or two the next time Microsoft does one of their gigantic "rebrand all the things" purges.
A ridiculous number of times that I've tried to go to xbox.com while previously signed in, the site redirects me around a bit before dropping me onto a blank page. Ugh.
Microsoft's login experience has been generally broken for years. Multiple redirects through different domains. Heck it uses Javascript redirects. In 2017. So your back button won't work. And it has a habit of just not working. I went to visit a public page on docs.microsoft.com and wound up dead on a white page on login.live.com because it decided I needed to be redirected to login. Just to view a docs page.
It is even worse if you work for a large company with Office 365 that uses your organizations domain for authentication. I think there are about 6 redirects to get logged in. Even worse than that, they made us create a "personal" account with the exact same username for accessing MSDN because it wasn't compatible with our SSO at the time. So every time I log in, I have to type in my username, wait for the redirect, then choose personal account, wait for redirect, etc...
What is the alternative to javascript redirecting when you can't do it as the http response?
It spits out an HTML page with no body that solely does a Javascript redirect. Put it in the http response.
I don't know if this is still the case, but you couldn't login if you had 3rd party cookies disabled. Somewhere in the authentication phase, it would silently fail. No error message like incorrect username/password. You'd get kicked back to the login screen as if you just got there. It was a hassle trying to find exactly which cookies were necessary.
My citibank credit card redirects me to "cardservicesdirect.com.au" -- which reads like a phishing site if I've ever seen one.
I confirmed over the phone with their support that was indeed the correct site before typing anything into it.
I confirmed over the phone with their support that was indeed the correct site before typing anything into it.
My previous mortgage company was a subsidiary of CENLAR. So the corporate branding of the monthly bill listed x&y.com, the actual owner of the company was cenlar.com, and the mortage was paid at loanadministration.com, which until recently had minimal branding even tying it back to cenlar, let alone the company I ostensibly have the direct relationship with.
But did you call the support phone number shown on the dodgy domain?
T-Mobile called me back one time instead of me waiting on hold. This was after I went through the song and dance of giving the automated system my details. The first thing this representative wanted to do was, again, confirm I am who I said I was.
I said think about what you're asking for a second. Should I answer your questions? Couldn't get them to understand. Wound up hanging up and calling again and waiting on hold.
I said think about what you're asking for a second. Should I answer your questions? Couldn't get them to understand. Wound up hanging up and calling again and waiting on hold.
My bank actually gets this right. They very, very rarely call me, but when they do it's
"Hello, am I talking to Nick Lamb?" "Yes, this is me" "OK, I'm calling from Example Bank and our confirmatory password is Melons" [not the actual bank or password] "Thanks, that checks out, what can I do for you?"
This happened because I had one of those conversations you're talking about, and they were like "Aha! We have something we can do for those situations, call us and set a password we can use" so I hung up and sure enough they've used that password ever since. I like it.
It's not a _good_ password, but hey, how many times does anyone try the wrong one? Literally never. So it's good enough.
"Hello, am I talking to Nick Lamb?" "Yes, this is me" "OK, I'm calling from Example Bank and our confirmatory password is Melons" [not the actual bank or password] "Thanks, that checks out, what can I do for you?"
This happened because I had one of those conversations you're talking about, and they were like "Aha! We have something we can do for those situations, call us and set a password we can use" so I hung up and sure enough they've used that password ever since. I like it.
It's not a _good_ password, but hey, how many times does anyone try the wrong one? Literally never. So it's good enough.
This reminds me of something my local credit union used to do. They had something where you picked an image during signup that they would always show you during subsequent sign-ons so that you knew you were actually signing into their site.
This seems pointless because an attacker could just proxy the login back to your bank. Well, not pointless -- it raises the bar attackers have to pass -- but not a real solution. Or am I missing something?
Ha, same thing happened to me with Vodafone. Some guy called having some nice upgrade to my account. For some reason, to check something, he said, I need your online password. I said, wait, you call _me_ and want my password too? If I call you, tell I am from your bank and I need your PIN, would give it? Well no, came the reply. Then...
Obviously I terminated the conversation.
Obviously I terminated the conversation.
I hate it when someone calls me and asks me who I am. You called, you tell me who you want to talk to.
[deleted]
One of the worst I've seen is Franklin Templeton. They sent out snail mail telling everyone to go to a URL like "accountservices.biz" and reenter private information like your social security number in order to update your account records.
The site itself is branded just like Templeton's own site. From what I could gather, it is actually their site but even the whois is something non descript. Quite ridiculous. And of course they don't have any way whatsoever that I could find to report things like vulnerabilities or phishing attempts.
The site itself is branded just like Templeton's own site. From what I could gather, it is actually their site but even the whois is something non descript. Quite ridiculous. And of course they don't have any way whatsoever that I could find to report things like vulnerabilities or phishing attempts.
That would be a fascinating way to do a scam. Send snail mail to people directing them to a site that looks like a major company, ask them to enter in their PII and boom, there you go. Of course now you've committed untold amounts of federal crime by using the postal system and you'd definitely get sent to federal PMITA prison if you got caught. But I could definitely see this working on older people who, bless their little hearts, just don't know any better.
Citi has some really bad security practices, when I talked with them about it they mentioned some future changes they were planning that were even worse.
Citi just had a terrible IT team. Their website is always broken and their back end computer systems, until recently, were filled with reward loopholes.
What is the business reasoning behind this kind of domain name silliness?
I assume one team is responsible for the home page, and another team is responsible for the banking portal, and they can't be bothered to coordinate with each other.
I agree. There is no technical reason behind this sort of bollocks.
One day S&M will catch up and have a fit at the fragmented "front face" - quite right too. To be honest the board should also give a shit about their org's outward appearance.
Bit of a fail all 'round, really.
One day S&M will catch up and have a fit at the fragmented "front face" - quite right too. To be honest the board should also give a shit about their org's outward appearance.
Bit of a fail all 'round, really.
[deleted]
True true true. I know of some banks where invest.examplebank.com and bank.examplebank.com are controlled by mutually distrustful organizations. They really should put their stuff into the public suffix list at https://publicsuffix.org/, because, session cookies. But that would assume they knew something about what they were doing.
This makes sense but it seems to be bigger than that. For example, most companies with a major internet presence have a CDN on a totally separate domain, like "twimg.com", "chasecdn.com", etc. there must be a good technical reason for this, because everybody does it.
Or is that an unrelated thing?
Or is that an unrelated thing?
That's an unrelated thing.
By having CDN assets on a separate domain, you not only easily avoid accidentally sending any cookies along to the other domains (so if your CDN gets owned at least they aren't getting user credentials or session cookies), but it's also a small performance optimization as there are less things sent in the headers.
The important distinction is that the user should never ENTER any information onto those domains directly. They should be for displaying static resources only, so there is no need to "build trust" for them.
By having CDN assets on a separate domain, you not only easily avoid accidentally sending any cookies along to the other domains (so if your CDN gets owned at least they aren't getting user credentials or session cookies), but it's also a small performance optimization as there are less things sent in the headers.
The important distinction is that the user should never ENTER any information onto those domains directly. They should be for displaying static resources only, so there is no need to "build trust" for them.
I was looking up details of the new Microsoft Surface recently, so hit the top link in a google search which was (supposedly) on Microsoft.com
It wouldn’t load because Facebook.com was blocked and apparently they were doing a full redirect via fb. Crazy.
It wouldn’t load because Facebook.com was blocked and apparently they were doing a full redirect via fb. Crazy.
You didn't click on a search result, you clicked on an advertisement.
A good reason to use at the very least adblock.
And to avoid Microsoft edge. Why do I have to open Windows store for an add-on to my browser? Why can't I do it from the browser like in Mozilla Firefox or in Google Chrome?
I quite like Edge tbh. It's my main browser. Nearly a year now.
This may in fact be because Google lets advertisers set a totally different URL than the one that they actually direct you to, so that advertisers can implement various tracking schemes.
This is also exploited by malicious actors to occasionally buy out fake ads for amazon.com or bestbuy.com (or even, hilariously, youtube.com) which actually direct you to support scam websites claiming your computer is infected.
Google seems to have no desire to correct this by making their advertisements show you the actual URL are you going to be directed to.
Verify that any link you click on is not an ad. Always look for the first native result. The policies permitted around ads make them simply a security risk to click on.
This is also exploited by malicious actors to occasionally buy out fake ads for amazon.com or bestbuy.com (or even, hilariously, youtube.com) which actually direct you to support scam websites claiming your computer is infected.
Google seems to have no desire to correct this by making their advertisements show you the actual URL are you going to be directed to.
Verify that any link you click on is not an ad. Always look for the first native result. The policies permitted around ads make them simply a security risk to click on.
[deleted]
That is typical for organizations, where a DNS change takes weeks or months or isn't even possible, because of different legal entities. "Lets just register our own domain. Its faster...."
Having a bank as a current client, I am often joking about what would happen if Jeff Bezos takes control for a month. And when I am angry, I ask what would happen if Amazon or Google start selling credits or insurances, tomorrow.
Having a bank as a current client, I am often joking about what would happen if Jeff Bezos takes control for a month. And when I am angry, I ask what would happen if Amazon or Google start selling credits or insurances, tomorrow.
Ugh, MS just seem to get worse too, "Try our new login experience, it logs you out every 15 minutes, so much fun!".
[deleted]
[deleted]
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.
The future is here folks. And it sucks.
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!
So the passwords 'abc' 'ABC' and '222' are treated as equivalent. Try it out for fun!
What banks do this? AFAIK, Wells Fargo doesn't care about case-sensitivity but that's it.
that's disgusting :-/
[deleted]
/that noise when your head hits the desk
I don't want to enter my password on the phone, I have fingerprint or pin in mobile banking app.
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 :)
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 :)
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.
Source?
BMO in Canada forces 6 digits or alphanumerics as your account password. No more, no less.
What's worse, because it can be entered on the phone, aAbBcC are all == 1. So it's really just 6 digits.
What's worse, because it can be entered on the phone, aAbBcC are all == 1. So it's really just 6 digits.
Somewhere, in the background, there's a poor old unix mainframe running Cobol, unaware that the world around it has changed, and that it should put to pasture, where it can live out the rest of its days in peace.
I've heard of a bank actually trying to use that excuse when asked why their online banking passwords were so limited.
That is, of course, complete bullshit.
Sure, it is plausible that a bank has an old mainframe handling their accounts. It is also plausible that user account passwords on that old mainframe are only 6 or 8 characters and from a limited alphabet.
What does that have to do with customer online banking accounts? Nothing!
When you open a bank account they don't make a user account for you on their mainframe. What they make for you is an entry in an application database that their banking applications use. The only mainframe user accounts involved are the account that the database runs under and the account that the banking application runs under, both of which are the same for all banking customers.
Even if, for some strange reason, they do actually have to make a mainframe login account for each banking customer there is no reason for the banking customer to ever directly access that. Online banking is accessed through the web, so only the web server needs to access your banking account on the mainframe. They could make the website have its own password system, without the mainframe login restrictions. The restricted mainframe login information would only be known by the mainframe and the website back end. The banking customer should never deal with that.
That is, of course, complete bullshit.
Sure, it is plausible that a bank has an old mainframe handling their accounts. It is also plausible that user account passwords on that old mainframe are only 6 or 8 characters and from a limited alphabet.
What does that have to do with customer online banking accounts? Nothing!
When you open a bank account they don't make a user account for you on their mainframe. What they make for you is an entry in an application database that their banking applications use. The only mainframe user accounts involved are the account that the database runs under and the account that the banking application runs under, both of which are the same for all banking customers.
Even if, for some strange reason, they do actually have to make a mainframe login account for each banking customer there is no reason for the banking customer to ever directly access that. Online banking is accessed through the web, so only the web server needs to access your banking account on the mainframe. They could make the website have its own password system, without the mainframe login restrictions. The restricted mainframe login information would only be known by the mainframe and the website back end. The banking customer should never deal with that.
"Unix mainframe" is something that never really existed, mainframes run special operating systems like z/OS. (You can run SuSE on a virtual partition under z, but not natively, and it is a recent concept.)
Worse, it's probably an emulation of a Unix mainframe running the original Cobol code - with the emulator running in machine generated JavaScript in Nodejs on AWS...
(Obligatory xkcd comic: https://xkcd.com/1926/ )
(Obligatory xkcd comic: https://xkcd.com/1926/ )
No, more likely it's a newer IBM mainframe, as those are built to be backwards-compatible with software written back in the 60s.
A large bank in the uk runs their core software on AS400s emulating a 1401. Their ledger software is almost 60 years old.
I signed up for a US BMO account for the sign up bonus... Man is that bank's website bad. The version of jQuery they are using is from 2008 (1.3xx IIRC) and they give you a pop-up if you try to right click saying "right-click has been disabled for security purposes."
To be fair though, at least they offer the guarantee that if your online banking is hacked they will reimburse 100%. Though not sure how truthful it is having never needed it.
https://i.imgur.com/O2eOwLw.jpg
Edit:
"You may be liable for all losses from unauthorized use of your Account if you:
contributed to its unauthorized use; used a PIN combination selected from your name, telephone number, date of birth, address, or Social Insurance Number; did not use reasonable care to safeguard your Secret ID Code; did not keep your Secret ID Code separate from your Card; did not comply with your reporting obligations in Section 11 of this Agreement unless there were exceptional circumstances for your failure to do so; or shared a mobile device that you registered with us for Electronic Banking Services. In those cases, your liability may exceed the funds in an Account, your credit limit or any daily transaction limits. In other words, your liability will not be limited by your Account balance, your credit limit or any daily transaction limits. You must cooperate and assist in any investigation that we initiate into the unauthorized use you reported, which is a precondition to being reimbursed for any losses. This cooperation may include filing a report with law enforcement authorities."
Overall seems fair enough protection.
https://i.imgur.com/O2eOwLw.jpg
Edit:
"You may be liable for all losses from unauthorized use of your Account if you:
contributed to its unauthorized use; used a PIN combination selected from your name, telephone number, date of birth, address, or Social Insurance Number; did not use reasonable care to safeguard your Secret ID Code; did not keep your Secret ID Code separate from your Card; did not comply with your reporting obligations in Section 11 of this Agreement unless there were exceptional circumstances for your failure to do so; or shared a mobile device that you registered with us for Electronic Banking Services. In those cases, your liability may exceed the funds in an Account, your credit limit or any daily transaction limits. In other words, your liability will not be limited by your Account balance, your credit limit or any daily transaction limits. You must cooperate and assist in any investigation that we initiate into the unauthorized use you reported, which is a precondition to being reimbursed for any losses. This cooperation may include filing a report with law enforcement authorities."
Overall seems fair enough protection.
Ok this sounds like a terrible question but how do they stop people from "hacking" themselves...
How do insurance companies stop people from emptying their house and then burning it down? How do brick and mortars prevent people from paying with photocopied money? It is fraud, and it is generally illegal. Huge amounts of money is spent on detecting and deferring fraud attempts.
It's entirely possible to claim your card was skimmed and have your bank refund the money. However, if they then find out that the ATM used to withdraw your entire balance is the same ATM you've used for years, and your face is on the ATMs security camera at the time of withdraw, then you're in for a world of hurt.
It's entirely possible to claim your card was skimmed and have your bank refund the money. However, if they then find out that the ATM used to withdraw your entire balance is the same ATM you've used for years, and your face is on the ATMs security camera at the time of withdraw, then you're in for a world of hurt.
You basically need to file a police report about the theft, and the bank will probably know where the money was sent/spent, and the police ideally would investigate and subpoena the records of wherever the money went and presumably discover if it goes back to you somehow. The first liability thing says you cannot have "contributed to its unauthorized use". I mean realistically someone could possibly do it and get away with it, but I mean people could realistically do many types of fraud. Most could realistically probably get away with it. It's more a guarantee to people that if they get hacked somehow other then giving naughty little Johnny/vindictive ex Jane the bank card and pin, they can get their money back.
Insurance fraud is illegal; you can go to jail for it.
I think I'd rather risk some money to hacks on an otherwise more secure system than look forward to whatever hellish phone support calls and hoop-jumping I expect I'd have to go through to get charges reversed.
It just took my terrible python program 9 seconds to guess 999999.
> my bank has a max password length of 12
Look at Mr. PrivateBanking over there, my one is 5. Amount in words : Five.
And that is after they updated all their software and moved to a new datacenter and everything recently.
Granted I have a hardware dongle to authenticate any transactions, but to gain access to all my information, five characters is all the protection they wish to offer...
Look at Mr. PrivateBanking over there, my one is 5. Amount in words : Five.
And that is after they updated all their software and moved to a new datacenter and everything recently.
Granted I have a hardware dongle to authenticate any transactions, but to gain access to all my information, five characters is all the protection they wish to offer...
I played Eve online for a while.
My corp (guild for non-Eve players) had a better and more secure login & SSO system than either my bank or my employer. My employer has replaced their SSO system by now, but my bank is still in the 90s.
My corp (guild for non-Eve players) had a better and more secure login & SSO system than either my bank or my employer. My employer has replaced their SSO system by now, but my bank is still in the 90s.
Your bank password is probably not even case sensitive: http://www.zdnet.com/article/surprise-online-bank-passwords-...
Offenders: Wells Fargo, Chase, American Express, Fidelity, ....
Offenders: Wells Fargo, Chase, American Express, Fidelity, ....
I know of at least one bank that requires your password to have exactly one digit. Not one or more, exactly one.
"The future is already here — it's just not very evenly distributed." - William Gibson
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.
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.
For some dumb reason the Bank of America website is ok with firefox on windows, but throws up a big red error message when you try to use firefox on mac.
https://www.bankofamerica.com/information/supported-browsers...
https://www.bankofamerica.com/information/supported-browsers...
Oh, God yes - the same on Linux. I'm thinking that what I ought to do is go down to my local BoA branch and discuss (and demonstrate!) this to their branch manager. I can't help but feel I'd just get a brush-off if I tried to deal with this online or over the phone.
When I worked for Chase on their main app, the policy for support was the current version of the browser, minus one.
To be fair Chase seems (on the surface) to have the best site/app/whatever of the major US banks.
The app is pretty great.
The app is pretty great.
Chase doesn't like chromium. It'll randomly load a mobile page if your user agent string is chromium. Not to mention, none of the US banks allow standard 2FA (TOTP). If they have 2FA at all, it'll be SMS.
I think there’s some way to get a hardware token from Chase (no idea who you’d call about that) but you’re right, that part annoys me.
Except for the unnecessary 5 second wait when accessing chase.com for the login prompt to appear.
I just go direct to chaseonline.chase.com .
It’s not pretty but it’s quick. :)
It’s not pretty but it’s quick. :)
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.
"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.
I'm sure that has been said by some manager somewhere.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Authority is a bad thing here, since the person who spoke to him is in a shadow of his own tech team authority. Don’t get me wrong, but if there is an objective security/xyz problem, then it doesn’t matter who’s reporting it and what does he make for a living.
I've never heard of him, and probably so haven't a lot of people on Twitter. I don't see why we should give him authority
shak77(2)
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.
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.
And it's so easy for anyone nowadays to get SSL with Let's Encrypt...
I remember a few years ago when there was no way you could do it for side projects because certs were 100/yr., now they're free.
I remember a few years ago when there was no way you could do it for side projects because certs were 100/yr., now they're free.
It is not easy if you are on a shared domain and it is not supported by your host. Please don't run around saying it is easy for everyone.
If you're on a host that doesn't support HTTPS, you should probably find a different one.
I have a shared hosting provider that lets me use Let's Encrypt certs on any of my domains through CPanel even.
For anyone interested :
http://buyshared.net
I'm only a customer for small niche sites, not associated in any other way, works fine enough for my needs.
For anyone interested :
http://buyshared.net
I'm only a customer for small niche sites, not associated in any other way, works fine enough for my needs.
Same with webfaction and I expect pretty much all non-shit hosts.
Only annoyance (at least with webfaction) is that they don't currently support letsencrypt auto-renewal, so you have to remember to update your cert manually every 12 weeks.
Only annoyance (at least with webfaction) is that they don't currently support letsencrypt auto-renewal, so you have to remember to update your cert manually every 12 weeks.
Cloudflare has you covered here. If you don't like them, there are many other options as well. If you have anything more important than a blog that doesn't have https enabled, you need to rethink how you're doing things.
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.
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.
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.
I took as more of a "if troy is pissed at someone, then everyone knows the person he's pissed at is hackable" statement.
Flagged hey? I'm serious, look at his LinkedIn if you don't believe me. His professional title is PluralSight author which he put on his senate inquiry docs. His CV for that was his LinkedIn page
The funny thing is, checking their web site they still haven't managed to secure their landing page. You'd think they'd get the message when everyone's just laughing at them...
To play devil's advocate:
everyone = Hacker News
Mostly likely not their customers; whom they have a vested interest in keeping money with.
everyone = Hacker News
Mostly likely not their customers; whom they have a vested interest in keeping money with.
True.
My care factor is probably very different to most non techies, by assumption. Then again, there's probably a bunch of things I do that would annoy(?) {them} greatly - that I'm not even aware of.
My care factor is probably very different to most non techies, by assumption. Then again, there's probably a bunch of things I do that would annoy(?) {them} greatly - that I'm not even aware of.
Here's the story: https://arstechnica.com/information-technology/2017/03/firef...
Isn't (not) needing HTTPs kind of unrelated to your database being pwned though?
The person who owned the website said this:
> We have our own security system, and it has never been breached in more than 15 years.
Which leads me to believe that their system was built by scratch, in PHP, 15 years ago, and hasn't been updated since.
> We have our own security system, and it has never been breached in more than 15 years.
Which leads me to believe that their system was built by scratch, in PHP, 15 years ago, and hasn't been updated since.
And that they have no monitoring to detect breaches.
No Troy and co do not work like that - per se. What is most likely is that someone noticed the public discussion and took advantage. I see where you are coming from but the fix was easy and wasting time whining about being called out on rubbish practice was the wrong response.
Besides, if the DB was pwned, it is unlikely that http -> https would have any real bearing anyway. There was probably a XSS exploit or whatever.
Besides, if the DB was pwned, it is unlikely that http -> https would have any real bearing anyway. There was probably a XSS exploit or whatever.
I think in this case it's some kind of a broken window theory.
If you don't think HTTPS is important you're probably not worried about SQL injection either.
If you don't think HTTPS is important you're probably not worried about SQL injection either.
It was some big oil company, blaming Mozilla for the NotSecure tag near input boxes.
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.
Actually that is a smart thing to do in it's own right, as long as they quickly move to https.
Not even predicated on HTTPS; owning more domains helps combat some obvious forms of fraud. Though, really, I agree that HTTPS is more important.
> Not even predicated on HTTPS
Sorry that's what I meant. Both moves are smart. Doing both is smartest.
Sorry that's what I meant. Both moves are smart. Doing both is smartest.
Well, they probably got a process for buying domains, but changing the websites architecture requires a project/task-force/whatever, which can't be set up so quickly (I'm just guessing).
> Alarmingly though, nw0lb.com is still available as is nuu0lb.com and it-doesnt-matter-because-that-isnt-the-point.com.
My sides.
My sides.
Yep. I laughed out loud in an empty room at that one.
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.
When I was with Three they had a phone password which was not the same password as my online account password. I have nothing informed to say on the security of this approach, other than that asking customers for their online account password would be completely unacceptable in all circumstances, and shouldn't even be helpful because as we all know passwords should not be stored in a reversible format.
Giving them the benefit of the doubt, if they're asking for a phone password, hopefully they're just keying it into their systems for verification against a hash, not manually comparing to a plaintext copy.
> 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.
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.
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.
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.
I think it's not just the UK. In fact, in many countries you don't have enough protections for security researchers. So no one bothers reporting these things because it would get you in trouble.
I'm with Three and I've not encountered that. That's terrible and I'll probably change my password.
But Nationwide is pretty good for banking.
But Nationwide is pretty good for banking.
I've had to deal with the call-in support twice in last 6 months and each time I was asked for my actual password (no one asked me for any 'telephone password' but I don't have one and even if I would, I wouldn't tell it to anyone either). Given I wasn't inclined to do so, after trying to explain how wrong this practice is, trying to escalate it, in the end I've meet the similar wall of 'we are sorry you feel this way, can we help you with something else?'.
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.
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.
Until I'm sure the other person doesn't know what they're talking about, I try and assume they're right.
Unfortunately, you're a minority in this.
The problem is that for all of the stereotypes to the contrary, tech is really full of people who worry, "Am I wrong? Am I the idiot?" Banks clearly don't attract the same kind of person, with the same intellectual gifts and challenges. Your advice is great, but it's probably already being taken to a fault by people like Troy Hunt, and people like the goober on the other end of the line think Dunning-Kruger is a brand of champagne.
"think Dunning-Kruger is a brand of champagne."
Oh bollocks, that's me undone. Err without Googling and being British and given where I am and a few other things, I'm going to go for ... ... firearm?
Simplistic analysis by me: Well it can't likely be a Champagne (French). Dunning (English), Kruger (German with options).
OK Goo ... https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect - hmmm 8)
Oh bollocks, that's me undone. Err without Googling and being British and given where I am and a few other things, I'm going to go for ... ... firearm?
Simplistic analysis by me: Well it can't likely be a Champagne (French). Dunning (English), Kruger (German with options).
OK Goo ... https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect - hmmm 8)
The most important scientific mindset is being willing and able to prove yourself wrong.
It's an important legal mindset, too, because it's an important mindset for any honest debater: You prepare an argument by attacking it, and trying your damndest to be the best argument for the opposition you can possibly be.
That's important in moral issues, where there arguably is no "right answer" to certain questions, but it's vital when things come down to factual questions where one position is right, any other position is wrong, and being able to recognize when you're holding a position which is wrong is vital to being honest, not only with others but with yourself.
It's an important legal mindset, too, because it's an important mindset for any honest debater: You prepare an argument by attacking it, and trying your damndest to be the best argument for the opposition you can possibly be.
That's important in moral issues, where there arguably is no "right answer" to certain questions, but it's vital when things come down to factual questions where one position is right, any other position is wrong, and being able to recognize when you're holding a position which is wrong is vital to being honest, not only with others but with yourself.
> 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.
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.
The only expectation was an escalation.
Thank you, voice of reason.
>you could go register nuuolb.com right now
Not anymore!
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?
Not anymore!
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?
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?!
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.
So I would advise you not to do it.
Do you have any examples of "You might get sued for this"?
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/
1: http://nissan.com/
[deleted]
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.
I can also get "complex web design" for $100 per hour from them. Judging by the quality of that site, I might pass.
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.
It says copyright 2016 on it...
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... :)
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... :)
Shhh... don't tell them about `new Date()`
that sounds unfair.
To be fair, it was more of a joke but this is a really good point. I wasn't intending to do it but thank you for the warning!
This is mentioned in the article. He also mentioned they didn't buy nw0lb.com and some other domains.
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/encr...
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."
[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."
Couldn't "private" also not mean "private"? For instance: when you're on Facebook, couldn't people think they are exchanging private messages because the address bar says "private"?
"secure" means "secure connection" to me, and it sounds perfectly appropriate. Maybe you can't find a better term for "secure" because it's perfectly fine, already..?
"secure" means "secure connection" to me, and it sounds perfectly appropriate. Maybe you can't find a better term for "secure" because it's perfectly fine, already..?
> Maybe you can't find a better term for "secure" because it's perfectly fine, already..?
Could be! Someone else suggested "Encrypted", seems like a good word. I really don't know.
Could be! Someone else suggested "Encrypted", seems like a good word. I really don't know.
If you're looking to be user-friendly, I'm not sure "encrypted" would work, because many people aren't going to know what it means.
I'm thinking specially in its inactive "not encrypted" version, where people aren't going to appreciate the gravity of a page being "not encrypted".
I bet the folks at Google already thought about this through.
I'm thinking specially in its inactive "not encrypted" version, where people aren't going to appreciate the gravity of a page being "not encrypted".
I bet the folks at Google already thought about this through.
This is bikeshedding. The only users who would be able to distinguish the meaning of "secure" and "private" in their address bar are people who already understand what https is and isn't.
This was an honest question, really. I didn't say I had the right answer, I was wondering why they chose "Secure"
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...
Perhaps the reverse would be better. If a site doesn't use HTTPS, call it unsecured.
This is expected to be the long term outcome of (at least) Google and Mozilla's current trajectory.
Google specifically says (without naming a date) that their long term intent is to put a UI like a red triangle plus the phrase "Not Secure" in the URL bar for all HTTP sites on their desktop browser. This is the same treatment you get today for a site with a bogus SSL certificate and similar to the treatment HTTP sites get now in Incognito mode.
Google specifically says (without naming a date) that their long term intent is to put a UI like a red triangle plus the phrase "Not Secure" in the URL bar for all HTTP sites on their desktop browser. This is the same treatment you get today for a site with a bogus SSL certificate and similar to the treatment HTTP sites get now in Incognito mode.
How about all it really means? "Encrypted"
HTTPS means more than just encryption. There is also authentication and integrity guarantees in SSL.
That's my point. There is no guarantee about authenticity. Anyone can register a domain and have an SSL cert from Let's Encrypt in less than 15 minutes.
The only thing that HTTPS guarantees is that you are communicating securely with the person that owns the domain. That's it.
The only thing that HTTPS guarantees is that you are communicating securely with the person that owns the domain. That's it.
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/
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.
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.
ESL, myself, but I wouldn't know if Encrypted makes a lot of sense for non-technical users?
Google likes https for their own selfish reasons. Yes, it's still a good thing. But what Google really likes is that it keeps ISPs, hotspot operators, and others from enjoying the same ubiquitous traffic snooping they get via AdSense, Google Analytics, Android, Chrome, their CDN, etc.
It's nice that their goals align with something actually helpful. But don't mistake the motive. This extends their dominance in global snooping.
It's nice that their goals align with something actually helpful. But don't mistake the motive. This extends their dominance in global snooping.
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.
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.
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
[2] http://financial-ombudsman.org.uk/consumer/complaints.htm
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
[2] http://financial-ombudsman.org.uk/consumer/complaints.htm
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.
Only then we can have 100% of the web encrypted.
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
[1] https://hstspreload.org/
[2] https://security.googleblog.com/2017/09/broadening-hsts-to-s...
[0] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
[1] https://hstspreload.org/
[2] https://security.googleblog.com/2017/09/broadening-hsts-to-s...
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.
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.
Using a TXT record for this purpose would achieve nothing. Just like an SSLStrip attack would strip 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.
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.
While I understand why HSTS makes sense I hate it and I think it comes from poorly tooling around it. Two examples:
1. HSTS Preload: I am not 100% sure but, AFAIK your browser gets the list once during installation and then sticks with it until he receives another software update. I think the list should be dynamic (e.g. like adblock lists). That way even older browsers would have an up-to-date HSTS Preload list.
2. Like everything else HSTS records have a lifetime, but when you use your dev-tools to delete your browser cache it doesn't delete the HSTS information. So every time you want to delete them you have to go to some net-internals... browser configuration to explicitly delete a HSTS record for a specific domain. It's even easier to delete serviceworkers...
For a long time I also didn't like that you could not easily remove your own domain from a preload list, but that fortunately changed and now there is a website where you can easily request to be deleted from the preload lists. The only hitch here is that as it takes a few month until every browser on this planet got a software update the new list will also have to wait for a while: https://hstspreload.org/removal/
1. HSTS Preload: I am not 100% sure but, AFAIK your browser gets the list once during installation and then sticks with it until he receives another software update. I think the list should be dynamic (e.g. like adblock lists). That way even older browsers would have an up-to-date HSTS Preload list.
2. Like everything else HSTS records have a lifetime, but when you use your dev-tools to delete your browser cache it doesn't delete the HSTS information. So every time you want to delete them you have to go to some net-internals... browser configuration to explicitly delete a HSTS record for a specific domain. It's even easier to delete serviceworkers...
For a long time I also didn't like that you could not easily remove your own domain from a preload list, but that fortunately changed and now there is a website where you can easily request to be deleted from the preload lists. The only hitch here is that as it takes a few month until every browser on this planet got a software update the new list will also have to wait for a while: https://hstspreload.org/removal/
There were a lot of complaints about Google doing that with .dev given the number of other companies and developers that use .dev for random LAN things, but an HSTS Preload for random LAN things isn't a bad idea in that it can prevent some types of mistakes going to production like bad HTTPS->HTTP redirects in an application. Obviously, Google themselves thought it a good idea to test that in their development environments.
The people doing random things with fake .dev domains were going to get bit in the ass one way or another. You can't just make up your own domain and hope no one ever does anything conflicting with it.
> You can't just make up your own domain and hope no one ever does anything conflicting with it.
Actually you can! You just need to use one reserved for that purpose:
> In 1999, the Internet Engineering Task Force reserved the DNS labels example, invalid, localhost, and test so that they may not be installed into the root zone of the Domain Name System.
https://en.wikipedia.org/wiki/.test
Actually you can! You just need to use one reserved for that purpose:
> In 1999, the Internet Engineering Task Force reserved the DNS labels example, invalid, localhost, and test so that they may not be installed into the root zone of the Domain Name System.
https://en.wikipedia.org/wiki/.test
Sure, but you should NEVER use a domain that isn’t delegated to you or explicitly reserved by the IANA for local purposes. Plenty of people used .int as well which is now a gTLD, you can’t complain about a name you don’t own breaking down the line.
Yeah, until that happens we won't ever be really secure.
I mean, take this case; lets say NatWest DID put their landing page behind SSL... well, lots of people are going to try to go to http://<url> instead of https://<url>. Most site will redirect the user to the https version, but if an attacker hijacks the initial request, they could easily serve up a fake version of the landing page that has a 'login' link to the malicious site.
Now, at least if NatWest was redirecting http to https, a savvy user could notice that their session wasn't being redirected to https and could be aware something was wrong, but if you didn't know to check, you could be fooled.
There is nothing the site owner can do to prevent that sort of hijacking.
I mean, take this case; lets say NatWest DID put their landing page behind SSL... well, lots of people are going to try to go to http://<url> instead of https://<url>. Most site will redirect the user to the https version, but if an attacker hijacks the initial request, they could easily serve up a fake version of the landing page that has a 'login' link to the malicious site.
Now, at least if NatWest was redirecting http to https, a savvy user could notice that their session wasn't being redirected to https and could be aware something was wrong, but if you didn't know to check, you could be fooled.
There is nothing the site owner can do to prevent that sort of hijacking.
HSTS Preloading solves that problem.
Huh, didn't know about that. Glad to see.
At that point, will we start seeing attackers targeting DNS instead?
You need to get to global DNS to get a valid cert. When certificate transparency logs become mandatory, that case will be detectable though not preventable.
Surely good enough detection is just one step from prevention? Detect fraudulent cert, revoke it. Or have I missed a layer?
Certainly, but depending on the type of attack, that might not be of much use. In a targeted attack, the damage might already be done by the time the certificate is detected. Additionally, revocation as a whole is broken in various ways[1], not to mention that even with hard-fail revocation checking[2], you have a window of several days during which you can staple a "good" OCSP response, from before the certificate was revoked. (The exact lifetime is up to the CA - I think the maximum allowed is 7 or 10 days.)
CT, as currently implemented, is good at two things: Detecting misbehaving CAs, and detecting certificates issued by attackers after a server is compromised or domain is hijacked, assuming the domain owner is monitoring logs for such certificates. The Web PKI does not provide many tools that actually mitigate damage for the second scenario (unless you've deployed HPKP, which is on its way out).
[1]: https://www.imperialviolet.org/2014/04/29/revocationagain.ht...
[2]: Practically no mainstream browser uses hard-failing OCSP. Firefox supports the X.509 Must-Staple extension, which enables hard-failing OCSP, but Must-Staple has a glaring hole: If the attacker gains the ability to issue a certificate for the targeted domain, they can simply request a certificate without the Must-Staple extension. Must-Staple's usefulness is mostly limited to key-compromise scenarios.
CT, as currently implemented, is good at two things: Detecting misbehaving CAs, and detecting certificates issued by attackers after a server is compromised or domain is hijacked, assuming the domain owner is monitoring logs for such certificates. The Web PKI does not provide many tools that actually mitigate damage for the second scenario (unless you've deployed HPKP, which is on its way out).
[1]: https://www.imperialviolet.org/2014/04/29/revocationagain.ht...
[2]: Practically no mainstream browser uses hard-failing OCSP. Firefox supports the X.509 Must-Staple extension, which enables hard-failing OCSP, but Must-Staple has a glaring hole: If the attacker gains the ability to issue a certificate for the targeted domain, they can simply request a certificate without the Must-Staple extension. Must-Staple's usefulness is mostly limited to key-compromise scenarios.
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.
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.
In the UK there are major ecommerce sites still on HTTP.
Major sites, really?
marksandspencer.com
very.co.uk
asos.com
next.co.uk
and many more.
and many more.
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 ;)
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 ;)
> 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.
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.
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.
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.
> 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.
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.
Well... you didn't read the article, did you?...
> 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.
Please understand that you are wrong here.
You need to go and read the article, and then perhaps some more writing around why it's important for the whole site to be served over TLS.
Once you can read and understand the linked article and why what was described is a real issue you will no-longer sound like you don't know what you're talking about on the Internet.
> I'm just not one of these people who think there are armies of people at the NSA/GCHQ spying on me.
This isn't about NSA/GCHQ, it's about "bad actors". Which bad actors are relevant depends on your circumstances. It's quite likely that the bad actors in the case of maliciously tampering with the login links of a bank, or the link a checkout process on an e-commerce site will not be a government entity, but a criminal operation.
> I'm also against forcing every website in the world onto https.
It's really not that hard to implement TLS on the average website, and the benefits are great.
However the main focus of this article was about TLS on sites that link to sensitive information, such as banks.
> Doing so will significantly raise the bar of accessibility for tinkerers and makers.
There's two things wrong here.
1. It's really not raising the bar very high. Lets encrypt is easy to use, and as a member of a hackspace myself I know that most people there could use it, or get help using it.
2. Just because some "tinkerers and makers" may struggle with some aspect of security doesn't mean that e-commerce sites or banks etc. need to downgrade their security, or that the rest of us need to suffer.
> 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?
This is a straw man argument. We're not talking about, and likely don't care about, your coffee pot.
We do however care about not having our personal data intercepted, our identities stolen, our credit card data misused, or ourselves be profiled etc. All concerns with things like e-commerce, bank, news sites etc. etc.
> 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.
Ultimately this may happen in the interests of everyone's online safety, and when it does there won't be some sort of "end of times" scenario where coffee pot sites are dissapeared from the Internet, people will just move to use TLS on them.
> 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.
Yes, and it's typical of banks to get this aspect of security wrong, however it's still better than not having TLS, and at this point you're just going to have to go and work out why yourself because I have other stuff to do.
> [1] Apparently this was a thing once ;)
Yes, it famously was: https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot
Please understand that you are wrong here.
You need to go and read the article, and then perhaps some more writing around why it's important for the whole site to be served over TLS.
Once you can read and understand the linked article and why what was described is a real issue you will no-longer sound like you don't know what you're talking about on the Internet.
> I'm just not one of these people who think there are armies of people at the NSA/GCHQ spying on me.
This isn't about NSA/GCHQ, it's about "bad actors". Which bad actors are relevant depends on your circumstances. It's quite likely that the bad actors in the case of maliciously tampering with the login links of a bank, or the link a checkout process on an e-commerce site will not be a government entity, but a criminal operation.
> I'm also against forcing every website in the world onto https.
It's really not that hard to implement TLS on the average website, and the benefits are great.
However the main focus of this article was about TLS on sites that link to sensitive information, such as banks.
> Doing so will significantly raise the bar of accessibility for tinkerers and makers.
There's two things wrong here.
1. It's really not raising the bar very high. Lets encrypt is easy to use, and as a member of a hackspace myself I know that most people there could use it, or get help using it.
2. Just because some "tinkerers and makers" may struggle with some aspect of security doesn't mean that e-commerce sites or banks etc. need to downgrade their security, or that the rest of us need to suffer.
> 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?
This is a straw man argument. We're not talking about, and likely don't care about, your coffee pot.
We do however care about not having our personal data intercepted, our identities stolen, our credit card data misused, or ourselves be profiled etc. All concerns with things like e-commerce, bank, news sites etc. etc.
> 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.
Ultimately this may happen in the interests of everyone's online safety, and when it does there won't be some sort of "end of times" scenario where coffee pot sites are dissapeared from the Internet, people will just move to use TLS on them.
> 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.
Yes, and it's typical of banks to get this aspect of security wrong, however it's still better than not having TLS, and at this point you're just going to have to go and work out why yourself because I have other stuff to do.
> [1] Apparently this was a thing once ;)
Yes, it famously was: https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot
> Yes, it famously was: https://en.wikipedia.org/wiki/Trojan_Room_coffee_pot
Of course it was. Hence me using it in my 'straw-man' argument. Maybe I was too subtle.
You still haven't convinced me why I should move everything to TLS. Also, I do doubt you have other stuff to do, seeing as you answered my post, point by point...
Yes there are 'bad actors' but lets not get too paranoid here. We can't wrap everything up in TLS cottonwool.... where does it stop? Are we all too afraid to leave our houses without 'security' ? Do we now talk in code in public just. in. case. someone is overhearing what we say?
Of course it was. Hence me using it in my 'straw-man' argument. Maybe I was too subtle.
You still haven't convinced me why I should move everything to TLS. Also, I do doubt you have other stuff to do, seeing as you answered my post, point by point...
Yes there are 'bad actors' but lets not get too paranoid here. We can't wrap everything up in TLS cottonwool.... where does it stop? Are we all too afraid to leave our houses without 'security' ? Do we now talk in code in public just. in. case. someone is overhearing what we say?
> You still haven't convinced me why I should move everything to TLS.
I don't need to, you can head off into the world believing what you want. You are however very wrong on this. Wether you decide you are going to continue to be wrong is of course up to you. I don't know you, do what you want.
> Also, I do doubt you have other stuff to do, seeing as you answered my post, point by point...
And I took time out of my day to do so, and yes, I do have other stuff to do.
> Yes there are 'bad actors' but lets not get too paranoid here. We can't wrap everything up in TLS cottonwool....
Taking adequate and proportional steps to secure our data, our identities and our money is not "wrapping everything up in cotton wool".
Risk and security are a sliding scale, we don't need to only talk about the extremes.
> where does it stop? Are we all too afraid to leave our houses without 'security' ? Do we now talk in code in public just. in. case. someone is overhearing what we say?
Another straw man argument, but just for fun:
> Are we all too afraid to leave our houses without 'security' ?
No would be the general answer, but it's going to depend on what your risks are. Who you are, where you live etc.
> Do we now talk in code in public just. in. case. someone is overhearing what we say?
Again, generally no. However if we have something that we want kept private we do either talk in code, or we wait until a more opportune moment.
I don't need to, you can head off into the world believing what you want. You are however very wrong on this. Wether you decide you are going to continue to be wrong is of course up to you. I don't know you, do what you want.
> Also, I do doubt you have other stuff to do, seeing as you answered my post, point by point...
And I took time out of my day to do so, and yes, I do have other stuff to do.
> Yes there are 'bad actors' but lets not get too paranoid here. We can't wrap everything up in TLS cottonwool....
Taking adequate and proportional steps to secure our data, our identities and our money is not "wrapping everything up in cotton wool".
Risk and security are a sliding scale, we don't need to only talk about the extremes.
> where does it stop? Are we all too afraid to leave our houses without 'security' ? Do we now talk in code in public just. in. case. someone is overhearing what we say?
Another straw man argument, but just for fun:
> Are we all too afraid to leave our houses without 'security' ?
No would be the general answer, but it's going to depend on what your risks are. Who you are, where you live etc.
> Do we now talk in code in public just. in. case. someone is overhearing what we say?
Again, generally no. However if we have something that we want kept private we do either talk in code, or we wait until a more opportune moment.
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.
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.
> 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!"
I can just imagine NatWest: "Oh, is that the problem? Ah, ok, well, let's just go get that domain then. Sorted!"
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.
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.
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
[2] https://www.starlingbank.com
[3] https://www.atombank.co.uk
[4] https://www.tandem.co.uk
[5] http://blog.softwareverify.com/list-of-uk-banks-that-are-sec...
[6] https://twitter.com/softwareverify/status/940961044633149440
Apparently 35% of all UK banks have insecure landing pages. [5][6]
[1] https://monzo.com
[2] https://www.starlingbank.com
[3] https://www.atombank.co.uk
[4] https://www.tandem.co.uk
[5] http://blog.softwareverify.com/list-of-uk-banks-that-are-sec...
[6] https://twitter.com/softwareverify/status/940961044633149440
> Hopefully their mobile apps use HTTPS for everything too?
Well, HSBC's didn't: https://threatpost.com/banking-apps-found-vulnerable-to-mitm...
Well, HSBC's didn't: https://threatpost.com/banking-apps-found-vulnerable-to-mitm...
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.
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.
NatWest is also guilty of storing passwords in plain text: their login page says 'enter the 5th, 8th and 12th character of your password'
Who's to say they haven't just hashed each individual character of the password?
If you're storing individually hashed characters:
a: 0CC175B9C0F1B6A831C399E269772661
b: 92EB5FFEE6AE2FEC3AD71C777531578F
c: 4A8A08F09D37B73795649038408B5F33
etc.
then this is basically the same as storing the plaintext characters because as long as you know the hashing algorithm you can generate a pretty small map of hash -> original character and convert back.
a: 0CC175B9C0F1B6A831C399E269772661
b: 92EB5FFEE6AE2FEC3AD71C777531578F
c: 4A8A08F09D37B73795649038408B5F33
etc.
then this is basically the same as storing the plaintext characters because as long as you know the hashing algorithm you can generate a pretty small map of hash -> original character and convert back.
To be fair we can't be 100% sure of that. It is possible they simply hash all the combinations they are going to show you. Could also be stored in an HSM making it a bit more secure.
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.
I think the attitude here is kind of douche.
There need to be a public directory for these websites. Something similar to 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..
Ridiculous password policy, http home page, virtual keyboard for password, loading javascript from http and what not..
Perhaps something like https://securethe.news/sites/ but for every website, not just news sites?
Thanks for the link!
Yes, would love to have one for every website. And visitor can input a website for "stupidness"
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.
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.
Scotiabank, one of the biggest banks in Canada, has the same issue:
http://www.scotiabank.com/ca/en/0,,2,00.html
Didn't find any contact to report it. Is Twitter really the right place?
http://www.scotiabank.com/ca/en/0,,2,00.html
Didn't find any contact to report it. Is Twitter really the right place?
Note that https://personal.natwest.com/ 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're trusting (and have a plausible way to check who it belongs to) but that is not the real world.
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.
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.
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.
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.
Could be worse; could be @taviso.
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 "all pages should be HTTPS" since 2010 or something?
It looks like some markets have gotten the message more quickly than others.
I'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've ever used.
it-doesnt-matter-because-that-isnt-the-point.com
What is the point?
Buying every domain name that could possibly be confused with yours would be unnecessary in this context if you fixed the issue of an attacker being able to redirect to another name.
(Banks should also protect against easily phishable domain names but that's a also losing game, and in that case the technical solution is not as simple or complete).
(Banks should also protect against easily phishable domain names but that's a also losing game, and in that case the technical solution is not as simple or complete).
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.
[deleted]
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.
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.
There are plenty of people accessing their banks on public / insecure networks; it’s folly to assume that MITM attacks just can’t happen. You yourself might not be at risk, but you’re not the only person out there.
The assumption is that yes, all of your machine’s updates are served over HTTPS. If they weren’t, then of course you’re right - it’d be possible to hijack your machine by serving malicious binaries. That’d be one hell of a security hole.
The assumption is that yes, all of your machine’s updates are served over HTTPS. If they weren’t, then of course you’re right - it’d be possible to hijack your machine by serving malicious binaries. That’d be one hell of a security hole.
I stated specifically that I agree it is bad in situations where you could be MITM. I also agree many people do that. My question here is only how it could effect me or people who follow the practice I follow.
Your assumption that there is such a thing as a "secure network" is foolish. ISPs inject vulnerable javascript into pages, ISPs have vulnerable routers, ISPs have bad passwords on their devices, ISPs have criminals on staff, ISPs run traffic through unencrypted microwave links that anyone close to the beam can listen in to, ISPs have devices running in remote locations, ... and your traffic is going to run through who knows how many ISPs, possibly even through other countries, ... in short, it simply doesn't make sense to build anything on the assumption that the network is secure.
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.
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." ?
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." ?
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.
With the layman example, you are describing man in the browser attack. It doesn't matter if you use wireless or not.
[deleted]
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?
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.
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.
[deleted]
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?
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?
> 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.
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.
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).
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).
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.
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.
Which is why certrificate transparency is coming, so those will be distrusted ASAP.
> valid certificate
> fake CA
Pick one. If your cert isn't signed by a CA that the browser trusts, it won't load the page.
> fake CA
Pick one. If your cert isn't signed by a CA that the browser trusts, it won't load the page.
The browser would still need to trust the fake CA, which means pwning the victim's computer i.e. it's already game over at that point.
No, the whole point of TLS is that you don't have to trust the network. At all.
Nope, you can MITM the HTTP-only landing page so the link to the login page takes you to a page that looks just like the actual banks login page, but actually just submits your credentials to an attacker.
Modifying the link would not be possible if the landing page were served over an encrypted connection.
Modifying the link would not be possible if the landing page were served over an encrypted connection.
Not to be a dick, but did you even read the article? Is the video what confused you? He's showing that he changed the homepage to link to a login page that he controlled.
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).
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).
NatWest is a subsidiary of RBS.
What fraction of users will do this, in your opinion?
About the same number of people that have been MITM'ed for personal.natwest.com and divulged login information.
The issue is that users tend not to notice the absence of EV security indicators. If they see a padlock (which a phisher could get for a phishing domain), they assume it's secure and enter their credentials.
Also, it may not be apparent to users whether "The Royal Bank of Scotland Group Plc [GB]" would be affiliated with NatWest. Companies often have different names they do business under.
Also, it may not be apparent to users whether "The Royal Bank of Scotland Group Plc [GB]" would be affiliated with NatWest. Companies often have different names they do business under.
> Companies often have different names they do business under.
If the name is unrecognizable for users, _that_ is the user security concern that you should be posting about.
That handles the widest array of security vulnerabilities on http://personal.natwest.com/, whether MITM, compromised site, misspelled domain, etc.
If the name is unrecognizable for users, _that_ is the user security concern that you should be posting about.
That handles the widest array of security vulnerabilities on http://personal.natwest.com/, whether MITM, compromised site, misspelled domain, etc.
And if you aren't familiar with the details of how web browsers work (eg most people who use them), you would have no idea something was wrong. Not to mention potential problems such as http://stripe.ian.sh
Uhh, yeah you could do that. Do most people do that after they click the login page on their bank's website? No.
The issue is that most non-technical users would not even think about checking. They went to their "secure" bank website and clicked login, why should they have to worry?
The issue is that most non-technical users would not even think about checking. They went to their "secure" bank website and clicked login, why should they have to worry?
Unfortunately EV certs are not bulletproof:
https://arstechnica.com/information-technology/2017/12/nope-...
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.
https://arstechnica.com/information-technology/2017/12/nope-...
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.
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/ looks pretty legit in Firefox.
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/ looks pretty legit in Firefox.
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 instead.
Or put another way, don't notice the absence of "The Royal Bank of Scotland Group Plc [GB]". Or don't notice if it's been changed to "RBSG [GB]" or "Royal Bank [GB]". Then there's this:
https://stripe.ian.sh/
https://stripe.ian.sh/
I think Troy will be just fine -- it's the average user NatWest should be protecting.
Wasn't there a post on HN just yesterday about EV certs not being a secure method of authenticating the website you're on? Something about Stripe being spoofed.
The case is not overstated in any way, serving a major trust-building page like a bank homepage over HTTP is crazy. Redirecting to a spoofed webpage is obviously the simple hijack but there's no reason some attacker couldn't drop some custom-built HTML and JS to drop a faux-login form right on the page that's filled with copy about how trustworthy the bank is.
Sidenote: several years ago my bank started POSTing their login form to a completely separate domain to login to my account. So I fill in the username field on the homepage and it sends me to "totallysecurebankloginsite.com" to enter my password. After a few calls to the bank they insist that this is the design they intended and that it's just fine.
The case is not overstated in any way, serving a major trust-building page like a bank homepage over HTTP is crazy. Redirecting to a spoofed webpage is obviously the simple hijack but there's no reason some attacker couldn't drop some custom-built HTML and JS to drop a faux-login form right on the page that's filled with copy about how trustworthy the bank is.
Sidenote: several years ago my bank started POSTing their login form to a completely separate domain to login to my account. So I fill in the username field on the homepage and it sends me to "totallysecurebankloginsite.com" to enter my password. After a few calls to the bank they insist that this is the design they intended and that it's just fine.
Just one day prior, I wrote that people's mental model of the benefits that EV certs confer is broken [1]: "an EV cert asserts that the domain name is controlled by a legal entity in some jurisdiction. This is a very distinct notion from the site that you've arrived at being the site that you were intending to visit, but people use it as a terrible, flawed proxy for such."
This was on the topic of an EV cert being issued to a different 'Stripe, Inc'.
But also, I observed that for top sites, "people trust their website by fiat, simply by mental associations about their domain names (...)". This is why HTTPS on a landing page is so important: to safeguard the trust chain that most users use to arrive at the login page -- first, the name of their bank, then the bank's URL from memory, then the bank's login page from the homepage's URL.
[1] https://news.ycombinator.com/item?id=15909273
This was on the topic of an EV cert being issued to a different 'Stripe, Inc'.
But also, I observed that for top sites, "people trust their website by fiat, simply by mental associations about their domain names (...)". This is why HTTPS on a landing page is so important: to safeguard the trust chain that most users use to arrive at the login page -- first, the name of their bank, then the bank's URL from memory, then the bank's login page from the homepage's URL.
[1] https://news.ycombinator.com/item?id=15909273
Dude, you could walk into a coffee shop in the UK today, set up a honeypot wifi, and over the course of a day collect a handful of credentials with direct access to bank accounts. Unlike the US, once you're into an account you can send money directly and more or less instantaneously to any other UK account. Assuming every single person is verifying the cert/domain after they click the login link is batshit insane, I guarantee you no more than 10% of people would even have a chance of noticing.
Most users check the URL when they first browse to a page.
You want them to continuously keep verifying it’s the correct domain/cert just because this company is too lazy/cheap to buy a cert?
You want them to continuously keep verifying it’s the correct domain/cert just because this company is too lazy/cheap to buy a cert?
Microsoft is another major offender. When logging in, I get redirected 20 times between various domains, none of which in microsoft.com