Brute-force attacks target two-year hole in Yahoo! Mail Scammers are exploiting a two-year-old security hole in Yahoo's network that gives them unlimited opportunities to guess login credentials for Yahoo Mail accounts, a researcher said. The vulnerability resides in a web application that automates the process of logging in to the widely used webmail service. Because it fails to …
The last sentence of the article appears to have been cut off at the end. Given Yahoo's normal modus operandi, it should probably read:
"Yahoo! takes online security very seriously," a company spokesman said. "We are investigating the situation and will take appropriate action if it turns out to be embarrassing enough to us."
You should use a single SP to auth, and increment login attempts in the SP. There should be no other point of entry to the user/login table in the database, and every app that wants to login MUST go through that SP.
Did they actually write an app that has a hardcoded "select userid from users where username='#####' and password='#######'???
I had a serious issue with Yahoo!Mail sometime ago, around 2006. This was obviously the culprit. I even wrote to them to advise them that the account was being continually compromised using COMPLEX passwords. Sheesh, guess I wasn't going bananas after all!
I've also had some issues with Hotmail too. Again complex passwords in use, wonder if the same vulnerability is there.
Grenade and vaseline for the application security design team...
Either you have an easy login method and millions of users or a secure login method and couple of hundred.
Windows didn't get where it is today by being secure. MS could get rid of 99% of mallware and virii by making sure windows is installed securely - but most of their userbase wouldn't be able to get to the internet and would desert them, and those that didnt would have all the passwords on post-it notes visible on google street wise.
This post has been deleted by its author
"Either you have an easy login method and millions of users or a secure login method and couple of hundred."
Methinks you miss the nature of the attack.
Yahoo's front-end logon, the one that users see, IS secure. The insecurity exists in the API, which allows programs and other Web sites to log into a Yahoo account. Fixing this insecurity would not affect people who go to Yahoo's Web page and log in at all.
These, and many, MANY more vulnerabilities very similar to it have always existed on Yahoo!
When I started programming 12 years ago it was simply as a means to utilise these ‘backdoors’. Yahoo have hundreds, even thousands of alternative login methods and front-ends that all a guy has to do to attempt a brute force attack is play around with their sub domains until you find one that doesn’t either a) produce a captcha after one wrong attempt, b) doesn’t lock the account for an hour after 5 attempts and also, and almost more importantly c) doesn’t ban your IP for an hour after 10 attempts (which the regular login page does).
Their Messenger program also has many different servers with which you can login, and finding one of those that doesn’t stop working after 5 attempts is as trivial as finding a whore in a whorehouse.
12 years and they still haven’t changed the basic foundation of their credential access and still leave it up to each front end developer to add their own security measures.
Yahoo chat is one of the dodgiest places on the Internet, makes most IRC servers look positively saintly. The reason is the whole thing is bug infested and completely insecure, last time I frequented the place there were numerous ways to remotely crash other people's yahoo chat, steal peoples login's using XSS, disconnect people from yahoo chat by faking bad packets from them, etc etc.
This exploit looks relatively tame compared to some of the stuff that was out there (and I'm pretty sure it isn't all fixed).
Franklin wrote:
"Yahoo's front-end logon, the one that users see, IS secure. The insecurity exists in the API, which allows programs and other Web sites to log into a Yahoo account. Fixing this insecurity would not affect people who go to Yahoo's Web page and log in at all."
...and if fixing the hole is going to take long then I suggest that simply removing the API support would be a fair trade-off too, since there's a secure and familiar alternative.
But kinda ironic that the interface for dumb(?) end-users makes them jump through the necessary hoops and the API for smart(?) programmers takes a load of dodgy short-cuts, which is the complete opposite of the catch 22 situation Tom7 is worried about.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
