Hacker News Reader

Comment by mquander | Hacker News Reader

He turned to me and said, "Do you really think the only thing the bank does to log people on is to check the username and password?" Banks are way more sophisticated than this and it goes well beyond merely string-matching credentials; there's all sorts of other environment, behavioural and heuristic patterns used to establish legitimacy. You won't ever see a bank telling you how they do it, but those "hidden security features" make a significant contribution to the bank's security posture.

Their response to having visible security that sucks is to say that they also have a lot of super complicated invisible security which is actually really good? Why am I supposed to believe that? Their invisible security probably sucks even more.

View on HN

I agree, Troy is way too gullible here.

> Do you really think the only thing the bank does to log people on is to check the username and password?

Yes. I assure you that when bad guys with your username and password log in and steal all your money the bank _won't_ say:

"Doh, our sophisticated environment, behavioural and heuristic patterns used to establish legitimacy let you down this time. We'll pay for this"

No, they'll say it is your fault because the bad guys had your username and password.

And that's all you need to know.

I'm inclined to agree. I was checking my bank account on my phone yesterday and the office Wifi was having an off day. So I disconnected the wifi and proceeded to try to login over 4g. I got locked out of my account for 10 minutes because that is suspicious. After checking my account I couldn't find a payment I was expecting to see so I opened my account on my laptop and got locked out for another 10 minutes. Sounds like the dumbest IP checking to me, not some super clever heuristic based check.

It's that assumption, literally: if the attacker had managed to steal your session information from the browser, then they would not be able to use it since they would also need to share my IP.

In real life if the attacker is capable of stealing my session credentials the chance of them _not_ being able to tunnel through my local network is infinitesimal.

The thing is though, what they seemed to object to was trying to login (not using the same session cookie) across different IP addresses. At least that was the case when I opened the site on my laptop. Maybe my phone did login on the dodgy wifi and then when I reconnected via the 4g it tried to use that session, perhaps causing my account to be flagged. I'm not really convinced though.

It clearly makes sense to tie the session to the IP address but the 10 minute delay doesn't make much sense to me.

> It clearly makes sense to tie the session to the IP address...

At one point that might have been true but not any more. Mobile devices are the norm, and handoffs between cell towers and WiFi access points are handled transparently without any user interaction. Consequently, people expect their sessions to continue working despite changes in their IP address. Use TLS connections and set expiration times on the session cookies, but ignore the source IP address.

Your IP doesn't change per tower transition, your data from the tower goes through more centralized servers. For example my IP sitting physically in RTP in North Carolina is actually exiting AT&Ts network in Atlanta, Georgia.

For clean handoffs within the same network, sure. But you also have roaming to consider, and the device may lose its connection temporarily and be assigned a new address when it returns.

Is there actually any advantage to having a dynamic pool of IP addresses like this? Associating a number from your IP block to a subscriber number seems far, far simpler and better.

Locality/size of routing tables. If you had a hundred million subscribers with fixed IP addresses moving all over the country, you essentially could not aggregate any routes, but would have to have a hundred million routes in your routing table, and/or you would have to push all the traffic from and to all subscribers through one central router, which in particular would add latency for any subscribers that currenty are at the other end of the country.

If you’re suggesting each subscriber gets a static IP then that’s much worse for privacy.

I'm speaking from the provider's point of view: they don't care about privacy. In fact, in the US there is a federal law that requires them to be able to associate network activity with a subscriber at the request of law enforcement.

Your cellular traffic is proxied in most cases, and how carriers present it varies.

>In real life if the attacker is capable of stealing my session credentials the chance of them _not_ being able to tunnel through my local network is infinitesimal.

In real life each "trivial" filter like this cuts down a substantial number of potential attackers. Defense in depth. When there's a ton of hoops to jump through attackers go find a different target.

Nah, in real life it constantly batters the system administrators with unnecessary alarms who then stop taking them as seriously as they should be if they were actual attacks.

I mentioned signals in another comment in this chain and this is a scenario (for banking specifically) where it makes 100% x 100% sense to kill the session for the client's security.

Like kill it totally totally dead!

Unlike other apps, with online banking, the priority is not to keep you connected.

It is to ensure the person carrying out the activity is whom they really say they are and that it is OK for them to do what they are doing with your account

