4 ms·

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

by throwaway201606 7y ago

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.

zAy0LfpBZLC8mAC 7y ago
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.
- throwaway201606 7y ago
  [edited to deal with formatting] 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.
  - zAy0LfpBZLC8mAC 7y ago
    > 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.
    - throwaway201606 7y ago
      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.
      - zAy0LfpBZLC8mAC 7y ago
        https://en.wikipedia.org/wiki/Falsifiability https://en.wikipedia.org/wiki/Falsifiability https://rationalwiki.org/wiki/Falsifiability 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.
        7y ago
rehevkor5 7y ago
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.
viraptor 7y ago
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.
- throwaway201606 7y ago
  So, am coming back, more than a little humbled... This security story from Canada came out Friday https://www.theregister.co.uk/2019/09/18/scotiabank_code_github_leak/ 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.'
- nickpsecurity 7y ago
  Nice setup. Did you make it do something security-critical like change your address or even transfer money?
  - viraptor 7y ago
    Mostly export statements and very rarely do transactions.
- throwaway201606 7y ago
  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. Like so: https://www.youtube.com/watch?v=kEOEQzC8-Fc 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.

zAy0LfpBZLC8mAC 7y ago

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.

throwaway201606 7y ago
[edited to deal with formatting] 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.
- zAy0LfpBZLC8mAC 7y ago
  > 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.
  - throwaway201606 7y ago
    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.
    - zAy0LfpBZLC8mAC 7y ago
      https://en.wikipedia.org/wiki/Falsifiability https://en.wikipedia.org/wiki/Falsifiability https://rationalwiki.org/wiki/Falsifiability 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.
      - 7y ago

rehevkor5 7y ago

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.

viraptor 7y ago

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.

throwaway201606 7y ago
So, am coming back, more than a little humbled... This security story from Canada came out Friday https://www.theregister.co.uk/2019/09/18/scotiabank_code_github_leak/ 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.'
nickpsecurity 7y ago
Nice setup. Did you make it do something security-critical like change your address or even transfer money?
- viraptor 7y ago
  Mostly export statements and very rarely do transactions.
throwaway201606 7y ago
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. Like so: https://www.youtube.com/watch?v=kEOEQzC8-Fc 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.