Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Databases EU

Are APIs Putting Financial Data At Risk? (csoonline.com) 66

Posted by EditorDavid from the SOAP-opera dept.
We live in a world where billions of login credentials have been stolen, enabling the brute-force cyberattacks known as "credential stuffing", reports CSO Online. And it's being made easier by APIs: New data from security and content delivery company Akamai shows that one in every five attempts to gain unauthorized access to user accounts is now done through application programming interfaces (APIs) instead of user-facing login pages. According to a report released today, between December 2017 and November 2019, Akamai observed 85.4 billion credential abuse attacks against companies worldwide that use its services. Of those attacks, around 16.5 billion, or nearly 20%, targeted hostnames that were clearly identified as API endpoints.

However, in the financial industry, the percentage of attacks that targeted APIs rose sharply between May and September 2019, at times reaching 75%.

"API usage and widespread adoption have enabled criminals to automate their attacks," the company said in its report. "This is why the volume of credential stuffing incidents has continued to grow year over year, and why such attacks remain a steady and constant risk across all market segments."
APIs also make it easier to extract information automatically, the article notes, while security experts "have long expressed concerns that implementation errors in banking APIs and the lack of a common development standard could increase the risk of data breaches."

Yet the EU's "Payment Services Directive" included a push for third-party interoperability among financial institutions, so "most banks started implementing such APIs... Even if no similar regulatory requirements exist in non-EU countries, market forces are pushing financial institutions in the same direction since they need to innovate and keep up with the competition."
This discussion has been archived. No new comments can be posted.

Are APIs Putting Financial Data At Risk? More

Are APIs Putting Financial Data At Risk?

