Over a million developers have joined DZone.

Who’s Responsible for Weak Passwords?

As Account Takeover (ATO) attacks become more common and more damaging to companies and websites, organizations should consider sharing responsibility for their customers' faulty passwords.

· Performance Zone

Evolve your approach to Application Performance Monitoring by adopting five best practices that are outlined and explored in this e-book, brought to you in partnership with BMC.

When people choose weak passwords and reuse them across websites, they bear some responsibility for security breaches that impact them. Historically, this was where it stopped: if you got hacked, it was your fault. But as Account Takeover (ATO) attacks become more common and more damaging to companies and websites, organizations should consider sharing responsibility for their customers' faulty passwords.

bad_password-618x336.jpg

This argument may sound counterintuitive: shouldn’t individuals bear the blame if their poor choices leave the door open to cyber-attackers? Yes, but since the damage caused by these bad actors ripples across the entire organization, it makes sense to improve web application security broadly, throughout the software development lifecycle -- long before end users set up credentials. This is ultimately the best way to minimize the impact of ATO and credential stuffing attacks.

Stolen Credentials are Big Business

One thing is for sure: the security problem arising from stolen credentials will only get worse. Not a week goes by without numerous disclosures of organizations impacted by such attacks, and the damage they cause can linger for years. As a result of just a single successful ATO attack, the 2013 breach at Adobe, more than 100 million username/password combinations were leaked to the dark web, where criminals of all stripes can easily access them. This is why ATO attacks are now the single-largest attack vector for cyber-criminals, according to researchers at Verizon.

In fact, one could argue that organizations have become too good at shielding their users from the impact of such breaches. If I know that Facebook is really good at protecting my account even though I’ve picked a weak password, I might be less motivated to pick a stronger one. If my bank automatically refunds any fraudulent charges resulting from security breaches, it might make me lazier when it comes to security.

Meanwhile, insecure web applications give attackers a relatively simple mechanism to steal user credentials, and commonly used security tools such as Web Application Firewalls (WAFs) fall short. They were designed to protect the perimeter, but ATO and credential stuffing attacks can easily bypass the perimeter to target web apps directly.

Adding to the problem is the fact that protecting user accounts piecemeal is all but impossible, when every application uses custom security measures. It quickly becomes a management nightmare to keep these security measures up to date, but failing to do so means your web apps are now a security liability.

Where to Start in Safeguarding Your Web Apps

Fortunately, there are proactive steps organizations can take right away to minimize the risks to their web apps. Encouraging secure password practices is a good place to start. Companies should put mechanisms in place to enforce a minimum level of password security, alerting users if their chosen passwords are too weak, and prompting them to choose passwords that are harder for attackers to guess.

It’s important to note that in this process, each organization will have a different level of tolerance for relative password weakness. If your apps deal with sensitive financial information, protected health data, or any other highly valuable information, it’s wise to make two-factor authentication mandatory. But this higher level of security won’t be necessary for all organizations.

In addition, companies should develop a backup plan for instances when password authentication can’t be trusted. If a user has the right credentials but there’s a good chance they’re not the right user because your system has been breached, implementing security solutions that detect fraudulent logins will add an extra level of security. Then, ensuring that you have secondary email addresses and/or phone numbers for your users on hand, you’ll be able to contact them to verify their identity.

One other commonly-overlooked, but important step is to make sure this contact information is up to date. Organizations should implement email verification flows to ensure addresses are valid. With this mechanism in place, users can be re-authenticated if necessary, but again, your organization will have to weigh how much “user annoyance” is tolerable.

Mitigating Breaches After the Fact

Unfortunately, web app security breaches are a fact of life today. But you can take steps to make it easier to manage them. By focusing on comprehensive user education on security, and by doing a web application vulnerability assessment, looking for cross-site scripting, SQL injection, input validation issues, and other vulnerabilities, you can lay the groundwork for more secure web apps. Emerging technologies such as Runtime Application Self-Protection (RASP) provide an easier, faster way to get a handle on your web app security.

Want to learn more? Check out our panel discussion on RASP, WAFs, and the way forward for better web application security. 

Learn tips and best practices for optimizing your capacity management strategy with the Market Guide for Capacity Management, brought to you in partnership with BMC.

Topics:
security ,passwords ,credentials ,account takeover ,immunio

Published at DZone with permission of Mike Milner, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}