A Thing
The Green SheetGreen Sheet

The Green Sheet Online Edition

March 23, 2020 • Issue 20:03:02

Passwords are so passé

By Dale S. Laszig

Most mobile app users know passwords alone are insufficient protection against automated attacks, but old habits die hard. The recent attack on J. Crew is one more wake-up call in a litany of worst case scenarios that highlight the need for multilayered security, according to Jason Kent, hacker in residence at Cequence Security. Kent told The Green Sheet that he sees automated attacks on mobile applications every day.

These attacks typically throw massive swaths of usernames against an application to see if the application prompts for a password. When the app recognizes a username, hackers begin the second attack phase by trying different password combinations. "Eventually the attacker learns the usernames and passwords of several accounts and in the next phase they attack," Kent said. "Both the testing and the attack are noisy but often we find organizations aren't instrumented to see the testing and attack phases."

As mobile app adoption grows, we need stronger authentication methods. A recent Harris Poll conducted by Ondot Systems showed 64 percent of U.S. consumers believe technology companies can significantly improve financial products and services. Survey respondents between the ages of 18 and 44 would consider purchasing a financial product from a tech company for the following reasons: tech companies make products that are more convenient to use (35 percent), have built-in tools to control budget/spending (30 percent) and provide better technology/digital features (28 percent).

"Technology companies have spent years and billions of dollars designing customer-centric platforms that deliver an easy user experience, Apple Card's instant issuance feature being a recent example," said Vaduvur Bharghavan, CEO of Ondot Systems. "As a result, consumers have incredibly high expectations of the companies with which they do business, including financial institutions."

High expectations, high crimes

Kent pointed out that their agile and user-friendly design makes mobile app APIs particularly vulnerable to massive, orchestrated attacks, and such automated attacks can be difficult to detect because APIs are designed to be fast and to accommodate thousands of transactions per second. Consumers and merchants who are conscious of where these attacks will likely occur can protect vulnerable endpoints and minimize exposure, he noted, adding that people don't have any idea of how easily a hacker can crack usernames and passwords.

"The challenge is that this type of vulnerability is often considered low risk because it is up to the user to have a good password, change it regularly, include special characters, etc.," Kent said. "In this case it's easy to see that even though the user has some responsibility, the system shouldn't be built in such a way that an attacker can test credentials and later construct and automated attack that isn't noticed."

To further illustrate mobile app vulnerability, Kent recalled that API layers were originally created for internal traffic, before mobile traffic became widespread. During this simple jump from internal to external use, developers weren't looking at the vulnerabilities of high-speed transaction models. Failure to follow security basics in an architecture that supported a huge transaction load gave automated attackers a great environment for efficient testing, he said.

How can we be safe?

Kent noted that mobile app developers and deployers can take steps to build more secure apps and detect anomalous, automated attacks. He provided the following guidelines:

  • Know your network: The first step is having a thorough knowledge and updated inventory of all network endpoints and APIs to figure out what is needed, Kent stated. This includes APIs that have recently been changed or up-versioned and old APIs that are left on. Just adding security to new API endpoints doesn't go far enough because attackers look at all the old applications to see which APIs are still on or have changed.
  • Understand API resilience: Next, understand what abuse the API can take. Can I login 500 times in a row? Can I take my session tokens and use them to get another user's information? What does registration and password resetting look like? Attackers can and will exploit these simple mechanisms to attack, Kent said. Familiarity with abuse cases can mitigate attacks.
  • Watch out for bots: Organizations that detect anomalous behavior and bot activities can mitigate numerous attacks because they will understand if a request is coming from a known bad actor or location, or trying to use an old session, such as Consumer A using a token assigned to Consumer B. Having this type of intelligence can make the difference between exposing an API for attackers to play with at will and having a protected application that takes attackers on a journey they weren't expecting, Kent noted. Attackers who are blocked or deceived will eventually realize they are being played and will move on to the next victim.

Wouldn't it be nice to flip the script and give bad actors a very bad day? Layered technologies work tirelessly in the background against automated attack vectors. Numerous attacks look and act legitimate, which is why they are so dangerous. With troves of personal data for sale on the Dark Web, reinforcing passwords with biometrics and one-time SMS codes can help protect us from automated attacks and fraudsters. end of article

Dale S. Laszig, senior staff writer at The Green Sheet and managing director at DSL Direct LLC, is a payments industry journalist and content development specialist. She can be reached at dale@dsldirectllc.com and on Twitter at @DSLdirect.

The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.

Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

Prev Next
A Thing