Comments Filter:
  • In theory, an API could be more secure, because the well defined (potentially) inputs and outputs make it relatively easy to build up a well-thought-out system of security over a well-defined interface.

    In practice, few companies do that, they just start writing APIs as new features are needed. It works in the happy case, and security is someone else's problem.

  • No, Bad Security/Programming Is (Score:5, Insightful)

    by Nova Express ( 100383 ) <lawrenceperson@@@gmail...com> on Saturday February 22, 2020 @07:41PM (#59755342) Homepage Journal

    Use best practices, require certs/two factor authentication for all calls, don't allow expired certs, don't allow universal passwords, etc.

    If you use bad security practices because you're too busy to implement good ones, or you'll fix it in release, or because your customer complains that it's too hard to use good practices, or because you have too high privileges than the API call actually needs, etc., then sooner or later that will come back to bite you on the ass.

    Nine times out of ten, it's not the fault of the APIs, it's the way you've implemented them.

    • Mod parent up.

      Permitting access without authentication, ACLs and long session persistence is clearly insane, but coders aren't responsible for the outcome in terms of actual liability. No one will pressure API guards because, also insanely, we limit the liability in breaches to a pittance of actual damages.

      If liability could be bestowed on organizations (who was it this week, MGM, the USPOTUS, and others) that would ransack their assets and put them in jail, then people would respect protecting access to th

      • Note: under CCPA the fines for losing personal data can be several thousand dollars for each record. So in theory the fines can now be enough in California to kill most companies (of course, this hasn't been tested in court so I have no idea how it will play out).

        • Um, sure. And when's the last time you heard of a successful litigation under CCPA? Yes, I know this is brand new legislation.

          It's not even a matter of pride. No one falls on their sword, gets publicly sacked and castigated, or probably even loses their job. It's in the lawyer's hand, here, have a nice credit report service (from people whose site's been jacked).

          At one time, long ago, Target Stores were breached, and it hurt their sales for a long time, along with Marshalls/TJMaxx/etc. Now we all shrug, bec

          • Your first paragraph is nonsense and utter ignorance. At least read the Wikipedia entry about CCPA.

            • It's laudable legislation, but my first paragraph's intent remains. Seen litigation? Seen massive fines? It's not nonsense. Where is the nexus of litigation under the CCPA? Is it at the AWS server where the data leaked? Was it a citizen of CA who is an injured party? Is the nexus a programmer in San Jose? Who owned the data at the time, or was managing it?

              No, California State can sue. Show me the litigation. Show me organizations slammed with fines for each and every record lost.

              Read my first paragraph. Rea

  • From my experience in companies offering APIs for financial applications I can say that the most immediate and obvious risk is the irresponsible use of unverified code downloaded from arbitrary repositories on the Internet.

    When I hinted my supervisors to the risk, pointing out actual cases that already happened where malware was injected into web services via public NPM repositories (with other repositories like PIP, Gems, CPAN being no less risky), I was just told that it is industry standard to use those
    • Current security practice is for the security team to do a review of any new library or external software installed. The security review will include things like "how likely the repository is to be replaced with malware." So make sure your boss knows that approach is now best practice.

      • Totally unrelated to the topic, but a comment/question about your signature:

        "If you find yourself hating a group of people, you are the problem."

        I overwhelmingly agree with this, but....I hate Nazis. Am I the problem?

        I don't hate anyone based on their skin color, race, ethnicity, religious beliefs, country of origin, sexual orientation, etc etc etc...but I've gotta say, I hate Nazis.

        Honestly, I'm not trying to be snarky, but how does that make me the problem? It seems to me that sometimes there are good rea

        • Yeah, that's a small problem. Hating them won't help them become better people, and in any case your hate is mostly in you, not them: clouding your vision, not theirs.

          • Yeah, that's a small problem. Hating them won't help them become better people, and in any case your hate is mostly in you, not them: clouding your vision, not theirs.

            Yes, some of the hate is certainly within me, but they also seem pretty hateful by any reasonable standard.

            I'm not sure there's anything I can do to help them become better people. And I hate them the same way I hate cancer cells: I regard them as an invasive species intent on destroying the host.

            Am I supposed to love or tolerate them? I'm not trolling you, I'm curious to know your thoughts on how to live on the same planet as them. Nazis (and their ilk) seem to be all or nothing- accept them and join them

            • Is this a real problem, like, do you ever have interactions with Nazis?

              • Is this a real problem, like, do you ever have interactions with Nazis?

                A few times in person, they were just as repulsive as I thought they'd be. I'm more concerned with the damage they're doing by poisoning society in general than through personal interactions. The same way I'm more concerned about pollution or disease, even though I may not be dealing with it on a strictly personal level.

                You didn't answer any of my questions, and I would sincerely appreciate hearing your thoughts on what I said.

                1) Am I supposed to love or tolerate them?

                2) How can I coexist with them when the

                • Again, to be clear, the neo-nazis or whatever here are a bigger problem, they put a lot of effort into hating a group of people.

                  1) Am I supposed to love or tolerate them?

                  You have to tolerate them, unless you're planning on hitting them with a Hanukkah hammer. If you can love them, that's hard, but try to not hate them. That's just contributing more hate to the world.

                  2) How can I coexist with them when they openly admit that they would like nothing better than to kill me and my entire family?

                  You've been coexisting with them for decades now. I don't understand the question.

                  • You have to tolerate them

                    I wouldn't tolerate a cancerous tumor that is going to kill me, why would I tolerate a group of people who eagerly want to do the same thing?

                    Tolerance is great until it's used to crush or kill you. And that is their openly stated goal.

                    If tolerance doesn't run both ways, then it ends up as a fatal weakness of those who are tolerant. If they won't 'tolerate' me, why should I tolerate them?

                    You've been coexisting with them for decades now. I don't understand the question.

                    Not by their choice and not by mine. They'd eradicate me if they could. FFS, we fought a World War against them because of

                    • You don't have to hate them to kill them.

                      The hate hurts yourself more than anyone, because it's in you. And your aim won't be good if you are blinded by anger.

                    • I appreciate you answering me and sharing your thoughts.

                      I think we'll have to agree to disagree on this one, though.

                      I sincerely hope that you or your loved ones never become the focus of the kind of hate these sorts of people produce, and again, I thank you for sharing your thoughts.

                    • I think we'll have to agree to disagree on this one, though.

                      Oh yeah? Do you have any reasoning to support you disagreement, or is it just a "gut reaction?"

                    • I think we'll have to agree to disagree on this one, though.

                      Oh yeah? Do you have any reasoning to support you disagreement, or is it just a "gut reaction?"

                      You're free to disagree if you like. :)

    • Sounds like their development and operations practices are fucked if at the very least you aren't setting up an internal repository where your deploys come from, from a reliability perspective alone. It just so happens that you can version control all your dependencies this way as well, because you are no longer dependent on the npm / python / rubygems guys to have their shit working, or not to publish broken new package versions (which happens all the time).

  • Thinking that people should have to access their information through a proprietary site interface is stupid. You might as well declare all standardization to be bad for security and that every financial site have it's own browser plugin.

    If your credentials have been compromised then doing anything besides changing them is just hand-waving.

    • Re: (Score:2)

      by DogDude ( 805747 )
      You might as well declare all standardization to be bad for security and that every financial site have it's own browser plugin.

      If it's something as important as financial information, why not?

      • Because I (for example), routinely interact with a dozen financial institutions and would prefer not to give control of my computer over to all of them when it's safer for them to use standard vetted code on the server-side instead.

      • Re: (Score:2)

        by cas2000 ( 148703 )

        For the same reason that it's idiotic to install a bank's (or any company's) app on your phone - it's just an excuse for that bank/company to install spyware in your phone or browser.

        You may be their customer, but they want you to be their product too.

        apart from all the other problems with such spyware (your bank doesn't need to know where you are or where you travel to/from, or who you communicate with, or what web sites you visit etc), that creates a conflict of interest WRT security - they have an incent

        • For a long time, Bank of America enforced your final point for me - their login would always say I had an incorrect password if I used Chrome, but it worked fine in Safari or Firefox. So, if I needed to deal with my mortgage, I would have to use a separate browser.

          I think at some point they fixed it.

          • Re: (Score:2)

            by cas2000 ( 148703 )

            yeah, i switched banks once in the 90s because their website stopped working on firefox on linux - it had been working fine for a few years. closed my accounts and transferred to another bank. well, that was part of the reason - the final straw. that bank sucked anyway.

            ---

            BTW, I worded my original post badly. Changing browsers isn't necessary if the user switches to a different login account, or reboots to linux for banking (because running random software as Administrator is "normal" in windows - "it doe

      • Because security through obscurity isn't security at all.

    • Comment removed based on user account deletion

  • The user-facing login page has always been an API. Just because there is a different API now available means nothing.

    A "user-facing" login page is just a client (or even proxy) to the existing login API. It makes no difference if that API parses data from a HTML form request, XML or JSON. It is all the same. The underlying authentication method is all that matters. In most cases the APIs meant for server-side consumption are much more secure. Especially when it comes to a brute for attack.

    I don't see the pr

    • The user-facing login page has always been an API. Just because there is a different API now available means nothing.

      A "user-facing" login page is just a client (or even proxy) to the existing login API. It makes no difference if that API parses data from a HTML form request, XML or JSON. It is all the same.

      This was my thought too- everything is an API when you get right down to it. The internet itself is little more than an API, regardless of all the graphical crap and eye candy.

      Hell, now that I think about it, my wife is kinda like an API. The inputs and outputs are often mysterious and inconsistent and seem to vary from day to day, but still...

  • As far as web applications are concerned, I think the larger problem is the move towards client-side programming.

    Client-side web apps expose huge amounts of application logic and schema that would otherwise be kept secret in a server-side application. Certainly, the requests for data can be restricted and secured, but a client-side app provides a detailed roadmap to bad actors about all the potential resources available to them. A server-side application would only output a view.

    I find it ironic that many s

    • Re: (Score:2)

      by Bert64 ( 520050 )

      Client side if done right offloads much of the complexity to the client, and keeps the minimum server side...
      It's the server which must implement all the security controls, and the client implements everything related to presentation. If you separate it out properly, then you keep the server side as simple as possible which makes it easier to verify that each call does exactly what its supposed to do and cannot be circumvented or otherwise abused.

      Knowing how a system works doesn't make it insecure, it does

  • And just how do these absolute fucking morons think the logon data gets from the silly point and clock user presented screen into the god damn fucking program that is actually using it? Do they think Samantha is wriggling her nose?

    What a fucking bunch of asshole time wasters. The whole fucking lot that had anything to do with this article should be taken out behind the barn and beaten to death with baseball bats!

    Hopefully no money was wasted on this assinine drivel!

  • Granted, it's much faster to grab a copy of /etc/password and run your tools on it than it is to try www://foo.com/login.

    Still betting at least 50% of the passwords will be brute force cracked before mine is.
  • CS101. API stands for Application Programming Interface (API). It is a userland program in Clark Kent mode. It cant do raw I/O, it can't do raw memory reads, and a competent operating system and database permissions, and any security credentials/tokens/handles are stored in protected memory where only OS calls can get them. The core problem is idiots writing highly privileged services and programs that get given Superman privileges to bypass normal operating system controls, or in old speak, supervisory c
  • Part of the problem is that bots can be used to brute force attack against security measures until they break through because they get an error code to every failed attempt. Hackers don't have to waste time trying to verify if what they got back is valid or not. If all servers gave 'false positives' to bad credentials, then the hackers would have to waste a ton more resources to try and get good data. When someone tries to log in with bad credentials, make it look like it was successful and send them fake,

    • Just like with robocalls, if everyone answered them and wasted a real person's time then they would stop doing it because it would be too expensive for them.

      I do this, and I fuck with them and waste their time relentlessly. It's a lot of fun to waste their time and hear the excitement building in their voices until I stop and ask, "So, does anyone really buy this bullshit?" Then I laugh while they rage impotently.

      My favorite targets are the IRS/SSA scammers- you can lead those dipshits on for the better part of an hour or more. And they get sooooooooooooo pissed when they realize that I've been scamming them.

      The way I look at it is that every minute I spend scr

  • No (Score:2)

    by gweihir ( 88907 )

    What puts data at risk are shoddy security practices and no accountability for those that employ them. If, say, the CEO would go to prison for a large data-breach, unless there is solid proof of having followed sound security practices and external reviews, the problem would vanish. A blanket compensation of $1000 for everybody that has their data stolen, payable unconditionally and without the victim having to ask for it, would also do the trick.

    As it is, no/bad security is just massively cheaper for the o

  • These financial guys have clearly come up with a new and important security model. They just need a catchy name... Something like "security through obscurity".
    Those dealing with security over the last decades have obviously never come up with this new security methodology. This is a wonderful example of how someone outside a field can jump in and make a significant contribution. I think that these financial experts should patent the idea and charge for anyone who uses it.

Slashdot Top Deals

God doesn't play dice. -- Albert Einstein

Close