The security posture is "deny" by default and allow if we can verify this person is whom they say they are.

Think about the signals here:

- connection has changed (from wifi to 4g - that gives you a whole bunch of IP, ISP, routing (hops) etc stuff )

- there is a proxy in the chain now (it is possible to identify the hop from phone to laptop)

- view port is still the same (connection is not the user on their phone, they are on their laptop, connected to a phone)

... then the same thing happens all over again but in reverse when you went back to the laptop.

The bank has no idea whether the proxy is a real phone or a MTM intercept especially since the connection did not initiate from that device but switched in flight.

Would totally have required killing the session if I was responsible for defining scenarios here.

> Yes. I assure you that when bad guys with your username and password log in and steal all your money the bank _won't_ say: "Doh, our sophisticated environment, behavioural and heuristic patterns used to establish legitimacy let you down this time. We'll pay for this" No, they'll say it is your fault because the bad guys had your username and password.

If your bank treats you this way, you should contact the relevant government authorities.

In the US that's the FDIC: https://www.fdic.gov/consumers/questions/consumer/complaint....

In the UK that's the FOS: https://www.financial-ombudsman.org.uk/contact/index.html

My own experience is that the bank fixes the account balance while I'm still on the phone with them so I'm not inconvenienced, does an investigation, and then decides whether it was actually me that did the transfer over the next few weeks.

In the 1990s, someone sent a fax to Chase with instructions to wire $25,000 out of my dad's bank account. When we discovered it was missing, they found the fax and realized that it wasn't my dad's signature and his name was misspelled. Chase put $25,000 back into my dad's bank account within about 2 weeks.

So yes, they will pay for it.

Two weeks seems like an unreasonably long time to be missing $25,000. If my bank took that long to repay me that much money, I would probably switch banks.

My Nans will was held up because she spelt my Uncles (her son) first and last name wrong. Professionally I've seen various other equally stupid errors over equally important things many times.

So I feel for Chase in this situation, I'm not suggesting they shouldn't have paid out.

On the other hand I log into my bank with my computer using the same browser as always and my username and password, but this time I'm in a different country. Even just a different Wi-Fi (like at a coffee shop)

And the bank _freaks out_. Omg omg omg hacking hacking! Quick to the 2FA mobile! Should we call you? Can we text you? Do you prefer email?

That's before we even get into how trigger happy they are about credit cards being used in weird ways. You buy one thing out of the ordinary (like a $3000 downpayment for a motorcycle) and immediately get 5 texts, 10 emails, and 2 phone calls. YO did you do that?

Or the one time my girlfriend deposited a physical cheque and it was so out of the ordinary the bank had a melt down and started shutting down all her accounts and blacklisting her from the bank.

I don't know about "sophisticated", but they definitely do something.

You really want to work yourself into a frenzy about minor inconveniences, huh? You’re so hyperbolic here that you sound like you’re basically making stuff up.

> You buy one thing out of the ordinary (like a $3000 downpayment for a motorcycle) and immediately get 5 texts, 10 emails, and 2 phone calls. YO did you do that?

First, dropping 3 grand at a motorcycle dealership is extremely out of the ordinary for most people. Second, my money says you got exactly one text, one email, and either one or zero calls. It makes perfect sense that they’d want to do the fraud check here. It also makes sense that they’d use multiple means of contact to reach you quickly.

As for the girlfriend blacklisting story, I don’t know if you’ve just horribly mangled this story or what. It doesn’t make sense. If you deposit a check, there is no potential fraudulent withdrawal from your account. Also, a bank cannot randomly close your accounts and “blacklist” you. They are holding your money. Stealing money from your depositors is generally frowned upon from a regulatory standpoint.

Yes it’s obviously hyperbole. My point was that banks do have security practices in place that go beyond weird password rules.

The girlfriend story unfortunately did happen. The part I left out was that the cheque bounced despite being from a reputable company – most likely an HR system glitch. This leaves the bank with 2 options: This person is doing something shady, or the big company that successfully pays thousands of cheques per day is being shady.

Guess which one the machine learning algos say is more likely :)

PS: when you sign the back of a cheque you become legally liable for that cheque not bouncing. If it does bounce, the law says you are committing fraud. The bank is therefore within their right to stop all service (they do send you your money back after killing your accounts)

