Smartphone apps from Walmart, CNN, ESPN, and dozens of other organizations put user accounts at risk of compromise because they allow attackers to make an unlimited number of login attempts, according to recently published research.

Security experts have long recognized the benefit of limiting the number of unsuccessful login attempts that users can make to online accounts. While such limits make it possible for attackers to lock out legitimate users, such denial-of-service drawbacks are generally outweighed by the protection they provide against online password cracking attempts, in which attackers make huge numbers of password guesses against specific user accounts in the hopes of trying the right one. Until last September, Apple's iCloud service failed to limit the number of login attempts to that service, a shortcoming that may have contributed to last year's mass celebrity hack and nude photo thefts.

Despite Apple mending its ways, many smartphone apps still allow users to make an unlimited number of login attempts. That failure allows attackers to cycle through long lists of the most commonly used passwords. Given the difficulty of entering strong passwords on smartphone keyboards, it's a likely bet that it wouldn't be hard to compromise a statistically significant number of accounts over a period of weeks.

According to research from smartphone security firm AppBugs, dozens of Android and iPhone apps downloaded more than 300 million times contain no limits on the number of logins that can be attempted, or provide rate limits that don't effectively block online cracking attacks. Per the company's disclosure policy, researchers give app developers up to 90 days to fix vulnerabilities before making them public. That means most of the 50 or so apps identified by AppBugs still aren't being made public. Still, the grace period has expired on at least 12 apps, including those from CNN, ESPN, Slack, Expedia, Zillow, SoundCloud, Walmart, Songza, iHeartRadio, Domino’s Pizza, AutoCAD, and Kobo. Three other apps, from Wunderlist, Dictionary, and Pocket, were found to be vulnerable but were later fixed after AppBugs brought the weaknesses to the developers' attention.

As noted earlier, rate limiting has a dark side because it makes it possible for attackers to lock legitimate users out of their own accounts. Besides putting rate limiting in place, app developers may want to consider two-factor authentication as a means of preventing the compromise of user accounts.

Update on July 23 at 11:45 a.m. California time: Officials at Slack, one of the companies whose smartphone app was called out in the AppBugs report has e-mailed Ars to say the app does in fact perform rate limiting. The company issued the following statement:

As is common in the industry, we don't disclose the specific details of our rate limiting implementation, as that would aid attackers in bypassing it and we change it on occasion to respond to new types of attacks. However, according to our calculations the current implementation would take over 40,000 years to crack a random password even with the lowest complexity we allow (6 characters). If you only ran a couple of 50-password batches you might not have run into our limits. We believe there's a usability balance to be struck with locking people out too easily, and that this is the right balance for our customers.

Slack officials also say they ban hundreds of the most commonly used passwords in an attempt to protect users who don't use random passwords.

Rui Wang, the AppBugs CEO has responded to the Slack statement with more detailed findings that he said show the Slack mitigations aren't as effective as they should be. In an e-mail, he wrote:

Some developers have deployed WAF (Web Application Firewall) or equivalent rate limiting techniques on their web services which can somehow mitigate the brute force attacks. For example, Slack and Domino’s Pizza will reset connections from an IP when x number of connections (In AppBugs tests, the value of x was above 40) are made to their web services within a minute. Expedia blocks connection requests from IP addresses in a blacklist, including those from Tor network. However, any of those defenses cannot block the attackers. Resetting the connections will just slow down the attacks. The attacker can simply make less connections in every minute to circumvent the defense. Blocking some IP addresses will just force the attackers to use some other IP addresses. For real attackers with a botnet, this is totally not an issue. For Slack, I just did some more test to check how much is the rate limit. My test result is that the rate limit that Slack applied is a number between 50 and 60. The attacker can send login attempts to Slack server with lower than 50 per minute rate to try the passwords. Slack will reset the connections if the limit is reached. The account will not be blocked.

Post updated to add statements from Slack and AppBugs and to add "or provide rate limits that don't effectively block online cracking attacks" in the fourth paragraph.