Banks, Arbitrary Password Restrictions and Why They Don't Matter
troyhunt.com
troyhunt.com
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.
google.com
adsrvr.org
amazon-adsystem.com
appdynamics.com
bing.com
demdex.net
doubleclick.net
facebook.com
googleusercontent.com
gstatic.com
hsbc.com
linkedin.com
liveperson.net
lpsnmedia.net
omtrdc.net
tiqcdn.com
yahoo.com
youtube.com
ytimg.com
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.
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)
+ 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
+ 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
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.
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."
> 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.
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."
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.
Here 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
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...
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.)
They could be doing 2FA when someone logs in with a new device too.
There’s so many things people could do. Limiting passwords is a bad idea :/
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:
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
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.
I'm glad he at least acknowledged that banks should modernize their password policies regardless of their other security measures, but he's quite wrong to claim that we end-users shouldn't be incensed by banks' bass-ackwards security policies just because "well um uh they told me they're doing secret things so I'm gonna totally take their word for it and you should too".
And no, account lockouts do not address the concerns caused by arbitrary password limits. Arbitrary password limits - be they for length or which characters can or cannot be used - are a rather bright red flag for storing passwords in plaintext, which means that when - not if - that bank inevitably has some kind of database leak, congrats, now the attackers don't even have to go through the trouble of brute-forcing or rainbow-tabling or whatever a bunch of hashes to get my plaintext password.
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.
> 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.
> Banks like ING will give you your money back
Now, I don't have any experience with having my bank account hacked, but I have had experience with my credit card getting used without my consent, and it's NOT a fun process. I can't even imagine how that'd go with a bank and a checking account. I can only guess that you have to 1. get the right customer rep on the line and 2. wait a good while.
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.
I have never used a good looking modern web app from a bank. Usually it's a slow bloated crap that looks and works like a project from 10-15 years ago.
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.
Also available were SMS TANs, where they texted you a code. I avoided these after reading about SIM swapping.
But, further, was a photoTAN. The bank mailed me a private key that I entered into a reader app. Then they would present me with a QR-code-like image that the app could read and decrypt into a six-digit code via the secret key. Type that in, good to go. The reader app and the banking app also had some message-passing thing where if you were banking on your phone (and couldn't take a picture of your own screen...) it could still work.
Also, if the first line defense with passwords is poorly designed, why would these security-by-obscurity hidden ones be any different? Sure, you sign in form a new computer (or one that had its cookies deleted) and the site says "You haven't used this computer before, answer this security question: What is you Father's middle name?" That isn't a high barrier. If you know my name and a little about me, plenty of white-pages style sites show relatives etc.
Yes. Yes I do. If you're putting arbitrary limitations on a user's password length, down to 6 characters even. I see no reason why you wouldn't be equally as insane with the rest of your system.
And, frankly speaking. The whole "you're locked out after 3 attempts" non-sense is complete crap. What is this now? We're supposed to believe databases don't get hacked into, and hashed passwords aren't leaked on the net for countless people to hack at and break?
This sentiment leads me to believe the passwords are stored in plaintext.
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.
If these advantages don’t outweigh the disadvantages of a bank, one could read this as a red flag regarding the systems behind that interface.
This is good, because it means people can't brute force the 5 digit password they forced you to use, but also bad, because if someone doesn't like you, they can easily block access to your bank.
If the account numbers are sequential, or otherwise patterned, they may be able to block access to all users without using all that much bandwidth.
Not sure what they hope to accomplish.
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 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?!
That's the point of obligating it by law. It's consumer protection to give them the benefit of the doubt. 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. In any case, here's a citation for you: http://www.nbcnews.com/id/8915217/ns/technology_and_science-...
... 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 liability would be all you need.
Then, there are cases where the bank received an order to execute some payment that was authenticated with your credentials. Now, as subcategories of that you have the actual legitimate payment that you ordered, the somehow fraudulent order where you were defrauded and the bank can tell, somehow, and the somehow fraudulent order where the bank doesn't see any signs of fraud and you can't demonstrate it either. Banking regulation and/or voluntary guarantees usually (mostly) cover that second subcategory. But there is no way to possibly cover the third subcategory: That is the category or fraudulent transactions that are indistinguishable from legitimate transactions by anyone but you, and you obviously have a conflict of interest, so your word that some transaction was fraudulent obviously is worthless in determining whether it was. Anyone who wanted to defraud a bank could submit a legitimate transaction and then claim that is was fraud, so that alone can not possibly be sufficient to get your money back.
""" 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.
I wonder what makes the US/UK/AUS so special? It's all incredibly alien.
No one ever got directly hacked because their password was too strong, but lots of people have had passwords guessed by brute force.
So put the two together. Its beneficial to have strong passwords because they can be presented as evidence of due diligence and there is no security risk to enforcing them. There may be some business risk(people fleeing because they don't like your password policy) but someone needs to quantify that its a problem for it to be considered in the calculus.
Your content free, one sentence response not withstanding. Is there something specific you'd like clarification about?
>How exactly does taking steps that have previously been used in civil suits to demonstrate due diligence such enforcing password requirements going to demonstrate due diligence?
Well I'm glad you asked billy! The answer is tautology. Thanks for playing.
This argument is stupid. You want to talk about yak shaving, theoretical nonsense. FWIW I agree with you and think that password requirements are dumb, but you live in the real world. These are the legal realities of IT policy.
I am an Information Security professional, customer of financial institutions, and started my earliest engineering career for a large bank.