That was a fun lesson to learn

I didn't understand the gist of the GP to criticize bank actions, but wanting to point out that banks do indeed have alarm systems in place beyond simple IP-change rules.

Some do. Many do not.

Sometimes they make mistakes. My wife once went to the bank office to make some operation and they unexpectedly asked a "security question" about her father's given name - something they don't usually do (the standard practice is to ask for one's mother's maiden name). She gave the answer and they rejected it, and immediately locked down access to her account without her realizing it. She only found out when she couldn't log in to the on-line interface at home. Angry phone calls were made and situation was restored, but it took a day or two and was pretty stressful.

Speaking of countries, it might be worth it to let the bank know if you're going somewhere atypical. Before my work trip to China, I phoned the bank and told them I'm gonna be there from this to this date, and didn't have any problems with accessing my account (modulo one branch of ATMs not cooperating with my card).

At least they contact you these days. I remember my cards getting locked every Christmas and every time I went overseas due to "unusual spending patterns". Yes, it's Christmas. Yes, I am overseas, I bought the airline tickets with your card.

The airline charge won't tell them where you are going... My banks have an online tool to inform them of travel plans.

Sure, but back then it was an expensive international phone call to be on hold for 15 minutes and then talk to a person who said: your card was used overseas, looked suspicious.

They are costing me money to protect themselves.

A good heuristic might be that I spent 2000AUD on Qantas a couple of months ago.

And yeah, their ads showed people on the other side of the world using their cards. No mention of this sort of stuff.

I’m not sure that’s true. My credit card statements usually show the route (and maybe the date; I don’t recall) for airfare purchases. The format the statements use has led me to believe it’s more than the airline stuffing that data in the generic string that all transactions have.

Honestly, I'd rather my bank be too quick to notify me of weird activity and ask for my approval than the opposite. At the very least, it lets me know that they are paying attention. If someone were to steal from my bank account, I'd rather find out about it from the bank than when I next try to make a purchase.

>And the bank _freaks out_. Omg omg omg hacking hacking! Quick to the 2FA mobile! Should we call you? Can we text you? Do you prefer email?

That seems like a melodramatic way to say they asked you to authenticate by a second factor, which my banks do on any unregistered device.

>No, they'll say it is your fault because the bad guys had your username and password.

This sort of claim requires evidence. Many people have had money fraudulently taken out of their accounts, so there is a wealth of experiences to draw from out there. Lots of people are getting hacked via credential stuffing due to password reuse. If the normal response from banks were to blame the customer, everyone would be talking about it.

Right. I've heard what actually happens is the bank does an investigation (which obviously costs them). One thing they'll want to figure out is if the account holder is trying to defraud them.

During this investigation the money is not available. And they do not guarantee it will be over quickly. This could result in all kinds of unpleasantness, including eviction, repossession, etc.

I don't think gullibility is the issue here. Really it's liability. Don't think for one second that Troy wouldn't get his pants sued off for any number of these banks for poo pooing their security. They certainly have the money to do it with.

I don't think it's gullibility, but I doubt that it's liability, either.

Why would the banks give a moment's thought to what Troy thinks about their security?

Even if he went on national TV telling everyone that this is terrible, they would just roll out their normal "While we appreciate the feedback, we are confident that our systems are secure" line.

The vast majority of people don't know who Troy is, they don't have any understanding of IT Security, and having some random computer guy rave about bank security is going to mean nothing to them. The few that might be marginally concerned over hearing it are almost certainly going to be persuaded by the bank's IT Suit that's rolled out to deliver the line.

It is likely just a GeoIP database and some basic user agent heuristics. I've worked at places that claimed stuff like this in public, and when you got to see behind the curtain it was a huge disappointment.

The people who really spend big bucks on this stuff are the ad-networks. Click-fraud is hugely costly to them, so determining "real" users (and the quality/type of user) is huge multi-billion dollar stuff. Creepy, but it works.

It's considerably better than that. Some examples:

The first time I went to China, I tried to pay for something with a debit card and my account got locked. I had to call the bank to OK it.

Subsequently, being in China has never been a problem, though I don't bother to tell the bank where I am at any given time.

