Hacker News Reader

Comment by bckr | Hacker News Reader

Another lesson here is to bookmark/ memorize the url of your bank, and don’t trust search engines to take you to your bank

View on HN

This might not be sufficient anymore. Many online payments are rendered either on the shop's pages or on a third party payment provider, including 3DSecure implementations. These don't redirect to any sensible bank URLs.

Both of my banks use a payment flow which uses a hardware authenticator. But only one bank seems secure: it prompts for an amount and a reference and generates an OTP based on that. This is distinct from any other signing operations with the same authenticator. The other bank tells me to enter a 6 digit number (which is allegedly made up out of a part of the amount and a reference), but it is impossible to tell this apart from any other signing operation. It doesn't strike me as too hard to abuse that to either log in to my account, to sign another payment, or even to create a direct debit...

I have a couple of bills to pay to the city and the 3rd party pay processor (they switched a couple years back) they got looks like the page was made by a moderately talented 5th grade web developer. I actually called them to verify I had the exact URL correctly and also told them the page looked like it was made by complete amateurs and was kind of scary it was so poorly done.

I ran into this. I'm trying to set up an account on wise.com. The way they want me to set up my bank for direct deposit is to type my banks password into their site! I asked support if there was any other way to do this (for example the regular institution, branch, account numbers) and they said no. But they reassured me that despite me typing the password into their site that they don't have access to it! (Ok, it was actually a Plaid iframe, but still not my bank. Clickjacking would also be very easy to implement and there is no way for the average user to understand this.)

Then banks wonder why their customers get phished.

Plaid is a cancer of the payment system. It's amazing how they're trying to normalize entering your banking credentials into their third-party site.

It's not even their site as far as the user can tell. It is a full-screen iframe. At least if it was their site a bank could say "plaid.com is fine". Still bad to make acceptable domains more than one but at least it isn't infinite.

I'd like to throw a little blame onto many namebrand websites.

Sites like Digital Ocean try to load dozens of third-party trackers for a single page. Their supposedly secure payment processing includes cross-site violations that are blocked by modern browsers.

When their credit card management pages fail to work with reasonable browser defaults or sane browser add-ons they immediately advise their users to strip out all security protections. You are supposed to just trust content coming from seemingly unrelated domains including multiple processors you may or may not have ever heard of. Paypal? Ok, plausible. Stripe? I guess, but both? Pendo? Sentry? Optimizely? Hexagon? Google Ads? Google Analytics? Six other different Paypal domains? Eight other Stripe domains? Multiple Typekit domains? TagManager? Spuare? The list keeps going.

Plenty of reasonable protections cause alarm bells left and right. The answer? Disable those protections. Train users to think they are the problem.

I'd be interested in anybody explaining why a welcome page needs assets from 17 other domains, including paypal and stripe.

https://cloud.digitalocean.com/welcome

Why are multiple payment processors included on this page that doesn't involve any payment?

pptm.js is paypal's tag manager, for "Marketing Solutions". Gives the vendor shopper insights (clickthru, etc).

Stripe recommends putting stripe.js on every page to help detect fraud better (https://docs.stripe.com/js/including)

In the past I've heard people say the opposite - that if less computer savvy people are using google instead of URLs, it's a good thing.

The reasoning was it protects them against typosquatters and whitehouse.com situations. I guess when people were giving out that advice, google wasn't the way it is now.

Yeah -- this was good logic back in the day.

Now one has to scroll down -- sometimes several links -- before finding a link that isn't an ad.

Maybe this is where encouraging people to use the "I'm Feeling Lucky" button would help, because it should still go to the top non-ad-link?

There was a time wherein the top result for facebook was a blog which faced a deluge of comments complaining that they couldn't log onto their facebook.

"Always use a bookmark" has always been the best advice. I'm fairly sure getting a bunch of typosquatting domains is standard practice now for major (particularly financial) sites so typing in the site from a reliable printed source for the first access is fine (particularly since you can be extra careful if you only do it once). For using shared computers, I'd still personally recommend typing from a reliable printed source.

For logins, a major advantage of having browsers save login info is to recognize legit sites becuase the login can be filled out (though it should be set to require a click on the login form and not just appear). Occasionally sites change in a way that breaks this but usually just once to use a subdomain and can be investigated more closely when it happens.

I think browsers should add a "site bookmark" feature that uses a well known mechanism to allow all associated sites to be annotated in a way that shows up similar to how EV certificates used to work (but is entered by users). That would make it possible to recognize legitimate links into a site (as long as you annotate the correct site the first time) and there could be an option to be notified when leaving the annotiated set of domains for particularly sensitive sites. Currently the closest is bookmarking the home page, editing the URL to remove everything after the domain, checking that the edited url is bookmarked (this is fragile since sites change the redirection quite a bit), and then hold the back button and go back to to the linked page, although this might not work for additional domains (e.g. support sites are often on a subdomain). Ideally, the site bookmarks would also annotate search results before they are clicked. While "remember to check if the site is legit" is not ideal it is a far better situation than "no way to tell if the site is legit". This could also be used to add a standard OTP entry mechanism that binds to a site and gives a warning if it is from a site you haven't given an OTP to before or stored login info (and shows the site name when you enter the OTP).

Native app on phone > bookmarked site > typing site name (but only if using native browser password manager to auto-complete when the domain is correct).

Or something like that. I hate when I have to type site URLs from printed material (usually only doctor's bills, yet another reason to move to single-payer/socialized care) because I'm paranoid I'll get it wrong. Even more so with some of the janky URLs used by medical payment processors (contrived but realistic example: http://paymemoney.doctors.systemhealth.net/~drabdullahriaz/l...). Le Sigh.

Very difficult with most big banks.

In my experience with Bank of America and US Bank they bounce you around to several totally different top level domains as you navigate through the web-based banking.

These are third-party service providers that the banks contract for various pieces of their online infra… And it is a complete mess in terms of conditioning consumers to be phished.

that's true and kind of a joke by now, bofa has at least two parallel bill pay systems (both seem white-labeled from someone else?) keep redirecting through multiple domains, both are barely usable and take forever to load to do basic tasks. Security definitely takes a back seat when fighting with their UIs to get anything done.

Also that Google, as a search engine that is also the world's biggest advertising company really should be able to manage not to sell ads to phishing scammers!

Maybe if platform is large enough it should be criminally liable for phishing attacks. I see no reason why Google should not be responsible in vetting each and every link they advertise at top of their search results.

KY(C)A

If Google ad words even allows a scammer to create an ad for a bank login page then we have a more fundamental problem.

Or skip the website and use their native app.

then you can't block anything

Why do you need to block stuff on your bank? I do all my banking through their app tbh. If I had to block stuff from the bank then I’d switch banks.

I don't understand - what would I block that's being delivered by my bank's native app? IF I can't trust their app, I can't trust the institution as a whole.

Reply on news.ycombinator.com