I would argue that this is not just banks but a number of different services. This entire Github repository [1] and this Twitter account [2] are dedicated to sites with dumb password rules. Passwords are not meant for humans.
Here is a link to a hackernews thread discussing the worst of the requirements in the repository is here [3].
The PayPal section doesn't mention that they have a 20 character limit too. I honestly wonder what kind of buffoons are in charge of making this shit up at multi-million dollar companies.
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.
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 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.
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.
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.
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.
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.
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.
>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.
>> 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?
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.
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.
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.
> 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?
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...
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.
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.
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.
>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.
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.
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.
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.
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.
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).
Stop deliberately using “modulo” incorrectly like this. It’s cringey, doesn’t make sense, will never catch on, makes people pause for a full minute trying to understand what you really meant or if it’s an odd autocorrect, wastes people’s time, and ruins your entire comment. Just say “other than” like a normal person.
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.
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.
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.
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.
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.
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)
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.
>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 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.
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."
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.
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.
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.
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.
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.
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?
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.
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.
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.
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?
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?
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.
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.
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.
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...
> 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.
This 'hidden security features' explanation sounds a bit like security by obscurity. Mouse movement fingerprinting? Browser fingerprinting? Locking people out when they get a new laptop doesn't sound like a good time
If someone guesses the 2 numeric digits necessary to gain telephone access to my pension fund, and they then transfer out the $10M value to the cayman islands, will they really give me back the money? Would I have any chance in court? - proving it wasn't me is near impossible.
Yet this pension company has millions of customers, and presumably isn't seeing widespread fraud. How come?
Because you're evaluating the effectiveness of one control in isolation, whereas the pension fund has a lot of controls, including e.g. an operational team which knows that wiring money to the Caymans is intrinsically high risk, a written procedure that they'll follow for high risk transfers specifically to papertrail up evidence in the event it is contested, a legal environment which will put the burden of proof on them rather than you if they did something that self-evidently stupid, the medallion guarantee program and associated regulation, etc etc.
Fraud happens. Financial institutions spend a lot of money defanging it; they also, when push comes to shove, have budgets for it.
For the really large banks: $XYYMM (i.e. hundreds of million dollars aka the cost of doing business) across all lines of business.
All this is mostly public info as it has to go into financials, you can find it under "Operational Losses" for any public bank (Note that "Operational Losses" are not the same as "Operating Losses").
A sample multi-year summary can be found here from an industry body in Europe for losses for debit. (losses are demonimated in Euro):look at page 7 under the last column for the rows "Retail Banking". Important to note that credit ops losses are an order (or maybe two) of maginitude higher.
Sorry, but that article is just dumb. For one, obviously, the possible existence of other security mechanisms is exactly no reason for intentionally breaking password security. Either you store passwords as plain text, in which case you have just failed, or you are storing a hash, in which case there is no cost to doing the right thing and accepting arbitrarily long passwords. There is no way to start with "we have other security mechanisms in place" and end with "therefore, we should weaken password security". And if an organisation is incapable of understanding that trivial piece of logic, I have very little hope for their supposed magic security solution.
But even worse: The idea that locking users out after so many failed attempts is a security mechanism. When a small bandwidth of unauthenticated requests can disable a critical service, that is known as a denial of service vulnerability and not a security mechanism. If you have proper passwords, locking users out is completely useless for security, but it's still a DoS vulnerability. A brute force attack will not crack a 128 bit random password, no matter the rate at which it is tried. And while non-public user IDs can help mitigate that risk, it is not at all a given that banks don't use essentially public account numbers as user names, even ones that have 6-digit password limits. Plus, the user ID at that point effectively becomes part of the password, just that it's a password that you can't change, which isn't exactly brilliant either.
And finally: It's quite a failure at assessing attack scenarios if you think that user lockout actually solves a problem. Your typical bank has a failure counter per account. A failure counter that is reset on every successful login. So, the real number of attempts an attacker could make is the number of attempts you have before lockout minus one, multiplied by the number of successful logins by the customer. An attacker might not necessarily be able to know very well when the user has logged into their bank account, which sure will limit the exploitability somewhat, but then, that very much depends on the circumstances. If you know someone pulls their transactions every 15 minutes, say (especially a business, which might even leak the time they pull transactions by sending payment receipts in response, for example), then you might very reliably be able to make 8 guesses per hour, or ~ 70000 per year, without causing lockout. If you instead want to target the general public, you might also just use a bot net to attempt login into accounts only occasionally, risking some lockout, but statistically compromising a certain number of accounts over time.
And all of that when proper passwords do solve all of those problems perfectly reliably.
Oh, yes, and the idea that some banks will give you your money back? Seriously? Now, if that isn't a failure at assessing risks, I don't know what is. Who seriously believes that banks will give you your money back on your word that you didn't authorize some transaction? Of course, they won't, they'd be wide open to fraud if they did. If the attacker is good enough at making it seem like the customer authorized the fraudulent transaction, obviously, the customer won't get back a cent. Those claims by banks are marketing bordering on fraud, and obviously not something anyone claiming to be an expert in security should just trust to be something you can rely on.
>When a small bandwidth of unauthenticated requests can disable a critical service, that is known as a denial of service vulnerability and not a security mechanism.
But what's your threat model here? Some attacker who's targeting you that somehow got your randomly assigned username but not your password? Or someone hitting every account number for "the lulz"? In the first case, it can be resolved with a 10 minute call to the bank to get your username changed (although you have bigger issues if your attacker was able to get sensitive information such as your banking username). In the second case, the attacker will get ip banned/rate limited very quickly.
>If you know someone pulls their transactions every 15 minutes, say (especially a business, which might even leak the time they pull transactions by sending payment receipts in response, for example), then you might very reliably be able to make 8 guesses per hour,
Sounds like a very non typical use case. Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising. Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious.
>Who seriously believes that banks will give you your money back on your word that you didn't authorize some transaction? Of course, they won't, they'd be wide open to fraud if they did.
What do I know? DoS attacks are a thing, so that's the threat model?!
> Some attacker who's targeting you that somehow got your randomly assigned username but not your password?
You are assuming the username is randomly assigned.
> In the first case, it can be resolved with a 10 minute call to the bank to get your username changed
Wut? For one, how is being denied access to your capital for ten minutes in any way "solving" the DoS risk? Then, how does that even solve anything if the attacker simply disables your account again within a few seconds? If your suggestion is that using the username as the password somehow is supposed to protect you, I have bad news for you: You usually can't change your username, so you can not change that "password" to something the attacker doesn't know.
> (although you have bigger issues if your attacker was able to get sensitive information such as your banking username)
You have it all backwards? The sensitive part is what is called the password. If your username is sensitive, you are already doing it all wrong. Especially because, see above, you can change your password, you can not (usually, easily) change your username-pretending-to-be-your-password.
> In the second case, the attacker will get ip banned/rate limited very quickly.
You have heard of this thing called a bot net, right?
Also, congrats, you have just introduced the next DoS risk: If you happen to use an ISP where your IPv4 connectivity is only through NAT, and given that most banks are IPv4-only, suddenly, some random customer of that ISP, or the malware on their machine, can disable your access to your account.
You know what would actually solve that problem? Wait for it ... it's passwords! Like, proper, real, high-entropy passwords. Who would have thought?
> Sounds like a very non typical use case.
The idea that banks should only be secure for "typical use cases" primarily sounds like a very bad design principle.
> Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising.
Except other countries have a slightly more modern banking infrastructure. All of the EU is currently introducing realtime money transfers with a guaranteed payment delay of maximum 10 seconds between any two banks in the EU. Pulling transactions only every 15 minutes seems like quite a massive delay in comparison.
> Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious.
Well, yes, sure. But for one, that there is a persistent login fail counter is a big if. If you are lucky, maybe there is. If there isn't, the bank will blame you. And also, regardless, the problem still remains: There definitely is no permanent login fail counter. Customers occasionally do mistype their passwords, and that does not lead to lockout. But whatever the real maximum rate of failed attempts is: The total number of possible attempts is more than the advertised supposed maximum number of attempts.
> AFAIK they're obligated by law.
They are obligated to do what? Give you back your money because you say so? Certainly not. Be able to determine with 100% accuracy whether a transaction was fraudulent? Yeah, sure?!
>What do I know? DoS attacks are a thing, so that's the threat model?!
It matters because you need to consider the attacker's motivations, goals, and resources.
>You are assuming the username is randomly assigned.
So? If not randomly assigned, the best you can do is enumerate all users in an unpredictable manner. It's not like sequential usernames allows you to easily guess the username for a specific person.
>Wut? For one, how is being denied access to your capital for ten minutes in any way "solving" the DoS risk? Then, how does that even solve anything if the attacker simply disables your account again within a few seconds?
It solves the DoS risk because it makes subsequent attacks sufficiently hard to perform afterwards. If your username can be leaked within seconds, the attacker probably has access to perform more devastating attacks than a simple DoS.
>You usually can't change your username, so you can not change that "password" to something the attacker doesn't know.
You might not be able to change your username online, but support can probably change it.
>You have it all backwards? The sensitive part is what is called the password. If your username is sensitive, you are already doing it all wrong. Especially because, see above, you can change your password, you can not (usually, easily) change your username-pretending-to-be-your-password.
Yes, usernames are supposed to be identifiers only, but keeping it a secret from your enemies isn't particularly hard. Please explain how the attackers are getting a hold of your username in the first place.
>You have heard of this thing called a bot net, right?
Here's why you need to consider the threat model. If it's some guy out for the lulz, using a botnet incurs a cost (both in terms of actual risk in terms of detection, and opportunity cost in terms of other things he could be using it for eg. credit card fraud, DDoS for fire, etc.). And the guy is willing to expend unlimited resources, then all bets are off. He could use amplification attacks to take down the bank's website by raw bandwidth alone. Worst case the bank mails/emails everyone new high entropy usernames.
>Also, congrats, you have just introduced the next DoS risk: If you happen to use an ISP where your IPv4 connectivity is only through NAT, and given that most banks are IPv4-only, suddenly, some random customer of that ISP, or the malware on their machine, can disable your access to your account.
Strange. I can log into my financial accounts while using VPN without a problem. You'd think that a VPN service that anyone can sign up for anonymously would invite more abuse than an ISP that you need to provide real credentials for.
>You know what would actually solve that problem? Wait for it ... it's passwords! Like, proper, real, high-entropy passwords. Who would have thought?
You seem to be misunderstanding Troy's position. He's not saying it's ideal, or even good practice. He's merely saying it's not as bad as you think. ie. having a 6 digit numeric password doesn't mean you're going to get you hacked within minutes.
>Except other countries have a slightly more modern banking infrastructure. All of the EU is currently introducing realtime money transfers with a guaranteed payment delay of maximum 10 seconds between any two banks in the EU. Pulling transactions only every 15 minutes seems like quite a massive delay in comparison.
I have a feeling that businesses that need low latency transactions aren't doing so by scraping their bank's web page. They're probably using some sort of payment provider, or the bank has an API.
>Well, yes, sure. But for one, that there is a persistent login fail counter is a big if. If you are lucky, maybe there is. If there isn't, the bank will blame you.
If anything, having a weak password gives you more plausible deniability than having a 256 bit entropy password.
> So? If not randomly assigned, the best you can do is enumerate all users in an unpredictable manner. It's not like sequential usernames allows you to easily guess the username for a specific person.
... or just use their account number that's on their website. Really, what's your point? Yes, you can potentially use some usernames as passwords. Doesn't mean it's somehow more sensible than using passwords as passwords.
> It solves the DoS risk because it makes subsequent attacks sufficiently hard to perform afterwards. If your username can be leaked within seconds, the attacker probably has access to perform more devastating attacks than a simple DoS.
What? Denying you service prevents denying you service because it makes denying you service any longer sufficiently hard, except it doesn't, because that's just another three requests?
> You might not be able to change your username online, but support can probably change it.
So, now you are just pulling stuff out of your ass? And in any case, how does any of this make any sense? Having bad passwords is a good idea, because we can use the username as a sort-of password? Sure you can, but why the heck not use the password as the password?
> And the guy really does have resources for a botnet, then all bets are off. He could use amplification attacks to take down the bank's website by raw bandwidth alone.
Erm, yeah? And why should he do that if a low-bandwidth attack does the job just fine? And in any case, how is the fact that there is one kind of DoS attack vector that you can not prevent a reason to also add another DoS attack vector, and to then use that to justify that you put in effort in order to weaken password security? Like ... what's your point?
> Strange. I can log into my financial accounts while using VPN without a problem. You'd think that a VPN service that anyone can sign up for anonymously would invite more abuse than an ISP that you need to provide real credentials for.
Which is a reason for building weakened security how exactly?
> You seem to be misunderstanding Troy's position. He's not saying it's ideal, or even good practice. He's merely saying it's not as bad as you think. ie. having a 6 digit numeric password doesn't mean you're going to get you hacked within minutes.
Yeah, having a root ssh account on your server with password "test" doesn't get you hacked within minutes. So, how is that an argument? There is real security, which doesn't get you hacked in decades, and then there is everything else that is pointlessly insecure, and in this case way less secure than he suggests in any case.
> I have a feeling that businesses that need low latency transactions aren't doing so by scraping their bank's web page. They're probably using some sort of payment provider, or the bank has an API.
... and banks use the exact same idiocy on their APIs, correct. Why would they not if they are convinced that that is how you are secure, as they seem to be?
> If anything, having a weak password gives you more plausible deniability than having a 256 bit entropy password.
Well, sure. But then, not ever having any unauthorized transactions means you don't have to worry about plausible deniability?
> That's the point of obligating it by law. It's consumer protection to give them the benefit of the doubt.
Erm ... you do realize that that can not possibly be the case, right? That a bank can not possibly be obligated to give money to a customer simply because the customer demands it?
> If you have an airtight case against the bank you wouldn't need it in the first place. I'd think you understand this concept, given that you're from the EU.
You are completely missing the point. There are cases where the bank is at fault (like, they simply handed your money to someone else for no reason) and you can show it. That's the case where the bank's general l...
In the UK at least, the regulations cover the third category i.e. where you can't demonstrate fraud, but neither does the bank have reasonable grounds to suspect you acted fraudulently. From https://www.fca.org.uk/consumers/unauthorised-payments-accou..., explaining when a bank is allowed not to refund you (although they are allowed to refund you and then ask questions and report you to the police).
"""
Why a refund can be refused
Your bank can generally only refuse a refund for an unauthorised payment if:
- it can prove you authorised the transaction – though your bank cannot simply say that use of your password, card or PIN conclusively proves you authorised a payment
- it can prove you are at fault because you acted fraudulently or because you deliberately, or with ‘gross negligence’, failed to protect the details of your card, PIN or password in - a way that allowed the transaction
- you told your bank about an unauthorised payment 13 months or more after the date it left your account, so make sure you contact the bank as soon as possible.
"""
Gee, what is your point? Whatever the exact rules are: There are cases where the bank will not be able to distinguish an actually fraudulent transaction from a legitimate one. In those case, you, the customer, will be stuck with the loss, there just is no way around that, other than preventing the loss in the first place.
OP explicitly listed the text explaining that in the case you describe the bank cannot refuse to reimburse you. Essentially, the burden of the proof is on them, not on the customer.
Suppose you had one legitimate transaction, and one fraudulent transaction. Now, suppose the bank had certain evidence to show that the legitimate transaction is legitimate that is sufficient from a legal perspective to refuse your refund request. Then, suppose the bank had no such evidence to show for the fraudulent transaction.
And now pay attention: THE FACT THAT THEY DON'T HAVE EVIDENCE FOR ONE OF THOSE THAT THEY DO HAVE FOR THE OTHER MEANS THAT THE BANK CAN DISTINGUISH THEM. Got it?
I was talking about cases where the bank is NOT ABLE TO DISTINGUISH an actually fraudulent transaction from a legitimate one. Your response "but if they are able to distinguish them, they have to refund you!11" is just completely irrelevant to the point that I was making.
Please keep calm - there's no need to shout. If for no other reason, it's harder to read all caps.
We are not making the point you think we are.
We're all clear that if the bank can distinguish, they must refund legitimate cases, but that's not what we're trying to explain either. Responding to your last paragraph alone:
"I was talking about cases where the bank is not able to distinguish an actually fraudulent transaction from a legitimate one. Your response "but if they are able to distinguish them, they have to refund you!11" is just completely irrelevant to the point that I was making."
My response is not "if they are able to distinguish them, they have to refund you". It is "if they are _not_ able to distinguish them, they have to refund you".
"There are cases where the bank will not be able to distinguish an actually fraudulent transaction from a legitimate one. In those case, you, the customer, will be stuck with the loss"
No, that's contrary to the FCA regulations. In cases where you can't tell if there's been a third party committing fraud, the benefit of the doubt must be given to the consumer. If the bank cannot demonstrate that the consumer is committing fraud, they cannot refuse the consumer their money.
It's obviously complete nonsense to say "_whatever the rules are_, in scenario X the bank will be able to do thing Y"; in this case the rule is "in scenario X, the bank is not permitted to do thing Y".
If the bank satisfies a court with evidence to show the customer committing fraud, then the customer won’t get their money back. Just like if the CPS satisfies a court that someone committed murder, prison will follow even if the person didn’t kill anyone.
This thread is rapidly losing value to readers now, since you seem to be dishonestly representing what you’ve previously said, at best guess because you don’t like to be wrong. Quoting you:
“the somehow fraudulent order where the bank doesn't see any signs of fraud and you can't demonstrate it either.”
“That is the category or fraudulent transactions that are indistinguishable from legitimate transactions by anyone but you”
“There are cases where the bank will not be able to distinguish an actually fraudulent transaction from a legitimate one.”
Only now have you changed this to apparently mean the bank can falsely prove the customer committed fraud.
There’s nothing wrong with not being up to speed on recent banking regulation changes in the UK. There is something wrong with pretending you were saying something you weren’t, just for the sake of internet points.
I’ll add an example to help get across how the regulations have changed:
If someone calls me pretending to be my bank and tricks me into giving them enough details (passnumbers etc) to move money out of my account, or persuaded me to authorise transactions they’re making (because I think they’re the bank saving the money from being stolen by someone else), then the transactions will look real to the bank. Previously, that was my problem. Now it is the bank’s - I may have divulged my details in good faith, but I didn’t give the criminal any money. The bank, unwittingly, gave the criminal money. The bank is no longer allowed to claim it was my money. Rather, the bank still owes me my deposit - nothing has happened to change that.
This has been a more commonly occurring crime in recent years, and the regulations are specifically there to:
Protect the consumer
Put the onus on the bank, to encourage them to do better protecting their money.
> This thread is rapidly losing value to readers now, since you seem to be dishonestly representing what you’ve previously said, at best guess because you don’t like to be wrong.
No, you are simply concentrating on the ultimately irrelevant details. I was not talking about any particular jurisdiction and their banking regulation, but about the fundamental problem that no banking regulation could possibly solve. Possibly I expressed that badly when I phrased things in terms of specific criteria that, of course, can lead to different assignment of liability depending on jurisdiction, but then, I would think that it should be clear from the context that that is not what I particularly care about here.
The fundamental problem is that you are trying to determine someone's intent. Ideally, you would want to be able to distinguish exactly when the bank customer intends to effect the execution of whatever order they formally have given you, and when they don't, either because they weren't actually involved in authorizing the order, or because they are somehow mistaken as to what the order they have given actually entails. If we could do that, the bank could refund all fraudulent charges without being at risk of being defrauded itself (or, ideally, prevent the fraudulent transaction in the first place).
It's just that we don't have access to someone's intent. All we have is someone who claims to have had a different intent than what the bank believes (or claims to believe), and who has a motivation to lie about that claim. But there is nothing that would be externally accessible that necessarily distinguishes someone who ordered some transaction fully understanding what that order entails and someone who gave the same order but was mistaken about what it entails. In some (maybe many) cases, you can have strong evidence that supports or contradicts the fraud claim, and those then generally can be resolved correctly. But there is absolutely no guarantee that you have any reliable evidence in either direction. And if you don't, there is no easy and reliable solution. You can not just say "if you can't know for sure, you have to refund", because you never can know for sure, so the bank would always have to refund, thus resulting in a massive fraud risk for the bank. Or you could say that, but it's just not gonna happen. The bank will always be able to avoid refunds without demonstrating beyond a doubt that the cutomer was trying to defraud them, or else they could not defend at all against people trying to defraud them. And as a result of that, there is always, unavoidably, the risk that you, as a customer, will be defrauded by a third party, and, no matter what the regulation, you will not get a refund because the bank can show sufficient evidence to convince a court that it was likely your fault according to whatever the specific rules are.
And all of that is relevant in this context because TFA suggested refunds as a supposed solution to the problem of weak passwords, and that is bullshit. While shifting much of the liability to the bank via regulation certainly helps in many cases, it can not, in principle, ever be a complete replacement for strong passwords. As far as guessing credentials is concerned, only strong, high-entropy, credentials actually solve the problem, solve it trivially (assuming the customer cooperates, of course), and solve it without exception.
> Who seriously believes that banks will give you your money back on your word that you didn't authorize some transaction? Of course, they won't, they'd be wide open to fraud if they did.
Anyone who has ever had it happen to them, i.e. me? Not sure where you live but this is a legal requirement where I'm from.
That's good to hear, but after how long and at what cost to you (time on the phone, sending documentation, basic stress, etc.)? And even if the mistake can be corrected easily, it's still better to prevent the mistake in the first place.
The 5 number 3 tries bank does not seem very secure:
It is (at least in my country) very easy to guess valid acount numbers: They are incrementally numbered + have a checksum. So while 1 account of a 5 number 3 tries bank is safe, attacking all of them in volume is not:
With N numbers, T tries, A accounts, the chance of guessing at least 1 account is
pow(1-T/pow(10,N),A)
5 numbers 3 tries means a chance of 0.9997 of being locked out of 1 account. For A=100 000 accounts, the chance is 0.049, so more than 95% chance you guessed one account right. For A=1 000 000, you're almost certain.
And that's the dumbest possible way. Try guessing with the most common password like 12345, take only 1 try each month so people unknowingly reset the account number when doing payments, and use a botnet to spread the load over tons of IP adresses and randomize the numbers.
I think this is exactly right. My bank has predictable account numbers too, and if they had one of these 4 or 5 digit password limitations, they would be a very ripe target for someone using a botnet to just go through all the accounts. The risk isn't that someone will target you personally, the risk is that someone will happen to hit you while attempting the profitable activity of hacking every account. (Plus, at least with a bank, if they manage to hack in and steal the database, one of the most profitable ways to use it would just be to log in and steal money. No effective hashing on a 5 char password.)
I also completely distrust the "advanced security measures" claim. I have no trouble logging into my bank via curl, including from remote IP addresses. (They finally rolled out 2FA, but I can still type the text code into my script.)
A couple years ago I discovered a number of vulnerabilities in their account site, too (including some many years old software with vulnerabilities with a CVSS of 10). After I reported this to them, the response from the guy who worked there was basically "Yeah, that's from the crappy vendor who supplies us with this software. Please don't say anything about this because we're replacing it with a new in-house backend in a couple months."
> Banks typically use customer registration numbers as opposed to user-chosen usernames or email addresses so there goes the value in credential stuffing lists.
I've had accounts at most of the major US banks and I don't think I can think of a single one that did this. Almost every single bank allows the user to select a username or occasionally uses email for login. This is not a good argument for Chase, Citi, Amex, Discover, Capital One, Barclays, and a whole bunch more I can't think of off the top of my head.
the money is in hacking bitcoin/crypto-related stuff anyway. Get the 12 words and there is nothing than can be done to recover the $ and nearly untraceable. hacking banks is overrated unless you can not onyl produce a facsimile of the victim including ID and other docs but also get past all the restrictions and then not be found and arrested in the process.
> Do you really think the only thing the bank does to log people on is to check the username and password?
Yes, I do think that. I automated some banking functions for myself and the last 4 retail banks worked just fine when accessed with curl, or headless chrome. I didn't even change the user agent for curl and used no delay between requests. Not only do they trust credentials, there are no extra checks in most cases. This is experience from UK and Oz. Lloyds, CommBank, ANZ, ING.
ING is actually the "hardest" one. Their 4-digit scrambled keypad varies colours slightly so it requires closest-match comparison to known samples. That was like 3 extra lines of code.
Access control is not on a binary 'yes-or-no ' decision on a per single-signal basis.
It is usually a weighted result of multiple signals. For example, it may look at say 20 factors and have a failure threshold of 15 passed. Most of the signals are evaluated server-side.
By design, some signals used are picked such that customer convenience, among other things, is not affected (e.g. the account holder data pull automation that you describe in your example ).
Examples of signals include timezone, time of login vs. past logins, hardware profiling (OS, screen resolution, IP, ISP, VPN vs. no VPN - based on known VPN server lists ) etc.
I agree that not all banks are doing this but the more sophisticated ones are (quite a few of them). Point here is curl or headless browsers working is not evidence of only account and password being checked.
Or in short: It's an untestable claim. No possible result of any experiment will count as evidence that there isn't a magic security system in place that will protect you but that through its magic figured out that your legitimate access was legitimate.
Genuinely looking for clarification - what does "untestable claim" means to you in this context?
If it means that you personally can't test it, then yes, it is an "untestable claim" and you are right, the whole thing is effectively a magic black box.
If it means that some other party/authority can't test it, then no, it is the opposite - a "testable claim" - to use the nomenclature put forward.
As a counterpoint to illustrate this, others who can, and do, test include:
1) internally (within the bank itself)
+ risk management: they define acceptable level of risk for login architecture & management
+ enterprise security: they define standards for login architecture among other things based on risk standards
+ infosec - they enforce ent. security standards
+ finance/analytics: test stuff like
"what did we/our customers lose to this type of fraud before/after we implemented this black magic box"
+ internal auditors (IT): assess and report on compliance
2) externally (outside the bank)
+ external auditors (who believe it or not, actually test this stuff)
+ regulators (who can mandate security levels in some jurisdictions - esp true outside the US)
+ pen-testers: banks hire them to ensure that the security posture works
In large bank environments, developers cant simply put out a username/password login architecture and expect to see it deployed to production.
There are a ton of other groups defining what they MUST do. The degree of functional separation in (large) banks is astounding - but it mostly works - because everyone has to toe to requirements defined by other functional groups.
I would argue that another CS-related analogy to this is machine learning. Everyone says they do "ML", most people don't understand it, some do understand it and a few understand it deeply; from an execution perspective, most are doing it ML badly, some doing it OK but there are a few are doing it really well because they understand it really well.
As with ML, for the case of user access management, the fact that *most" are doing it badly does not negate its (very real potential) value if done right.
> Genuinely looking for clarification - what does "untestable claim" means to you in this context?
Simply what I wrote above: The fact that no observation counts as evidence against the claim, every possible observed behaviour can be explained by "it's magic". That includes the behaviour of all the components of the system, including the people. You claim that there are all those people and roles that make sure that crap doesn't go to production. I make the observation that those people and roles and whatnot have decided to implement a 5-char limit on passwords. You respond that "it's magic". No matter how obviously terrible the observable effects of the system are, you will find some rationalization why the black-box magic can exhibit this behaviour while also being perfectly secure.
In case you aren't aware, it's a term from epistemology/philosophy of science.
Thanks for taking the time to explain that, much appreciated.
I was not aware about the epistemology / philosophical implications of the "it's magic" comment.
I took the literally reading of your comment.
Can you point me at some stuff I can look at to start learning a little more about this - sounds like the kind of interesting stuff I should be reading late into the night rather than working on the sleep I should be getting.
could be starting points? I dunno. And, yeah, "it's magic" is just a placeholder for a random ad-hoc rationalization that you can make up in any such situation that would explain the given observation while some apparently contradicting claim is also true. The problem is when there is (almost?) no observation that would make you go "ah, ok, I guess this claim is bullshit after all", because you can always make up some story as to why it might not be.
There's no reason we should assume that's happening behind the scenes. Password practices, on the other hand, don't require assumptions because everyone can see exactly what they are.
I did it scheduled past midnight, from "abroad", from known AWS us-east ranges, with headless resolution set to 1000x1000, completely ignoring their browser detection JS, identifying as either curl or "bank bot", not following links and redirects, causing lots of unexpected failures which should be impossible with a normal browser while developing my scripts. (including 503s from bad csrf token passing)
Basically if there was any check, I would fail it. I did that on purpose - better to know immediately than get silent failures later on. I really don't know what else I'd have to do to trigger "this it not a real person" detection.
Thanks for taking the time to explain this: it does indeed seem clear that they are just doing username and password detection for access.
A followup question: I have lived in Europe and have accounts in banks in Ireland. For those accounts, actually executing any financial transaction requires entering a one time token generated by a device that uses your debit card and PIN.
Just trying to find out if these specific banks have chosen to control view transactions with just the username / password but require some other additional authentication for actual financial transactions.
None of them required extra authorisation to get data. (even transactions going back 5+ years) They did have the SMS validation when adding new transfer targets, but not for executing transactions to existing contacts - which is potentially an issue if you can pay off a different credit card just by changing the reference field.
am with an FI (financial institution) in the great white north (I am, of course, not speaking for them in any way here) so this is all very very humbling. One theory that I have heard through my network is that event may be the result of agile / sprint work outside regular process ... but it is an unconfirmed rumor... and I do know for a fact that not all platforms are like this...
The assessment of security capability from the guy who found the code + credentials in the wild is brutal! - '"In my experience, this muppet-grade security is perfectly normal for Scotiabank, as they usually leak information once every three weeks on average," Coulls mused.'
I agree, particularly since I have never been refused any service online with my bank, despite having logged in from a heterogeneous set of devices and locations.
The challenge is that if a system only offers a four or a five number passcode, you can still attack accounts by just guessing passcodes for account names/numbers. This is addressed a little bit by pointing out that it’s sometimes not easy to enumerate accounts - but if you’re malicious and have purchased a list of compromised accounts, you could then pound the system from a botnet even after the passwords have been changed. In this case you’re not concerned about a _specific_ account, but rather you’re concerned about _any_ account. And with a 4 or 5 number passphrase, you’d get hit pretty quickly.
If you knew the bank and the account, you could assume that people login to their account atleast once a month. So every month you could try a combination. Known passcodes could be tried first. If a dump also has the person Birthday then their birth year is a good Guess for a 4 digit pass code. 2 failed attempts reset when the user succeeds their login during the month.
There’s so many things people could do. Limiting passwords is a bad idea :/
I cannot believe ANY banks are using passwords at all in this day and age. Reading discussions like this makes my brain hurt - even a decade and a half back we were on chip and pin card readers for login/signing verification, now since a long time back there's a universal app-based 2fa equivalent (Mobile BankID).
That's not the case for "my bank(s)" but all banks here.
I wonder what makes the US/UK/AUS so special? It's all incredibly alien.
Moving from a country with Mobile BankID to the US, all I can speculate is that it's not a big enough problem for the banks to make the investment. Similar to the healthcare system keeping the status quo is "cheaper" until you're one of the unlucky ones...
Amazon really understands what security means. When it does 2FA, sends you a unique code by email, it disables the option to paste that code back into the login form, you have to type it. You know you are dealing with really competent people when you see that!
My favorite is "locking the account after x number of password attempts".
Ever want to annoy the hell out of someone? Try their username or email a bunch of times and lock them out of their accounts. Bonus points if it's one of those super duper ultra secure banks that does password resets via snail mail.
/s [I don't condone doxing anyone. My point is that an attacker should not be able to modify the state of a system he's unauthorized to access]
That seems to be the least objectionable to me. You need to have some protection against brute-forcing. Whether it's limiting the rate of guessing or whatever, the attacker is still "modifying the state of a system."
Indeed, that's a weird rule. When someone stole my credit card number and ran up charges, my bank called me to verify them. How was that not "modifying the state of a system?"
> You need to have some protection against brute-forcing. Whether it's limiting the rate of guessing or whatever, the attacker is still "modifying the state of a system."
You could just make brute-force searches unproductive, for example by requiring a hardware security key or client certificate rather than a mere password or PIN. Good luck brute-forcing a 128+-bit random secret.
> When someone stole my credit card number and ran up charges, my bank called me to verify them. How was that not "modifying the state of a system?"
The state of the system was modified when an unauthenticated (never mind unauthorized) individual managed to run up charges on your account using only your credit-card number—which is "sensitive" information but not actually secret. That should not have been permitted in the first place. If the rule had been applied properly then this remedial step would not have been necessary.
> You need to have some protection against brute-forcing.
Yes, that protection is called "password".
> Whether it's limiting the rate of guessing or whatever, the attacker is still "modifying the state of a system."
Which is why you should not limit the rate of guessing (or at least offer that option--limiting the rate of guessing does help users who use terrible passwords, after all).
> Indeed, that's a weird rule. When someone stole my credit card number and ran up charges, my bank called me to verify them. How was that not "modifying the state of a system?"
Which is exactly why that shouldn't be a thing. Being able to pay with a semi-public number is just stupid. You should have to authenticate using a strong password, and "stealing credit card numbers" simply wouldn't be a thing anymore.
No, it can't. If you are willing to say that a cow can not jump over the moon, then a strong password can not be brute-forced, even though it might theoretically be possible for a cow to quantum-tunnel over the moon, and it might theoretically be possible that an attacker guesses your password. The probability is so vanishingly small that you would call it impossible in any other context.
We had a situation like this at work. My username was very common and got locked on our ssh proxies like clockwork with just the routine background internet scanning. I couldn't get any traction with getting this fixed. We had hardware 2FA (physical tokens), so brute forcing was effectively moot.
Then, strangely, various senior folks found their accounts getting locked 1-2 times a day, including the founder. That autolock policy died in a week, and they started looking for 2FA failures instead, as they should have.
I had considered "accidentally" setting up a ssh loop to do this but never quite got around to it. I assume somebody else did. I doubt that an infusion of sanity happened by accident.
I did that to an overzealous sysadmin who wouldn't see the light about why a 30 minute password lock policy after three failed interactive tries with horrendous complexity requirements was a bad idea.
Typed in his email address in front of him, hit enter three times, locked him out. Since this was a military base, typed in the commanding officer's email address, started to do the same thing, and suddenly the sysadmin saw the light shine down from heaven.
> That very first tweet touched on the first reason why it doesn't matter: banks aggressively lock out accounts being brute forced.
Until a hacker steals the salted password database and brute forces it as much as they like. A truly strong password is secure even when the attacker has the salted version.
(Anyone who tells you that it's completely impossible for a hacker to ever get their password file is lying either to you or to themselves.)
What's odd to me about this post and all of the responses in this thread so far is that everyone is only thinking about password length as a way to defend against online bruting attempts when in reality long passwords mostly serve to protect against offline bruting attempts. The reason you don't want 6 or 8 character passwords is that when your password hashes get dumped it's a lot easier to crack them.
"What's odd to me about this post and all of the responses in this thread so far is that everyone is only thinking about password length as a way to defend against online bruting attempts when in reality long passwords mostly serve to protect against offline bruting attempts. The reason you don't want 6 or 8 character passwords is that when your password hashes get dumped it's a lot easier to crack them."
This is:
i) not accurate
and
ii) bad info
Password hash dumps are worthless if the password hashing scheme used is i)crypto-hashing based and ii) uses salt.
6-8 char passwords are not an issue under this scenario. Current password management best practice is to use both standard crypto-hashing algorithms and salt.
Almost all platforms use standardized crypto-hashing packages that come as standard libraries in the language these days and those require salt. Further, almost all banks will all use these packages.
This is the reason you do not see rainbow tables these days, they are worthless in face of almost any current acceptable crypto-hashing implementation ... assuming one does break rule #1 of crypto and try to roll their own crypto ...
Salting also has the additional benefit of making brute-forcing magnitudes of difficulty harder. This is because salting rules can be implement that always add non-standard chars..
As others have said, the 6-8 chars limits are are a function of legacy system somewhere in the application chain (online banking is never a single platform, it is usually a front-end that talks to a standard backend that tellers, operations etc also access, usually some type of greenscreen app - which is where the password hashes end up).
I'm not talking about rainbow tables or hash tables, I'm talking about straight up bruting with GPUs and hashcat. You seem to be implying that using a salt adds entropy, but the salt is known (plaintext) and it's added in a set way so it doesn't. Sure your choice of algorithm and complexity factor will definitely affect your guess rate and ease of bruting, and yes using a salt prevents the use of precomputed hash tables, but it's not like it's impossible to crack a salted 6-8 character password hashed with bcrypt if you throw enough GPUs at the problem. The only question is if it's cost effective.
So let's assume a 6 character alpha-numeric password with upper and lowercase. 36^6 possible passwords or about 2.1 billion.
The article linked is one guy and one machine who can do 156 bcrypt hashes per second, with salted hashes.
That's ~161 days to hash them ALL.
If you have a dump of thousands of passwords it's extremely probable to get a few of them in under a day. Which is what the article shows - common short passwords were owned.
What's funny about the additional restrictions (you must use 2 upper, 2 lower, etc.) is that they reduce the complexity of this problem so there are fewer possibilities the attacker needs to check for. So you're making it more difficult for users while decreasing actual security against this kind of attack.
Much better policy is something like, "at least 16 characters, whatever ones you want." Easier for users because then passphrases are possible, easier to implement because there's only a string length check on the client, and more secure because it doesn't completely rely on users not choosing trivial passwords.
> What's funny about the additional restrictions (you must use 2 upper, 2 lower, etc.) is that they [...] decreasing actual security against this kind of attack.
Not necessarily - the additional restrictions might prevent even more common short passwords from being used by the users, thus making it harder for both the user and the attacker.
(If the bank says you can't use "Password" as your password, then yes, the attacker only needs to check 62^8 - 1 passwords instead of 62^8, making it insignificantly "easier" for the attacker, but at the same time a lot of people must switch from "Password" to something else, making it much harder for the attacker).
EDIT to add: Having said that, what you propose (at least 16 chars, no other restrictions) makes perfect sense (maybe introduce a maximum of 32k chars).
I get the math and the idea that one password can have all combinations hashed in 161 days for this specific scenario - which is a 6-8 char password that does not allow non-alpha-numerics.
I do think I forgot to add that I was thinking about all of this not just as a theoretical problem but in the context of a single end goal: accessing some random's bank account for some large {randoms} through some front end tool that is protected a 6-8 char password.
Keeping this in mind: running this 161 day process results in a list of 32 billion hashes - useful only for a single account - that you really cannot do anything with since:
i) you don't have bank's stored hash to test against
and
ii) you can't use the front-end access to test a hash
If an attacker has back-end access to some DB or app to test the hash, you didn't need the hash in the first place to do nefarious stuff. You are already in.
Point being that, yes, I do get it now that a 6-8 char password is much weaker in that it can be cracked in 161 days. But it is a really expensive attack to mount for a single account that may not even hold the cost of hardware and time spent mounting it. This strategy just does not scale to huge volumes of accounts.
From a bank's risk management perspective, the potential losses associated with a successful attack of a single account in this fashion are more than manageable. It is cheaper, long term, to refund a clients up to $YYMM than it is to pay for one-time development work across all platforms to remove the 6-8 char restriction.
Remember that security posture here has multiple layers. For example, for accounts with significant funds, you can definitely get in the front end with this approach but once in, you still have to deal with other protection schemes before being able to tap into any funds (e.g. multiple 2FA / RSA / PIN / keyword challenges, IP and/or time of day and/or destination gating etc ).
This is even more important because banking systems with legacy password limitations (e.g. 8 characters) generally imply that there's also legacy password management - meaning that it's very possible the approach to hashing is outdated. bcrypt or scrypt is a best practice but it's far from universal in brand new software, the systems these banks are using were likely developed before either algorithm was published.
I'm even ignoring here that many banks at least recently used to provide strong hints that they are storing passwords in plaintext, such as by using a modified form of the password as a telephone passphrase.
>Password hash dumps are worthless if the password hashing scheme used is i)crypto-hashing based and ii) uses salt.
>6-8 char passwords are not an issue under this scenario.
I don't think so. Unless you meant something other than cryptographic hashing when you say "crypto-hashing". SHA-256 is a cryptographic hashing function (much more likely to be used at a bank than something like bcrypt I would wager) and a GPU is going to do on the order of a billion hashes per second. So cracking a 6 character password in minutes.
A salt will make a set of passwords harder to crack en masse, but if they want your specific password, salting isn't going to make that any harder.
When the accounts of our company started to be beyond the low 6 figures, we got upgraded by our bank to a different online banking system with a smartcard and a keypad for strong 2FA.
Our admin team is informed every time someone logs in the system, and wiring money is a 2 phase process. If a transaction is unusual, the bank usually contacts us.
So yes, I do think banks have additional protection measures, it's just not worth it for smaller amounts where the insurance will just cover it.
>> Hey [bank], does that 16 character limit mean you've got a varchar(16) column somewhere and you're storing passwords as plain text?
> As much as I don't believe that's the case in any modern bank of significance, it's definitely not a good look. Inevitably the root cause in situations like this is "legacy" - there's some great hulking back-end banking solution the modern front-end needs to play nice with and the decisions of yesteryear are bubbling up to the surface. It's a reason, granted, but it's not a very good one for any organisation willing to make an investment to evolve things.
But the only reason that "legacy" system would have a limit is because it's storing your password. So
> I don't believe that's the case in any modern bank of significance
It _is_ the case. It may not be the case in their most recent systems, but a chain is only as strong as it's weakest link. You can be hashing/salting the user's password and locking it behind a vault door to make sure noone can access it. But if you _also_ keep a copy of the password in plain text on a piece of paper taped to the outside door, the vault copy doesn't protect it.
My bank allows arbitrary length, but enforces certain special characters while disallowing others. Which means I can't use the (long and secure) password and have to write it down.
I think basically everyone in this thread is looking at this all wrong. Banks don't have a ton of fancy hidden security gating the login itself most of the time. Trying to build a digital Ft. Knox in front of the login page and then paying no attention to what the users do after they login is the wrong way to go about securing these types of accounts.
I'm pretty sure they have much more security around detecting and blocking suspicious behaviors after you've logged in, like adding new payees on bill pay systems, requesting transfers of large amounts of money to random accounts, particularly overseas, etc.
I also argue that banks have much, much better security than anything most of us have ever touched, because they handle billions of dollars moving around routinely and manage not to lose it. Meanwhile, half of the internet can't manage not to lose the email addresses of everyone who signed up for their cat picture website. If they're trying that hard to steal something of little value like that, how hard to you think people are trying to steal the billions of dollars that banks handle?
"
I also argue that banks have much, much better security than anything most of us have ever touched, because they handle billions of dollars moving around routinely and manage not to lose it. Meanwhile, half of the internet can't manage not to lose the email addresses of everyone who signed up for their cat picture website. If they're trying that hard to steal something of little value like that, how hard to you think people are trying to steal the billions of dollars that banks handle?"
Exactly this is the reason why I don't think Troy is being gullible here.
I do not argue that they're competent because they're important. I argue that they are competent because there is a multi-billion dollar pile of cash that they're guarding. If they aren't competent, how come nobody has stolen it all yet?
Look at the efforts spent hacking Bitcoin exchanges and identified large holders. Lots and lots of money being taken there. Look at the efforts made to hack much less important things. How come no big banks have suffered a serious compromise leading to the loss of 9-figure plus amounts of money yet?
Banks normally don't actually transfer any money. There's a funny story from the 1920s of the Bank of England pushing money across the vault floor to indicate a transfer to France, who held an account with them. The money doesn't actually go anywhere, it just says so on the balance sheet. If someone "steals" 1 billion dollars by making the system think they took it, someone will eventually notice, then they'll send somebody down to the vault to push it back to the other side.
Bitcoin is very different: when the bitcoin blockchain says someone else has your money, they have it. Imagine someone had heard that Ethereum had suffered no major attacks on exchanges, but hadn't heard of the DAO attack. They must think that Ethereum is extremely secure. Actually, Ethereum is very insecure, but a large enough target will get special treatment. Bitcoin doesn't have the same tendency as Ethereum (and real life) towards hard forks, so of course it will have more attacks on it. But this doesn't imply that anyone will hard fork when you get hacked, nor will the banks necessarily reverse the transaction when someone guesses your password.
I have USAA and they are pretty bad as well. Max password length is 20 characters. They only do MFA through cell phone numbers and email which allows someone to Sim-Swap if they are able to get your username and password. To top it off, they have a mobile app knock-off 2FA screen, but you _can not_ see it when you're trying to log in to your account via the mobile app because the modal doesn't let you leave the input screen.
I was going to write them an email, but they have no clear email to report security concerns so I figured they don't care.
Extra stupidity: you literally can't use the USAA app on a rooted Android device; it'll detect that the phone's rooted and refuse to let you login. God forbid I assert control over my own goddamn device, right? It ain't USAA's job to lecture me about my own device security; its job is to shut up and show me information about my car insurance.
Given the nature of HN, I'm sure many of you have had inner-contact with financial technology infrastructure. Are there any banks that stand out for their technical competence/incompetence? Which bank(s) would you patronize/avoid?
Sure, three-strikes-and-out reduces probability of brute forcing any particular account with forced 5-digit password, but if an attacker has a list of just 25k usernames, odds are that at least one is going to get brute-forced.
Wow this made me laugh. I spent long time working for banks, financial institutions, and credit agencies. "So many things that lock the account down" Really? Out of ALL of articles about breaking into systems leveraging techniques like lateral attacks on systems, and this is supposed to be believable.
People ask me what it was like working there as far as processes etc. I always say the same thing. "Banks are like the mafia. They have a lot of money, and they don't like giving any of it away." Banks (especially) care about 2 things, money and risk. They spend just enough money to mitigate the risk and then stop. What this means is that they may buy good systems to help with security administration, but rarely did I see them take extra time to make sure they have multiple security redundancies like Troy describes. Employees were "trained" to what the letter of the law required. Don't get me wrong, there were some great people there, but let's not pretend they only hired from a select group of highly trained and extremely smart people. It's just like almost anyplace else. Employee's and contractors are there to get a paycheck and go home. They do what risk wants and when their done, bam they go home til tomorrow, because the fights just not worth it after a while.
I briefly worked with a sales guy from a vendor we used, and he used to work in the banking industry. He had the best quote (that I shamelessly stole) to describe banks. He said, "If people knew what I know about banks, mattress sales would skyrocket."
People tend to get lost in mathematical technicalities in these discussion. Yes, even really dumb limitations leave 100k+ possibilities open, much more than you can brute force with a three-strike-lockdown. But that's not making it ok. Even if some crafty hackers on the other side of the world find a way to crack my account I'm confident the bank will look at the possible PR and legal costs and just refund my money fully, yes, yes, wonderful. That is not the problem.
The problem is user inertia. Let me speak as an averaged one, mixed with my own deeds prior to being knowledgeable in cyber security.
If I'm forced to remember my password because my password manager gets shut out or because of weird requirements, like uppercase letter + two numbers + non-alphanumeric, I'm nudged to use the same variation of my "default password" I used before, 27 times.
"DognameBirthyear&".
"+KeysThatAreCloseOnTheKeyboard1234+".
And of course, I use a slight variation of that for everything. Shady web-server-under-the-desk web forum in 2007 three of my friends were on. Indie game servers, another classic. Bank. Google. It also was my facebook password which I gave to my bff once to check if that cute boy really liked me. It also can be guessed by obtaining my ID and watching me super slowly type the added non-alphanumerical at the end.
This opens the very real possibility of revenge of ex partners, witty people at the coffee shop gaining access and the like. Crimes are committed overwhelmingly by people knowing the victim. No fancy AI is gonna help you with that, reasonable withdraws in the middle of the day in your time zone from your own MacBook's IP address. Good luck with customer support. You are enabling THAT with your dumb requirements.
And why?? You are a bank, hire someone who knows their job and does not just act on blog spam FUD or whereever you got the idea of exactly 5 digits numbers only. No, I choose to be mad about this because there is no excuse for such horrifying UX and security.
Just enforce a minimum limit of like four characters to prevent breach by putting down coffee mug on keyboard, enforce a maximum limit so you don't fall victim to an embarrassing flavor of DOS attack. If you feel fancy, throw a bunch of money at haveibeenpwned to check whether people are putting dumb passwords and let your local RegEx wizard check against all other silliness. There you go. I even waive you the $150k fee for that extraordinary piece of consulting.
228 comments
[ 1.8 ms ] story [ 248 ms ] threadHere is a link to a hackernews thread discussing the worst of the requirements in the repository is here [3].
[1] https://github.com/dumb-password-rules/dumb-password-rules
[2] https://twitter.com/dumb_pw_rules
[3] https://news.ycombinator.com/item?id=20890381
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.
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.
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.
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 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
I'm not looking forward to the mandatory phone auth on "3d secure": https://www.sagepay.co.uk/support/12/36/3d-secure-explained
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.
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?
>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.
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?
You're assuming that the lockout counter resets on successful login. Maybe there's a daily failed login counter.
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)
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?
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.
> 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)
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.
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.
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?
> 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.
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.
It clearly makes sense to tie the session to the IP address but the 10 minute delay doesn't make much sense to me.
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.
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.
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.
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.
So yes, they will pay for it.
So I feel for Chase in this situation, I'm not suggesting they shouldn't have paid out.
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.
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).
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.
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.
> 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.
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
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.
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.
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 bet they have something like IP address origin checks and nothing more.
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
I'll update if I remember the name.
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 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.
The last two I've spoken with had read-only access to _everything_. The entire company did.
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.
Because if someone gets in, they're going to refund you.
But presumably the data from those trackers feeds into the hidden backend heuristics the parent commenter mentioned.
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'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 aren’t. You trust that if your money is stolen in a hack, the bank is liable for your losses.
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.
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.
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.
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...
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.
They could be doing 2FA when someone logs in with a new device too.
Yet this pension company has millions of customers, and presumably isn't seeing widespread fraud. How come?
Fraud happens. Financial institutions spend a lot of money defanging it; they also, when push comes to shove, have budgets for it.
All this is mostly public info as it has to go into financials, you can find it under "Operational Losses" for any public bank (Note that "Operational Losses" are not the same as "Operating Losses").
A sample multi-year summary can be found here from an industry body in Europe for losses for debit. (losses are demonimated in Euro):look at page 7 under the last column for the rows "Retail Banking". Important to note that credit ops losses are an order (or maybe two) of maginitude higher.
https://managingrisktogether.orx.org/sites/default/files/dow...
But even worse: The idea that locking users out after so many failed attempts is a security mechanism. When a small bandwidth of unauthenticated requests can disable a critical service, that is known as a denial of service vulnerability and not a security mechanism. If you have proper passwords, locking users out is completely useless for security, but it's still a DoS vulnerability. A brute force attack will not crack a 128 bit random password, no matter the rate at which it is tried. And while non-public user IDs can help mitigate that risk, it is not at all a given that banks don't use essentially public account numbers as user names, even ones that have 6-digit password limits. Plus, the user ID at that point effectively becomes part of the password, just that it's a password that you can't change, which isn't exactly brilliant either.
And finally: It's quite a failure at assessing attack scenarios if you think that user lockout actually solves a problem. Your typical bank has a failure counter per account. A failure counter that is reset on every successful login. So, the real number of attempts an attacker could make is the number of attempts you have before lockout minus one, multiplied by the number of successful logins by the customer. An attacker might not necessarily be able to know very well when the user has logged into their bank account, which sure will limit the exploitability somewhat, but then, that very much depends on the circumstances. If you know someone pulls their transactions every 15 minutes, say (especially a business, which might even leak the time they pull transactions by sending payment receipts in response, for example), then you might very reliably be able to make 8 guesses per hour, or ~ 70000 per year, without causing lockout. If you instead want to target the general public, you might also just use a bot net to attempt login into accounts only occasionally, risking some lockout, but statistically compromising a certain number of accounts over time.
And all of that when proper passwords do solve all of those problems perfectly reliably.
Oh, yes, and the idea that some banks will give you your money back? Seriously? Now, if that isn't a failure at assessing risks, I don't know what is. Who seriously believes that banks will give you your money back on your word that you didn't authorize some transaction? Of course, they won't, they'd be wide open to fraud if they did. If the attacker is good enough at making it seem like the customer authorized the fraudulent transaction, obviously, the customer won't get back a cent. Those claims by banks are marketing bordering on fraud, and obviously not something anyone claiming to be an expert in security should just trust to be something you can rely on.
But what's your threat model here? Some attacker who's targeting you that somehow got your randomly assigned username but not your password? Or someone hitting every account number for "the lulz"? In the first case, it can be resolved with a 10 minute call to the bank to get your username changed (although you have bigger issues if your attacker was able to get sensitive information such as your banking username). In the second case, the attacker will get ip banned/rate limited very quickly.
>If you know someone pulls their transactions every 15 minutes, say (especially a business, which might even leak the time they pull transactions by sending payment receipts in response, for example), then you might very reliably be able to make 8 guesses per hour,
Sounds like a very non typical use case. Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising. Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious.
>Who seriously believes that banks will give you your money back on your word that you didn't authorize some transaction? Of course, they won't, they'd be wide open to fraud if they did.
AFAIK they're obligated by law.
What do I know? DoS attacks are a thing, so that's the threat model?!
> Some attacker who's targeting you that somehow got your randomly assigned username but not your password?
You are assuming the username is randomly assigned.
> In the first case, it can be resolved with a 10 minute call to the bank to get your username changed
Wut? For one, how is being denied access to your capital for ten minutes in any way "solving" the DoS risk? Then, how does that even solve anything if the attacker simply disables your account again within a few seconds? If your suggestion is that using the username as the password somehow is supposed to protect you, I have bad news for you: You usually can't change your username, so you can not change that "password" to something the attacker doesn't know.
> (although you have bigger issues if your attacker was able to get sensitive information such as your banking username)
You have it all backwards? The sensitive part is what is called the password. If your username is sensitive, you are already doing it all wrong. Especially because, see above, you can change your password, you can not (usually, easily) change your username-pretending-to-be-your-password.
> In the second case, the attacker will get ip banned/rate limited very quickly.
You have heard of this thing called a bot net, right?
Also, congrats, you have just introduced the next DoS risk: If you happen to use an ISP where your IPv4 connectivity is only through NAT, and given that most banks are IPv4-only, suddenly, some random customer of that ISP, or the malware on their machine, can disable your access to your account.
You know what would actually solve that problem? Wait for it ... it's passwords! Like, proper, real, high-entropy passwords. Who would have thought?
> Sounds like a very non typical use case.
The idea that banks should only be secure for "typical use cases" primarily sounds like a very bad design principle.
> Most businesses I know pull transactions end/start of day. Considering most/all banking transactions (ie. not done through a third party platform like venmo) are done daily, this isn't surprising.
Except other countries have a slightly more modern banking infrastructure. All of the EU is currently introducing realtime money transfers with a guaranteed payment delay of maximum 10 seconds between any two banks in the EU. Pulling transactions only every 15 minutes seems like quite a massive delay in comparison.
> Even then, this exploit only works if there isn't a persistent login fail counter. Getting a password wrong twice before getting it right is ususal a couple times a day. Doing that 10+ times a day is definitely suspicious.
Well, yes, sure. But for one, that there is a persistent login fail counter is a big if. If you are lucky, maybe there is. If there isn't, the bank will blame you. And also, regardless, the problem still remains: There definitely is no permanent login fail counter. Customers occasionally do mistype their passwords, and that does not lead to lockout. But whatever the real maximum rate of failed attempts is: The total number of possible attempts is more than the advertised supposed maximum number of attempts.
> AFAIK they're obligated by law.
They are obligated to do what? Give you back your money because you say so? Certainly not. Be able to determine with 100% accuracy whether a transaction was fraudulent? Yeah, sure?!
It matters because you need to consider the attacker's motivations, goals, and resources.
>You are assuming the username is randomly assigned.
So? If not randomly assigned, the best you can do is enumerate all users in an unpredictable manner. It's not like sequential usernames allows you to easily guess the username for a specific person.
>Wut? For one, how is being denied access to your capital for ten minutes in any way "solving" the DoS risk? Then, how does that even solve anything if the attacker simply disables your account again within a few seconds?
It solves the DoS risk because it makes subsequent attacks sufficiently hard to perform afterwards. If your username can be leaked within seconds, the attacker probably has access to perform more devastating attacks than a simple DoS.
>You usually can't change your username, so you can not change that "password" to something the attacker doesn't know.
You might not be able to change your username online, but support can probably change it.
>You have it all backwards? The sensitive part is what is called the password. If your username is sensitive, you are already doing it all wrong. Especially because, see above, you can change your password, you can not (usually, easily) change your username-pretending-to-be-your-password.
Yes, usernames are supposed to be identifiers only, but keeping it a secret from your enemies isn't particularly hard. Please explain how the attackers are getting a hold of your username in the first place.
>You have heard of this thing called a bot net, right?
Here's why you need to consider the threat model. If it's some guy out for the lulz, using a botnet incurs a cost (both in terms of actual risk in terms of detection, and opportunity cost in terms of other things he could be using it for eg. credit card fraud, DDoS for fire, etc.). And the guy is willing to expend unlimited resources, then all bets are off. He could use amplification attacks to take down the bank's website by raw bandwidth alone. Worst case the bank mails/emails everyone new high entropy usernames.
>Also, congrats, you have just introduced the next DoS risk: If you happen to use an ISP where your IPv4 connectivity is only through NAT, and given that most banks are IPv4-only, suddenly, some random customer of that ISP, or the malware on their machine, can disable your access to your account.
Strange. I can log into my financial accounts while using VPN without a problem. You'd think that a VPN service that anyone can sign up for anonymously would invite more abuse than an ISP that you need to provide real credentials for.
>You know what would actually solve that problem? Wait for it ... it's passwords! Like, proper, real, high-entropy passwords. Who would have thought?
You seem to be misunderstanding Troy's position. He's not saying it's ideal, or even good practice. He's merely saying it's not as bad as you think. ie. having a 6 digit numeric password doesn't mean you're going to get you hacked within minutes.
>Except other countries have a slightly more modern banking infrastructure. All of the EU is currently introducing realtime money transfers with a guaranteed payment delay of maximum 10 seconds between any two banks in the EU. Pulling transactions only every 15 minutes seems like quite a massive delay in comparison.
I have a feeling that businesses that need low latency transactions aren't doing so by scraping their bank's web page. They're probably using some sort of payment provider, or the bank has an API.
>Well, yes, sure. But for one, that there is a persistent login fail counter is a big if. If you are lucky, maybe there is. If there isn't, the bank will blame you.
If anything, having a weak password gives you more plausible deniability than having a 256 bit entropy password.
>They a...
... or just use their account number that's on their website. Really, what's your point? Yes, you can potentially use some usernames as passwords. Doesn't mean it's somehow more sensible than using passwords as passwords.
> It solves the DoS risk because it makes subsequent attacks sufficiently hard to perform afterwards. If your username can be leaked within seconds, the attacker probably has access to perform more devastating attacks than a simple DoS.
What? Denying you service prevents denying you service because it makes denying you service any longer sufficiently hard, except it doesn't, because that's just another three requests?
> You might not be able to change your username online, but support can probably change it.
So, now you are just pulling stuff out of your ass? And in any case, how does any of this make any sense? Having bad passwords is a good idea, because we can use the username as a sort-of password? Sure you can, but why the heck not use the password as the password?
> And the guy really does have resources for a botnet, then all bets are off. He could use amplification attacks to take down the bank's website by raw bandwidth alone.
Erm, yeah? And why should he do that if a low-bandwidth attack does the job just fine? And in any case, how is the fact that there is one kind of DoS attack vector that you can not prevent a reason to also add another DoS attack vector, and to then use that to justify that you put in effort in order to weaken password security? Like ... what's your point?
> Strange. I can log into my financial accounts while using VPN without a problem. You'd think that a VPN service that anyone can sign up for anonymously would invite more abuse than an ISP that you need to provide real credentials for.
Which is a reason for building weakened security how exactly?
> You seem to be misunderstanding Troy's position. He's not saying it's ideal, or even good practice. He's merely saying it's not as bad as you think. ie. having a 6 digit numeric password doesn't mean you're going to get you hacked within minutes.
Yeah, having a root ssh account on your server with password "test" doesn't get you hacked within minutes. So, how is that an argument? There is real security, which doesn't get you hacked in decades, and then there is everything else that is pointlessly insecure, and in this case way less secure than he suggests in any case.
> I have a feeling that businesses that need low latency transactions aren't doing so by scraping their bank's web page. They're probably using some sort of payment provider, or the bank has an API.
... and banks use the exact same idiocy on their APIs, correct. Why would they not if they are convinced that that is how you are secure, as they seem to be?
> If anything, having a weak password gives you more plausible deniability than having a 256 bit entropy password.
Well, sure. But then, not ever having any unauthorized transactions means you don't have to worry about plausible deniability?
> That's the point of obligating it by law. It's consumer protection to give them the benefit of the doubt.
Erm ... you do realize that that can not possibly be the case, right? That a bank can not possibly be obligated to give money to a customer simply because the customer demands it?
> If you have an airtight case against the bank you wouldn't need it in the first place. I'd think you understand this concept, given that you're from the EU.
You are completely missing the point. There are cases where the bank is at fault (like, they simply handed your money to someone else for no reason) and you can show it. That's the case where the bank's general l...
""" Why a refund can be refused
Your bank can generally only refuse a refund for an unauthorised payment if:
- it can prove you authorised the transaction – though your bank cannot simply say that use of your password, card or PIN conclusively proves you authorised a payment
- it can prove you are at fault because you acted fraudulently or because you deliberately, or with ‘gross negligence’, failed to protect the details of your card, PIN or password in - a way that allowed the transaction
- you told your bank about an unauthorised payment 13 months or more after the date it left your account, so make sure you contact the bank as soon as possible. """
[edit - remove block formatting]
Suppose you had one legitimate transaction, and one fraudulent transaction. Now, suppose the bank had certain evidence to show that the legitimate transaction is legitimate that is sufficient from a legal perspective to refuse your refund request. Then, suppose the bank had no such evidence to show for the fraudulent transaction.
And now pay attention: THE FACT THAT THEY DON'T HAVE EVIDENCE FOR ONE OF THOSE THAT THEY DO HAVE FOR THE OTHER MEANS THAT THE BANK CAN DISTINGUISH THEM. Got it?
I was talking about cases where the bank is NOT ABLE TO DISTINGUISH an actually fraudulent transaction from a legitimate one. Your response "but if they are able to distinguish them, they have to refund you!11" is just completely irrelevant to the point that I was making.
We are not making the point you think we are.
We're all clear that if the bank can distinguish, they must refund legitimate cases, but that's not what we're trying to explain either. Responding to your last paragraph alone:
"I was talking about cases where the bank is not able to distinguish an actually fraudulent transaction from a legitimate one. Your response "but if they are able to distinguish them, they have to refund you!11" is just completely irrelevant to the point that I was making."
My response is not "if they are able to distinguish them, they have to refund you". It is "if they are _not_ able to distinguish them, they have to refund you".
No, that's contrary to the FCA regulations. In cases where you can't tell if there's been a third party committing fraud, the benefit of the doubt must be given to the consumer. If the bank cannot demonstrate that the consumer is committing fraud, they cannot refuse the consumer their money.
It's obviously complete nonsense to say "_whatever the rules are_, in scenario X the bank will be able to do thing Y"; in this case the rule is "in scenario X, the bank is not permitted to do thing Y".
Which is why I obviously was not talking about that.
> If the bank cannot demonstrate that the consumer is committing fraud, they cannot refuse the consumer their money.
OK. Now, the bank demonstrates that you committed fraud (that you didn't). Now what?
This thread is rapidly losing value to readers now, since you seem to be dishonestly representing what you’ve previously said, at best guess because you don’t like to be wrong. Quoting you:
“the somehow fraudulent order where the bank doesn't see any signs of fraud and you can't demonstrate it either.”
“That is the category or fraudulent transactions that are indistinguishable from legitimate transactions by anyone but you”
“There are cases where the bank will not be able to distinguish an actually fraudulent transaction from a legitimate one.”
Only now have you changed this to apparently mean the bank can falsely prove the customer committed fraud.
There’s nothing wrong with not being up to speed on recent banking regulation changes in the UK. There is something wrong with pretending you were saying something you weren’t, just for the sake of internet points.
If someone calls me pretending to be my bank and tricks me into giving them enough details (passnumbers etc) to move money out of my account, or persuaded me to authorise transactions they’re making (because I think they’re the bank saving the money from being stolen by someone else), then the transactions will look real to the bank. Previously, that was my problem. Now it is the bank’s - I may have divulged my details in good faith, but I didn’t give the criminal any money. The bank, unwittingly, gave the criminal money. The bank is no longer allowed to claim it was my money. Rather, the bank still owes me my deposit - nothing has happened to change that.
This has been a more commonly occurring crime in recent years, and the regulations are specifically there to:
Protect the consumer
Put the onus on the bank, to encourage them to do better protecting their money.
No, you are simply concentrating on the ultimately irrelevant details. I was not talking about any particular jurisdiction and their banking regulation, but about the fundamental problem that no banking regulation could possibly solve. Possibly I expressed that badly when I phrased things in terms of specific criteria that, of course, can lead to different assignment of liability depending on jurisdiction, but then, I would think that it should be clear from the context that that is not what I particularly care about here.
The fundamental problem is that you are trying to determine someone's intent. Ideally, you would want to be able to distinguish exactly when the bank customer intends to effect the execution of whatever order they formally have given you, and when they don't, either because they weren't actually involved in authorizing the order, or because they are somehow mistaken as to what the order they have given actually entails. If we could do that, the bank could refund all fraudulent charges without being at risk of being defrauded itself (or, ideally, prevent the fraudulent transaction in the first place).
It's just that we don't have access to someone's intent. All we have is someone who claims to have had a different intent than what the bank believes (or claims to believe), and who has a motivation to lie about that claim. But there is nothing that would be externally accessible that necessarily distinguishes someone who ordered some transaction fully understanding what that order entails and someone who gave the same order but was mistaken about what it entails. In some (maybe many) cases, you can have strong evidence that supports or contradicts the fraud claim, and those then generally can be resolved correctly. But there is absolutely no guarantee that you have any reliable evidence in either direction. And if you don't, there is no easy and reliable solution. You can not just say "if you can't know for sure, you have to refund", because you never can know for sure, so the bank would always have to refund, thus resulting in a massive fraud risk for the bank. Or you could say that, but it's just not gonna happen. The bank will always be able to avoid refunds without demonstrating beyond a doubt that the cutomer was trying to defraud them, or else they could not defend at all against people trying to defraud them. And as a result of that, there is always, unavoidably, the risk that you, as a customer, will be defrauded by a third party, and, no matter what the regulation, you will not get a refund because the bank can show sufficient evidence to convince a court that it was likely your fault according to whatever the specific rules are.
And all of that is relevant in this context because TFA suggested refunds as a supposed solution to the problem of weak passwords, and that is bullshit. While shifting much of the liability to the bank via regulation certainly helps in many cases, it can not, in principle, ever be a complete replacement for strong passwords. As far as guessing credentials is concerned, only strong, high-entropy, credentials actually solve the problem, solve it trivially (assuming the customer cooperates, of course), and solve it without exception.
Anyone who has ever had it happen to them, i.e. me? Not sure where you live but this is a legal requirement where I'm from.
It is (at least in my country) very easy to guess valid acount numbers: They are incrementally numbered + have a checksum. So while 1 account of a 5 number 3 tries bank is safe, attacking all of them in volume is not:
With N numbers, T tries, A accounts, the chance of guessing at least 1 account is pow(1-T/pow(10,N),A)
5 numbers 3 tries means a chance of 0.9997 of being locked out of 1 account. For A=100 000 accounts, the chance is 0.049, so more than 95% chance you guessed one account right. For A=1 000 000, you're almost certain.
And that's the dumbest possible way. Try guessing with the most common password like 12345, take only 1 try each month so people unknowingly reset the account number when doing payments, and use a botnet to spread the load over tons of IP adresses and randomize the numbers.
I also completely distrust the "advanced security measures" claim. I have no trouble logging into my bank via curl, including from remote IP addresses. (They finally rolled out 2FA, but I can still type the text code into my script.)
A couple years ago I discovered a number of vulnerabilities in their account site, too (including some many years old software with vulnerabilities with a CVSS of 10). After I reported this to them, the response from the guy who worked there was basically "Yeah, that's from the crappy vendor who supplies us with this software. Please don't say anything about this because we're replacing it with a new in-house backend in a couple months."
> Banks typically use customer registration numbers as opposed to user-chosen usernames or email addresses so there goes the value in credential stuffing lists.
I've had accounts at most of the major US banks and I don't think I can think of a single one that did this. Almost every single bank allows the user to select a username or occasionally uses email for login. This is not a good argument for Chase, Citi, Amex, Discover, Capital One, Barclays, and a whole bunch more I can't think of off the top of my head.
Yes, I do think that. I automated some banking functions for myself and the last 4 retail banks worked just fine when accessed with curl, or headless chrome. I didn't even change the user agent for curl and used no delay between requests. Not only do they trust credentials, there are no extra checks in most cases. This is experience from UK and Oz. Lloyds, CommBank, ANZ, ING.
ING is actually the "hardest" one. Their 4-digit scrambled keypad varies colours slightly so it requires closest-match comparison to known samples. That was like 3 extra lines of code.
It is usually a weighted result of multiple signals. For example, it may look at say 20 factors and have a failure threshold of 15 passed. Most of the signals are evaluated server-side.
By design, some signals used are picked such that customer convenience, among other things, is not affected (e.g. the account holder data pull automation that you describe in your example ).
Examples of signals include timezone, time of login vs. past logins, hardware profiling (OS, screen resolution, IP, ISP, VPN vs. no VPN - based on known VPN server lists ) etc.
I agree that not all banks are doing this but the more sophisticated ones are (quite a few of them). Point here is curl or headless browsers working is not evidence of only account and password being checked.
Genuinely looking for clarification - what does "untestable claim" means to you in this context?
If it means that you personally can't test it, then yes, it is an "untestable claim" and you are right, the whole thing is effectively a magic black box.
If it means that some other party/authority can't test it, then no, it is the opposite - a "testable claim" - to use the nomenclature put forward.
As a counterpoint to illustrate this, others who can, and do, test include:
1) internally (within the bank itself)
2) externally (outside the bank) In large bank environments, developers cant simply put out a username/password login architecture and expect to see it deployed to production.There are a ton of other groups defining what they MUST do. The degree of functional separation in (large) banks is astounding - but it mostly works - because everyone has to toe to requirements defined by other functional groups.
I would argue that another CS-related analogy to this is machine learning. Everyone says they do "ML", most people don't understand it, some do understand it and a few understand it deeply; from an execution perspective, most are doing it ML badly, some doing it OK but there are a few are doing it really well because they understand it really well.
As with ML, for the case of user access management, the fact that *most" are doing it badly does not negate its (very real potential) value if done right.
Simply what I wrote above: The fact that no observation counts as evidence against the claim, every possible observed behaviour can be explained by "it's magic". That includes the behaviour of all the components of the system, including the people. You claim that there are all those people and roles that make sure that crap doesn't go to production. I make the observation that those people and roles and whatnot have decided to implement a 5-char limit on passwords. You respond that "it's magic". No matter how obviously terrible the observable effects of the system are, you will find some rationalization why the black-box magic can exhibit this behaviour while also being perfectly secure.
In case you aren't aware, it's a term from epistemology/philosophy of science.
I was not aware about the epistemology / philosophical implications of the "it's magic" comment.
I took the literally reading of your comment.
Can you point me at some stuff I can look at to start learning a little more about this - sounds like the kind of interesting stuff I should be reading late into the night rather than working on the sleep I should be getting.
https://rationalwiki.org/wiki/Falsifiability
could be starting points? I dunno. And, yeah, "it's magic" is just a placeholder for a random ad-hoc rationalization that you can make up in any such situation that would explain the given observation while some apparently contradicting claim is also true. The problem is when there is (almost?) no observation that would make you go "ah, ok, I guess this claim is bullshit after all", because you can always make up some story as to why it might not be.
Basically if there was any check, I would fail it. I did that on purpose - better to know immediately than get silent failures later on. I really don't know what else I'd have to do to trigger "this it not a real person" detection.
A followup question: I have lived in Europe and have accounts in banks in Ireland. For those accounts, actually executing any financial transaction requires entering a one time token generated by a device that uses your debit card and PIN.
Like so:
https://www.youtube.com/watch?v=kEOEQzC8-Fc
Do the banks you tested have a similar setup?
Just trying to find out if these specific banks have chosen to control view transactions with just the username / password but require some other additional authentication for actual financial transactions.
This security story from Canada came out Friday
https://www.theregister.co.uk/2019/09/18/scotiabank_code_git...
am with an FI (financial institution) in the great white north (I am, of course, not speaking for them in any way here) so this is all very very humbling. One theory that I have heard through my network is that event may be the result of agile / sprint work outside regular process ... but it is an unconfirmed rumor... and I do know for a fact that not all platforms are like this...
The assessment of security capability from the guy who found the code + credentials in the wild is brutal! - '"In my experience, this muppet-grade security is perfectly normal for Scotiabank, as they usually leak information once every three weeks on average," Coulls mused.'
Also with PSD2 coming along they'll be doing MFA now, I'd guess.
There’s so many things people could do. Limiting passwords is a bad idea :/
I wonder what makes the US/UK/AUS so special? It's all incredibly alien.
Ever want to annoy the hell out of someone? Try their username or email a bunch of times and lock them out of their accounts. Bonus points if it's one of those super duper ultra secure banks that does password resets via snail mail.
/s [I don't condone doxing anyone. My point is that an attacker should not be able to modify the state of a system he's unauthorized to access]
Indeed, that's a weird rule. When someone stole my credit card number and ran up charges, my bank called me to verify them. How was that not "modifying the state of a system?"
You could just make brute-force searches unproductive, for example by requiring a hardware security key or client certificate rather than a mere password or PIN. Good luck brute-forcing a 128+-bit random secret.
> When someone stole my credit card number and ran up charges, my bank called me to verify them. How was that not "modifying the state of a system?"
The state of the system was modified when an unauthenticated (never mind unauthorized) individual managed to run up charges on your account using only your credit-card number—which is "sensitive" information but not actually secret. That should not have been permitted in the first place. If the rule had been applied properly then this remedial step would not have been necessary.
Yes, that protection is called "password".
> Whether it's limiting the rate of guessing or whatever, the attacker is still "modifying the state of a system."
Which is why you should not limit the rate of guessing (or at least offer that option--limiting the rate of guessing does help users who use terrible passwords, after all).
> Indeed, that's a weird rule. When someone stole my credit card number and ran up charges, my bank called me to verify them. How was that not "modifying the state of a system?"
Which is exactly why that shouldn't be a thing. Being able to pay with a semi-public number is just stupid. You should have to authenticate using a strong password, and "stealing credit card numbers" simply wouldn't be a thing anymore.
Any password can be brute-forced if you neither limit the number of guesses nor limit the rate that you can guess them.
Why doesn't a purchase require a password, at the very minimum?
Then, strangely, various senior folks found their accounts getting locked 1-2 times a day, including the founder. That autolock policy died in a week, and they started looking for 2FA failures instead, as they should have.
I had considered "accidentally" setting up a ssh loop to do this but never quite got around to it. I assume somebody else did. I doubt that an infusion of sanity happened by accident.
Typed in his email address in front of him, hit enter three times, locked him out. Since this was a military base, typed in the commanding officer's email address, started to do the same thing, and suddenly the sysadmin saw the light shine down from heaven.
Until a hacker steals the salted password database and brute forces it as much as they like. A truly strong password is secure even when the attacker has the salted version.
(Anyone who tells you that it's completely impossible for a hacker to ever get their password file is lying either to you or to themselves.)
This is: i) not accurate and ii) bad info
Password hash dumps are worthless if the password hashing scheme used is i)crypto-hashing based and ii) uses salt.
6-8 char passwords are not an issue under this scenario. Current password management best practice is to use both standard crypto-hashing algorithms and salt.
https://en.wikipedia.org/wiki/Salt_(cryptography)
Almost all platforms use standardized crypto-hashing packages that come as standard libraries in the language these days and those require salt. Further, almost all banks will all use these packages.
This is the reason you do not see rainbow tables these days, they are worthless in face of almost any current acceptable crypto-hashing implementation ... assuming one does break rule #1 of crypto and try to roll their own crypto ...
https://security.stackexchange.com/questions/18197/why-shoul... https://www.schneier.com/blog/archives/2015/05/amateurs_prod... .. ad nauseam
Salting also has the additional benefit of making brute-forcing magnitudes of difficulty harder. This is because salting rules can be implement that always add non-standard chars..
https://en.wikipedia.org/wiki/Salt_(cryptography)#Common_mis...
As others have said, the 6-8 chars limits are are a function of legacy system somewhere in the application chain (online banking is never a single platform, it is usually a front-end that talks to a standard backend that tellers, operations etc also access, usually some type of greenscreen app - which is where the password hashes end up).
Brute-forcing bcrypt-hashed passwords on GPUs has a ridiculously low success rate even on most commonly used password data sets.
Failure rate on passwords outside the most commonly used list is more than 95%
https://arstechnica.com/information-technology/2015/08/crack...
The article linked is one guy and one machine who can do 156 bcrypt hashes per second, with salted hashes.
That's ~161 days to hash them ALL.
If you have a dump of thousands of passwords it's extremely probable to get a few of them in under a day. Which is what the article shows - common short passwords were owned.
What's funny about the additional restrictions (you must use 2 upper, 2 lower, etc.) is that they reduce the complexity of this problem so there are fewer possibilities the attacker needs to check for. So you're making it more difficult for users while decreasing actual security against this kind of attack.
Much better policy is something like, "at least 16 characters, whatever ones you want." Easier for users because then passphrases are possible, easier to implement because there's only a string length check on the client, and more secure because it doesn't completely rely on users not choosing trivial passwords.
> What's funny about the additional restrictions (you must use 2 upper, 2 lower, etc.) is that they [...] decreasing actual security against this kind of attack.
Not necessarily - the additional restrictions might prevent even more common short passwords from being used by the users, thus making it harder for both the user and the attacker.
(If the bank says you can't use "Password" as your password, then yes, the attacker only needs to check 62^8 - 1 passwords instead of 62^8, making it insignificantly "easier" for the attacker, but at the same time a lot of people must switch from "Password" to something else, making it much harder for the attacker).
EDIT to add: Having said that, what you propose (at least 16 chars, no other restrictions) makes perfect sense (maybe introduce a maximum of 32k chars).
I get the math and the idea that one password can have all combinations hashed in 161 days for this specific scenario - which is a 6-8 char password that does not allow non-alpha-numerics.
I do think I forgot to add that I was thinking about all of this not just as a theoretical problem but in the context of a single end goal: accessing some random's bank account for some large {randoms} through some front end tool that is protected a 6-8 char password.
Keeping this in mind: running this 161 day process results in a list of 32 billion hashes - useful only for a single account - that you really cannot do anything with since:
If an attacker has back-end access to some DB or app to test the hash, you didn't need the hash in the first place to do nefarious stuff. You are already in.Point being that, yes, I do get it now that a 6-8 char password is much weaker in that it can be cracked in 161 days. But it is a really expensive attack to mount for a single account that may not even hold the cost of hardware and time spent mounting it. This strategy just does not scale to huge volumes of accounts.
From a bank's risk management perspective, the potential losses associated with a successful attack of a single account in this fashion are more than manageable. It is cheaper, long term, to refund a clients up to $YYMM than it is to pay for one-time development work across all platforms to remove the 6-8 char restriction.
Remember that security posture here has multiple layers. For example, for accounts with significant funds, you can definitely get in the front end with this approach but once in, you still have to deal with other protection schemes before being able to tap into any funds (e.g. multiple 2FA / RSA / PIN / keyword challenges, IP and/or time of day and/or destination gating etc ).
I'm even ignoring here that many banks at least recently used to provide strong hints that they are storing passwords in plaintext, such as by using a modified form of the password as a telephone passphrase.
>6-8 char passwords are not an issue under this scenario.
I don't think so. Unless you meant something other than cryptographic hashing when you say "crypto-hashing". SHA-256 is a cryptographic hashing function (much more likely to be used at a bank than something like bcrypt I would wager) and a GPU is going to do on the order of a billion hashes per second. So cracking a 6 character password in minutes.
A salt will make a set of passwords harder to crack en masse, but if they want your specific password, salting isn't going to make that any harder.
Our admin team is informed every time someone logs in the system, and wiring money is a 2 phase process. If a transaction is unusual, the bank usually contacts us.
So yes, I do think banks have additional protection measures, it's just not worth it for smaller amounts where the insurance will just cover it.
> As much as I don't believe that's the case in any modern bank of significance, it's definitely not a good look. Inevitably the root cause in situations like this is "legacy" - there's some great hulking back-end banking solution the modern front-end needs to play nice with and the decisions of yesteryear are bubbling up to the surface. It's a reason, granted, but it's not a very good one for any organisation willing to make an investment to evolve things.
But the only reason that "legacy" system would have a limit is because it's storing your password. So
> I don't believe that's the case in any modern bank of significance
It _is_ the case. It may not be the case in their most recent systems, but a chain is only as strong as it's weakest link. You can be hashing/salting the user's password and locking it behind a vault door to make sure noone can access it. But if you _also_ keep a copy of the password in plain text on a piece of paper taped to the outside door, the vault copy doesn't protect it.
Not sure what they hope to accomplish.
I'm pretty sure they have much more security around detecting and blocking suspicious behaviors after you've logged in, like adding new payees on bill pay systems, requesting transfers of large amounts of money to random accounts, particularly overseas, etc.
I also argue that banks have much, much better security than anything most of us have ever touched, because they handle billions of dollars moving around routinely and manage not to lose it. Meanwhile, half of the internet can't manage not to lose the email addresses of everyone who signed up for their cat picture website. If they're trying that hard to steal something of little value like that, how hard to you think people are trying to steal the billions of dollars that banks handle?
Exactly this is the reason why I don't think Troy is being gullible here.
"Because it's so important, surely they must be competent."
Which does not follow.
Look at the efforts spent hacking Bitcoin exchanges and identified large holders. Lots and lots of money being taken there. Look at the efforts made to hack much less important things. How come no big banks have suffered a serious compromise leading to the loss of 9-figure plus amounts of money yet?
Bitcoin is very different: when the bitcoin blockchain says someone else has your money, they have it. Imagine someone had heard that Ethereum had suffered no major attacks on exchanges, but hadn't heard of the DAO attack. They must think that Ethereum is extremely secure. Actually, Ethereum is very insecure, but a large enough target will get special treatment. Bitcoin doesn't have the same tendency as Ethereum (and real life) towards hard forks, so of course it will have more attacks on it. But this doesn't imply that anyone will hard fork when you get hacked, nor will the banks necessarily reverse the transaction when someone guesses your password.
I was going to write them an email, but they have no clear email to report security concerns so I figured they don't care.
People ask me what it was like working there as far as processes etc. I always say the same thing. "Banks are like the mafia. They have a lot of money, and they don't like giving any of it away." Banks (especially) care about 2 things, money and risk. They spend just enough money to mitigate the risk and then stop. What this means is that they may buy good systems to help with security administration, but rarely did I see them take extra time to make sure they have multiple security redundancies like Troy describes. Employees were "trained" to what the letter of the law required. Don't get me wrong, there were some great people there, but let's not pretend they only hired from a select group of highly trained and extremely smart people. It's just like almost anyplace else. Employee's and contractors are there to get a paycheck and go home. They do what risk wants and when their done, bam they go home til tomorrow, because the fights just not worth it after a while.
I briefly worked with a sales guy from a vendor we used, and he used to work in the banking industry. He had the best quote (that I shamelessly stole) to describe banks. He said, "If people knew what I know about banks, mattress sales would skyrocket."
The problem is user inertia. Let me speak as an averaged one, mixed with my own deeds prior to being knowledgeable in cyber security.
If I'm forced to remember my password because my password manager gets shut out or because of weird requirements, like uppercase letter + two numbers + non-alphanumeric, I'm nudged to use the same variation of my "default password" I used before, 27 times.
"DognameBirthyear&".
"+KeysThatAreCloseOnTheKeyboard1234+".
And of course, I use a slight variation of that for everything. Shady web-server-under-the-desk web forum in 2007 three of my friends were on. Indie game servers, another classic. Bank. Google. It also was my facebook password which I gave to my bff once to check if that cute boy really liked me. It also can be guessed by obtaining my ID and watching me super slowly type the added non-alphanumerical at the end.
This opens the very real possibility of revenge of ex partners, witty people at the coffee shop gaining access and the like. Crimes are committed overwhelmingly by people knowing the victim. No fancy AI is gonna help you with that, reasonable withdraws in the middle of the day in your time zone from your own MacBook's IP address. Good luck with customer support. You are enabling THAT with your dumb requirements.
And why?? You are a bank, hire someone who knows their job and does not just act on blog spam FUD or whereever you got the idea of exactly 5 digits numbers only. No, I choose to be mad about this because there is no excuse for such horrifying UX and security.
Just enforce a minimum limit of like four characters to prevent breach by putting down coffee mug on keyboard, enforce a maximum limit so you don't fall victim to an embarrassing flavor of DOS attack. If you feel fancy, throw a bunch of money at haveibeenpwned to check whether people are putting dumb passwords and let your local RegEx wizard check against all other silliness. There you go. I even waive you the $150k fee for that extraordinary piece of consulting.