On the other hand, after a trip to Georgia (the US state), my card information was apparently skimmed and used to make a fraudulent purchase, in Georgia, a week later. My legitimate purchases on the trip triggered no alarms, but the fraudulent one triggered a phone call to me alerting me that the bank had detected suspicious behavior on my account. I'm still amazed they could tell the difference.

The simplest heuristic I can think of is that if you made another purchase yourself not long before or after the fraudsters did, it's easy to tell that you'd have to go supersonic for both transactions to be valid.

Reminds me of a video on the VINWiki youtube channel[1].

The tl;dr: Apparently Amex have some algorithm that includes flights and road travel options. Doing a Canonball Run (very high speed driving from one side of the US to another) triggers that.

[1] Relevant portion starts at roughly https://youtu.be/HkZNddd9Pxc?t=354

My bank has SMS alerts, I can ok a suspicious transaction just by saying Y. I also chose HSBC because they have branches in China, otherwise they are not a great bank.

They most likely saw a bunch of charges from the same place at the same time and yours was one of them. They were probably card running and got caught.

Or the purchase was made online. I had that happen to me. I was in Detroit. A couple of weeks later an online purchase was made (from Detroit) and flagged.

Probably not; if I'm remembering right, the fraudulent purchase was at a gas station.

Good on them for catching that one, then!

Surely the bank giving the wrong people their money is a huge problem too?

I know they mitigate it by trying to claim it's a customer's money and not their responsibility, but that doesn't always work for them.

It works enough. They've managed to push the term "identity theft" into the public consciousness as a description of the problem, when the real problem is that they can't be bothered to actually identify people.

I think Troy has too much trust in financial institutions, or rather their staff that he encountered.

I have worked for and with several banks and financial institutions, and my impression is that this industry takes security theatre very seriously whilst quite slack and outdated on actual security.

There were a lot of ivory tower architecture (and architects) that imposed random restrictions but full of gaps and workarounds, and not very impressive once you saw past the gimics. Unfortunately, their own staff and management mostly bought into this theatre so I can't see it improving very much.

Some parts were done well and useful, but a lot was just outdated and ineffective, and just restrictive. But they have so many layers, so hacking a bank is hard, and various delays so that they can recover and recompensate you before you know it if there even was some fraud or other discrepancies.

Though there were some niches of clever heuristics and analysis but not much real-time, so my I don't buy the "Do you really think the only thing the bank does to log people on is to check the username and password?". For most that is nearly the only thing they do.

Last time I worked for a financial institution they were starting to introduce some useful user and device fingerprinting anomaly detections so I hope it has gotten better...

The corollary to this is that a user can fix a "wrong password" error, but if they're locked out by the invisible security, they can do nothing.

I'm not looking forward to the mandatory phone auth on "3d secure": https://www.sagepay.co.uk/support/12/36/3d-secure-explained

I was coming here to say the same thing. This might explain why every time I try and login to and manage our Costco Citi card (which is in the wife's name) I constantly run into issues with the password in our shared 1Password vault not working. It's gotten so obnoxious she manages it entirely now via the mobile app, because every time I would try and make payments it would lock the stupid thing.

I've done work for a few major banks and seen their back-ends. Most of the products and tools they use in support of security are purchased from 3rd party vendors, and some of them aren't bad. Where I've seen it break down is in practice, where you end up with a bunch of compromises that boil down to "lowest common denominator".

e.g. Banks are buying each other up all the time. After a few dozen acquisitions you end up with a giant hodgepodge of diverse systems not designed to work together, but need to integrate them. Username and password is common to all, so you wind up with raw dumps to synchronize credentials. (That's less common now that most vendors have adopted better practices like password hashing, etc. but it wasn't so uncommon back in my day)

I'm not surprised at the character limits. It simply means there's at least one legacy system somewhere that can't accommodate more. It's not necessarily tied to a plaintext database field as Troy suggests; it could simply be a validation in some line of custom reporting code a programmer put in two decades ago based on ancient requirements devised long before current-day practices. Or more simply, bank IT themselves may be unsure what their real limit is at a given point in time, and chose to go with something "safe".

I'm not denying banks need to step up their game, after all it's nearly 2020. But personally I think the reason it won't matter is most of them won't be around long enough - they're in for a world of painful disruption from the likes of Stripe, Apple, Google, cryptocurrencies, Libra-like instruments, peer-to-peer services and micropayments, etc. and who-knows-what other big innovations about to be invented by geniuses from areas of the world presently starved for financial services.

"I'm not denying banks need to step up their game, after all it's nearly 2020. But personally I think the reason it won't matter is most of them won't be around long enough - they're in for a world of painful disruption from the likes of Stripe, Apple, Google, cryptocurrencies, Libra-like instruments, peer-to-peer services and micropayments, etc. and who-knows-what other big innovations about to be invented by geniuses from areas of the world presently starved for financial services."

I'd be surprised if these services actually disrupted the banking industry. Banks are heavily regulated, and with reason. The moment any service starts to step onto bank turf, they're going be subject to the same regulations and will have to effectively become a bank as a result. What's more, these services don't address the social role that banks play where they enable governments and large business to function by loaning them money. Or the economic control function that banks play. Banks will remain in existence for generations to come.

You raise some good points, and I agree it will take ages before the existing institutions die off. But the internet has transformed (or is transforming) nearly every other industry. Television (Netflix), retail (Amazon), transportation (Uber, eventually perhaps Waymo), communication (Gmail, Slack) etc. I think banking is up next. It's a ripe combination of innovation lethargy (the ancient, outdated tech is just one symptom), a customer base unsatisfied with the user experience, insipient poor judgement or corruption (to the point we've actually bailed them out to keep malfunctioning ones alive instead of letting market forces do their thing), comparatively fat margins supporting intrinsic inefficiency, and more. Some of the peer-to-peer techs (eg. decentralized Smart Contracts maintained by developers in permissive jurisdictions) will bypass regs for a while or limit enforcement to the on/off ramps - at least long enough to demonstrate alternative models (the way Napster did). Eventually new startups will offer the most appealing benefits in a legit, scalable, compliant way and run circles around the old institutions. At least, that's the broadcast today in my crystal ball ;-).

I would think it'd be possible to remove limits for the user facing password and store it as a secure hash. Then on the integration side transform that hash into something that is compatible with the legacy system.

I've had the opportunity to chat with many ex-bank developers and based on those discussions I'm as positive as I can be, without my own personal experience, that this is assuredly utter garbage.

The last two I've spoken with had read-only access to _everything_. The entire company did.

I’ve worked at 2 of the 4 major banks here in Australia and I’m calling bull on that last statement.

The entire company had read-only access to everything? Yeah nah. Who put the Siebel client on Janice the HR lady’s laptop? Who created an account on the mainframe for Barry the bloke who re-stocks the milk in the fridge?

You get my point.

I was a bit exaggerative - the entire "development" arm of the bank had read only access to all customer financial data. One of the devs was a customer and pulled up all of his information.

I think they meant that the last two ex-employees they spoke to had read-only access to everything, not that every employee at a given bank had access to everything.

> there's all sorts of other environment, behavioural and heuristic patterns used to establish legitimacy.

Here's what annoys me: These "environment, behavioural and heuristic patterns" check for cookies, IP/location, typing speed or so, don't they. Which means, that if I (for enhanced privacy and security) frequently clear my cookies and habitually use a VPN and/or travel a lot and use a password manager and copy/paste the password, then I'm flagged as suspicious and just DOSed myself. Thank you very much.

I must admit though that most of the banks I use are reasonably good with that. Paypal, however, is just a total pain in the ass: basically every time I try to use it, it concludes that I'm brute forcing myself and blocks me.

Like "military encryption" and buzzwords like RSA, which leads me to believe that banks do just the bare minimum that some consultant has told them to do...

Well here's some of it. This is what ublock origin has to say about us.hsbc.com:

  google.com
  adsrvr.org
  amazon-adsystem.com
  appdynamics.com
  bing.com
  demdex.net
  doubleclick.net
  facebook.com
  googleusercontent.com
  gstatic.com
  hsbc.com
  linkedin.com
  liveperson.net
  lpsnmedia.net
  omtrdc.net
  tiqcdn.com
  yahoo.com
  youtube.com
  ytimg.com

Plenty of behavioral stuff in there!

They wouldn't put that in the front-end allowing you to block it. It's all in the back-end using third-party services such as Guardian Analytics. Dislcaimer: I briefly worked as a software consultant in the finance industry, that is one of (I'm sure) many out there. You don't want to expose third parties you use for parts of your online banking process. I assume bigger banks homebrew it all.

But why would this really be? Are they actually attempting to harvest specific user data for HSBC account holder X from all these sources? (something I sure as hell wouldn't want my leaky bank to do no matter what kind of security it promises) Or are these just links for the sake of typical bigcorp bullshit ad tracking attempts.. Any ideas?

Probably the latter in fairness.

But presumably the data from those trackers feeds into the hidden backend heuristics the parent commenter mentioned.

Yes but if one has many of these disabled or logged out (the social media-type pages in particular) I imagine they couldn't get much for the sake of heuristics data collection anyhow,or if say you log in from a device where none of these accounts are also opened. I can't imagine Facebook openly letting a third party banking site or app scrape up its precious specific user data without first paying for it in "anonymized" form, ditto for Google, so how might that work if the bank was attempting that?

If you scroll to the bottom of that page for HSBC you will see the typical social media icons. It's likely embedded from those.

HSBC direct is almost as bad. Won't be opening an account with them with that much vulnerability exposure on the site.

Yeah it would be great if Bank of America just worked with Safari and uBlock Origin on with my username and password, and it didn't have these moronic "patterns."

> Why am I supposed to believe that?

You aren’t. You trust that if your money is stolen in a hack, the bank is liable for your losses.

Exactly!

We had some money fraudulently withdrawn from our Wells Fargo checking account and though we got it back, I had a bunch of questions about bank security. My bank manager arranged a phone call from somebody on the inside to me. I pressed her about their password length restriction saying that as long as they are hashing the password, length doesn't practically matter. The fact that length is limited to a small number of characters makes me think they are storing the clear password in a database. The response was basically don't worry about it because you aren't responsible for fraud.

> The response was basically don't worry about it because you aren't responsible for fraud.

That's assuming you can prove it. The banks' poor authentication practices certainly don't help on that front. If their own systems don't flag the transaction as fraudulent then it becomes nothing more than your word against theirs.

And storing cleartext passwords is a risk to the user in the event of a breach regardless of their liability, or lack thereof, for fraudulent activity in their account. (Yeah, each password should be a unique, random string used only for that account—in theory. It rarely works out that way in practice.)

Personally I'd rather they implemented standard strong authentication mechanisms and backed off a bit on the data-mining and general paranoia about atypical transactions. Chip+PIN cards are a good start on this but they're still far from universal (especially the PIN part) and don't work at all for online payments. The card should be a proper HSM with standardized interfaces for PCs and mobile devices, and the PIN should be both mandatory for every transaction and randomly assigned.

> That's assuming you can prove it.

Once you tell them some transaction wasn't authorized, it's up to them to prove otherwise.

All the suggestions you make are great if your goal is to minimize fraud. If you are trying to maximize profit then you don't tighten security if the cost to do so exceeds losses due to fraud.

> Why am I supposed to believe that?

Because it's required by law, at least in the US, UK, and most of the EU. The quality varies somewhat, but the main goal is less to prevent fraud than to detect it after the fact. Basically every single bit of information your computer is willing to send will be recorded. That includes request headers at a minimum (if you've disabled JS) and quite a bit more if you do have it enabled. Try a packet capture when you open your bank account next time to see just how much they transfer out of your computer.

Source: used to work on one such product

What laws?

I worked dev (hence the username) and left the company more than 5 years ago, so I don't remember the exact regulations. I do remember it was a big deal towards end of 2012, so you're probably looking for something from around 2008 with a final enforcement date of 2012.

I'll update if I remember the name.

There was a bunch of stuff to do with this in the first payment service directive, most of which was enforced around 2012-2013

https://en.wikipedia.org/wiki/Payment_Services_Directive

PSD2 has requirements on "strong customer authentication" basically requiring 2-factor, that were meant to come into force on Saturday the 14th of September just passed, but ended up being delayed at the last minute in most countries.

I'm sure whatever product you worked on had all of the features you've described. I'm skeptical that the primary purpose of those features was fraud prevention rather than data mining. I'm quite certain none of those features are required by law.

I've yet to see any law that requires a specific feature. Usually they're worded like "has a control for preventing unauthorized access to accounts". The definition of unauthorized, access, accounts, and even control are left to auditors and each bank defines them differently. I spent 2 months implementing something with absolutely zero security value, but the bank's auditor was insisting so we had no choice.

I don't remember any data mining projects that weren't explicitly anti-fraud, but that was years ago and things may have changed since. One project I recall was able to proactively reach out to banks and inform them of compromised accounts based on things we learned from other banks. Pretty cool stuff; kinda wish I had stayed there longer.

It would be interesting to see how this squares with GDPR, the purpose of the latter being to minimize recording of what your computer is willing to send.

We have one dataset we would very much like to delete (discontinued product) but are required by a different EU law to keep. GDPR now also means that we have to provide that data to our customers if they request a copy of all the data we hold on them.

GDPR allows you to collect data if you have a legal need to do so.

It's debatable whether there is a legal need. I prefer 2FA and that should be it. If you are trying to stalk me, I am willing to cancel.

It's questionable when you can turn bank passwords over to a random third party to check/verify your account information or import the data into another system.

"Why am I supposed to believe that?"

Because if someone gets in, they're going to refund you.

Seriously. They do the bare minimum requirement of their regulatory regime and other insurance requirements in most cases.

Not always. See https://www.pindrop.com

Don't get me started on their "invisible security" on credit card transactions....

I'm sure that Equifax used these security features.

How on earth is that relevant? Equifax's breach had nothing to do with password authentication whatsoever.

I can’t tell you why, but I know some of the anti-measures bank use and I can assure you that they are pretty sophisticated. However, all I have seen are security efforts to secure the network, not the banking interface of customers - which means, if someone has your name and passcode, they can access your account online.

I bet they have something like IP address origin checks and nothing more.

> I can’t tell you why, but ...

>Their response to having visible security that sucks

seems like you missed the whole point of the article - their security doesn't suck.

EDIT: as reply points out below, not bits of entopy, just possible combinations. ORIGINAL: 3 trys - thats it. theres no account autounlock. 5 lower case letters is ~12 million bits of entropy, and thats if you even know the username which, the article points out, you often dont.

furthermore, even if i accepted your claim that this "visible security" was bad, the "invisible security" is well established. any reputable bank will flag your account for any number of reasons. ive had cards (correctly) locked for <$1 charge at an air pump a few miles away.

>Why am I supposed to believe that?

again, as the article says, "Banks like ING will give you your money back". they have skin in the game and will refund your fraudulent charges.

> 3 trys - thats it.

Until the users logs in, then you have another two tries. Until the users logs in, then you have another two tries. Well, and so on, ad infinitum.

> 5 lower case letters is ~12 million bits of entropy,

That's more like 23.5 bits, which, as far as I know, is quite a bit less than 12000000.

> again, as the article says, "Banks like ING will give you your money back". they have skin in the game and will refund your fraudulent charges.

So, if everything looks like you authorized a transaction, they'll give you your money back because you said so? And you seriously believe that?

I agree with all your points except the last;

> If everything looks like you authorized a transaction, they'll give you your money back because you said so? And you seriously believe that?

two times I've reported fraud to two different banks. I was sent a letter from them stating "you say you didn't make X transaction, please sign and date and return", and I got the money back, no further questions asked. I fully believe that a consumer bank will refund 99.99% of transactions without asking further questions if you tell them it's fraud. (Both my values we're under 300 pounds, for whatever it's worth, and I've found out since thatits a royal pain to spend > 1000 pounds on a debit card without being pre approved for the transaction)

> I fully believe that a consumer bank will refund 99.99% of transactions without asking further questions if you tell them it's fraud.

OK, so my point still stands then?! I mean, it's certainly true that banks will generally refund (and in many jurisdictions have to refund) if they can tell that the customer was defrauded, and they also generally won't inconvenience their customers over small amounts.

But for one, you didn't say 100%, and you can guess that the remaining 0.01% (though I would guess it's quite a bit more than that) are not the 100 pound transactions that ultimately wouldn't really hurt the customer anyway, but rather those that wipe out someone's life savings. It's an easy business decision for a bank to immediately refund you 100 pounds if they expect to make more than 100 pounds from you by retaining you as a customer. It's very much not if you are asking them to refund you 100000 pounds. So, there is a bias in this mechanism that it primarily helps those who don't need it, but is of questionable reliability for those who really need it.

Plus, even if you do get your life savings back, you can be sure that just asking them to refund you 100000 pounds will not do the trick.

So, yeah, sure, banks will refund you more often than not. But my point was that that is not something you can really rely on when it actually matters, and I stand by that.

> and you can guess that the remaining 0.01% (though I would guess it's quite a bit more than that) are not the 100 pound transactions that ultimately wouldn't really hurt the customer anyway, but rather those that wipe out someone's life savings

I disagree - like I mentioned before, actually getting my bank to _make_ a medium sized transaction (debit card >1k) required me to phone them in advance.

I'm not going to say 100% because all you need is one anecdote about a fraud transaction being reversed, for any reason, and 100% isn't valid.

> I disagree - like I mentioned before, actually getting my bank to _make_ a medium sized transaction (debit card >1k) required me to phone them in advance.

Are they legally required to do so? Could an attacker circumvent this somehow (such as redirecting the calls to themselves)? ...

Apart from the fact that preventing me from using my money is terrible usability. If I am not contractually obligated to have my phone with me, but they suddenly refuse to authorize a transaction because they can't reach me on my phone, I suddenly have to fulfill some secret requirements in order to be able to spend my own money.

> I'm not going to say 100% because all you need is one anecdote about a fraud transaction being reversed, for any reason, and 100% isn't valid.

The point is: You recognize that that probably does happen. And that some of those cases could be prevented with strong passwords. So ... what is your point?

On the attacker's extra tries. that's assuming a straight username/password combo with no additional data.

For UK banks at least, I can't think of a single one that's only username/password.

The better ones are 2FA, the less advanced ones will at least have something like username+password+"some kind of secondary secret" so straight online brute force is unlikely to be successful.

Also your attacker shouldn't know about the impending lockout, so unless they have some way of knowing when a user has logged in, they'll end up locking the account (well assuming username/password ofc)

The more advanced ones that use 2fa are really only 1fa (at least the two I have accounts with). Both allow you to reset your 2fa using the username+password on an install of their mobile device.

>> 5 lower case letters is ~12 million bits of entropy,

>That's more like 23.5 bits, which, as far as I know, is quite a bit less than 12000000.

woops! youre totally right. added an edit.

>ad infinitum.

this is not true. banks take action and will not give you probably any more than 2 or 3 sets of lockouts before taking action.

>So, if everything looks like you authorized a transaction, they'll give you your money back because you said so? And you seriously believe that?

You must not be from the US. To my knowledge, most banks will refund fraudulent purchases. in addition to being believable at face value, I have also personally had fraud charges reversed.

> this is not true. banks take action and will not give you probably any more than 2 or 3 sets of lockouts before taking action.

Except no lockout happens in this case?

> You must not be from the US. To my knowledge, most banks will refund fraudulent purchases. in addition to being believable at face value, I have also personally had fraud charges reversed.

And what do you do when your bank tells you that they can't see any sign of fraud?

Or what do you do when you can't pay your rent/mortgage because the bank hasn't returned your money yet. All that convincing doesn't happen instantly.

https://www.federalreserve.gov/supervisionreg/regecg.htm

>Except no lockout happens in this case?

You're assuming that the lockout counter resets on successful login. Maybe there's a daily failed login counter.

Well, maybe? But for one, that's a big maybe, but also, it does not fundamentally change the fact that an attacker has more than three tries, or whatever the official limit is.

And being able to lock arbitrary people out of their accounts is also a form of attack.

> Until the users logs in, then you have another two tries. Until the users logs in, then you have another two tries. Well, and so on, ad infinitum.

I don't understand how this is exploitable unless an attacker knows when a user logs in. Otherwise, how do they know when they have two tries again?

Well, how about the attacker knows when the user logs in, then? That's not exactly sensitive information ... or at least it shouldn't be. There sure are plenty of ways of how that info could leak out.

But also, an attacker might just not care? Just try to get into a vast number of accounts at a rate that generally, statistically, doesn't trigger lockout, and it might just be irrelevant that that triggers some lockouts here and there.

Reply on news.ycombinator.com