Nearly Half a Million Yahoo Passwords Leaked [Updated]

An anonymous reader writes "Some 450,000 email addresses and associated unencrypted passwords have been dumped online by the hacking collective 'D33Ds Company' following the compromise of a Yahoo subdomain. The attackers said that they managed to access the subdomain by leveraging a union-based SQL injection attack, which made the site return more information that it should have. According to Ars Technica, the dump also includes over 2,700 database table or column names and 298 MySQL variables retrieved during the attack." Update: 07/12 20:03 GMT by T :Reader techfun89 adds this update: "Yahoo has confirmed that the usernames and passwords of more than 400,000 accounts were stolen from their servers earlier this week and that data was briefly posted online. The information has since been removed but it wasn't just credentials for Yahoo, but also Gmail, AOL, Comcast, Hotmail, MSN, SBC Global, BellSouth, Verizon and Live.com as well."

Comments

lastpass

[Dave Whiteside]

you know it makes sense ...
every day there is another hack .... just waiting for the lastpass one now....

Re:lastpass

[Anonymous Coward]

I sure wish these dumbasses would learn to secure their shit. SQL injection AGAIN? There's just no damned excuse for it.

This isn't hard to test for. Hell this isn't hard to guard against. This is a "oh I'll just shoot myself in the foot now, ah-hyuk! *BANG* Ow that hurts what happened?" type of negligence.

If the incompetent designers don't get their shit together you're going to see gov't get involved. All it would take is for a hack to finally affect the "right" people. Nobody wants that except gov't.

Re:lastpass

[bedroll]

This wouldn't terribly shock me, but it also wouldn't concern me much if it were to happen. While the data in a Lastpass vault is quite desirable, it's also much more securely stored than your average data set. Even if someone managed to get a dump of their entire data set they'd have to decrypt each vault individually. If you follow their recommendations then your vault is likely not easy to crack.

Most of all, I wouldn't be concerned because as Lastpass has shown in the past they take communications seriously. When they noticed strange traffic they immediately told their users to change their vault passwords. This is different than waiting for a whistle blower to come forward and then announcing the breach, or even waiting until an investigation proves there was no breach. That previous incident may have shook the faith of some, but the way the company handled it increased my faith in them.

Should a major breach happen I would simply change my vault password and then begin changing the passwords I have stored in the vault. Since Lastpass would alert me early on that the breach happened, by the time my vault was cracked - if at all - the passwords within would be useless.

Re:lastpass

[hades.himself]

And yet they keep pushing OAUTH onto us.

Re:lastpass

[Anonymous Coward]

Better to use keepass then, because there is no central database of passwords for that.

Re:lastpass

[Runaway1956]

You're probably right. What's scary is - the government isn't a whole lot better at this stuff. I seem to recall a recent transatlantic telephone conference, involving multiple "intelligence" and/or "enforcement" agencies that was recorded by the very people being discussed.

Yeah, I really want some alphabet soup dude from Washington looking out for my internet security.

Re:lastpass

[mr1911]

If the incompetent designers don't get their shit together you're going to see gov't get involved.

That will certainly fix it. I can't wait for a bunch of lawmakers that think SQL is some sort of 'dirty text talk the kids use' to secure us online. No one can be sure what they will come up with, but the odds are pretty strong it would include a full body scan (with the ability to opt-out and get groped by the TSA instead) to get on the internet.

Re:lastpass

[Anonymous Coward]

Please, don't be so harsh on SQL Injection victims. It happens all the time, and even to the best developers. Even at Yahoo! Look, between you and me, we at Sony suffered a lot from attacks - allegedly SQLi attacks... but actually, it was something else: you say "guard" against it? We have here the best Javascript developers. Our JS code checks the user input several times, even before it reaches our servers! No, you really don't know what you are talking about.

Re:lastpass

[Anonymous Coward]

You didn't just lump in Goofy with these incompetent shitwizards, did you?

Re:lastpass

[ZombieBraintrust]

There could be a combined Dropbox Keepass attack. Would have same effect of a lastpass hack.

Re:lastpass

[Anonymous Coward]

IT is corrupted..... Just sad

Re:lastpass

[lhunath]

And that's exactly why you shouldn't store your passwords anywhere.

This tool/algorithm will generate passwords on demand so you don't need to upload them to the cloud or save them on your failure-prone hardware.

Re:lastpass

[mlts]

What might be ideal would be a way for an front end to Lastpass to be able to communicate a keyfile to other devices. So, one can have a local keyfile stashed on their workstation, a keyfile on their mobile device, and one on their tablet.

This in combination with a password would make unauthorized access to a Lastpass database pointless. Unless the attacker is able to get at people's devices, they won't be able to get the keyfile, and without that, brute forcing the password is pointless.

I do this with TC and Dropbox, so even if someone gets access to containers stored there, there is no way to get access by just guessing passwords.

Re:lastpass

[Anonymous Coward]

The algorithm behind it is basically a scrypt and hmac hash turning your master password and site name into a site-unique password.

Looks like it's GPLv3 and it's got a Java & CLI implementation.

Re:lastpass

[bedroll]

The problem with local storage is that you're responsible for securing your local device. That makes you much more susceptible to a direct, targeted attack. It also makes you beholden to the security of the various systems you use.

Correct usage of Keepass will likely give you a more secure password database than Lastpass's vault. The non-standardization and decentralization of that method will make you less susceptible to mass database leaks. Even if you use Dropbox (which has some serious security concerns itself) and that service were compromised the attacker would have a hard time getting all of Keepass vaults out. So, that argument holds.

Where it fails is if you are targeted, and even worse if you are not an advanced user. In a hand-spun system like this you are the one who has to monitor for intrusions, and you are the one who has to design the security and maintain it. If you store your password database in Dropbox I believe the exploit of stealing a machine authentication token will still allow an attacker to gain access to your files, which may allow them to begin cracking your password without your knowledge. Once they've gotten a copy of your encrypted file it does not matter if you change your password because it won't change their copy. This becomes a real problem if you're not an advanced user whose setup strong encryption on your database or if you've used a weak password, let alone the issues with a standard user using and maintaining such a system.

Targeted attacks are scary. One can assume that if a victim is targeted it is because the attacker knows there is value in the additional work. If we assume that the effort to decrypt a Lastpass vault is not significantly less than any other strongly encrypted container then we can infer that a compromise of Lastpass (or 1Password, or other such services) would be comparably expensive because each vault has an unknown value. Long story short, I'm far more concerned with a targeted attack than I am a database leak in this case. I'd rather have a service focused on security monitoring for intrusions, even if that doesn't excuse me from maintaining a reasonable level of security on my own devices.

Re:lastpass

[MightyMartian]

There's certainly no excuse for a company like Yahoo, that's for sure.

Re:lastpass

[dkleinsc]

Yeah, I really want some alphabet soup dude from Washington looking out for my internet security.

I might want that, because the government guy at the very least doesn't have a short-term financial incentive to skimp on doing a decent job of it.

Imagine, if you will, a company where the tech team has done a fantastic job of buttoning everything up tight, and has some smart guys who focus on really keeping things secure. New manager comes in: "Hey, we could cut back a bit on the size of our security team, our customers won't notice a difference, and we'll save $500K a year!" His boss will almost definitely approve, because it makes more money this quarter.

Re:lastpass

[Anonymous Coward]

I suppose its a matter of definition. By my definition the best developers are the ones that don't make stupid mistakes. That's what separates them from the crowd and justifies their earning decent wages.

Re:lastpass

[Bengie]

SQL injection is insanely easy to protect against. Your input should NOT be in your command stream

C# pseudo-syntax
sql.CommandType=Procedure
sql.command = "MyStoredProcedure"
sql.parameters.add("@MyInput",InputValue)


You will never get an SQL injection through that.(assuming MyInput isn't a string that gets concatenated to dynamic SQL inside the sproc)

You could even do something like this

sql.CommandType=Text
sql.command = "select * from table"
if(InputValue != null) {
sql.command += " where table.myfield = @MyInput"
sql.parameters.add("@MyInput",InputValue) }

This is also safe from injection

Re:lastpass

[Pieroxy]

Usually, everyone knows that. The problem is on the trainee you hired for almost nothing, and as (s)he costs almost nothing, you don't want to invest time in them, so they are alone in their cubicle. They commit things and nobody looks it over.

Of course, they're trainees, n00bs that don't know better than to concatenate strings to build sql queries.

All in all, in a fair amount of these cases, I'm sure it's bad management instead of poor technicians/developers.

Re:lastpass

[Bengie]

I agree. Bad management encouraging/enabling poor technicians/developers by not looking for quality hires.

Either way, we can still blame Yahoo as they have a professional responsibility to make sure their employees know common industry standards. Protecting against SQL Inject is common knowledge. I learned about it sophomore year and StackOverflow users mention it in almost every case where it could happen when a question is posted.

Re:lastpass

[Anonymous Coward]

"government guy at the very least doesn't have a short-term financial incentive to skimp on doing a decent job of it."

I suppose, but he also has the incentive to look for problems where they don't exist and suggest (perhaps force) idiotic & possibly very expensive solutions to simple problems. Its not tech related but I do have an example of bureaucratic incompetent at the state level. About a year back someone dumped around a hundred gallons of oil into a small creek in our area. From what I understand someone contacted the state DEQ and they contacted the counties Drain Commission and demanded they act. The Drain Commission had never handled a situation like this so they asked the state how to proceed. The response of the state was "throw straw into he drain to soak up the oil". After an environmental cleanup contractor was hired they noted that throwing loose straw into the drain was just about the stupidest thing that you could do and added significantly to the costs of the cleanup.

Re:lastpass

[mlts]

Nail, head hit.

To boot, with all the information floating around, it is easy to do a targeted attack. I'm sure GPS info can be obtained to track where someone goes in a day. Combine that with some criminal element in a local area doing the HUMINT (or just basic thuggery), and things can get pretty scary.

What I would like to see is a service similar to LastPass except that every device, be it a computer, smartphone, tablet, or embedded PDA dedicated for authentication would have a public/private key. Then, the database would be stashed/synced in a format like OpenPGP where each key can open the database. That way, if the server storing it is compromised, the data is still encrypted until they get their hands on one of the people's devices and get access to that. Then figure out what the password is. Of course, there is always the issue of recovering access if all devices having keys to it are erased/lost/destroyed.

Re:lastpass

[marcosdumay]

Who has time to spend putting SQL queries by hand at their software nowadays? Really, who at 2012 isn't using a database abstraction library?

Well, ok. I know, TFA answers that. It was kind of a rethorical question... (Me? I prefer to lose my time reading /.)

Re:lastpass

[uigrad_2000]

To make it clear, it wasn't Yahoo! directly that was compromised.

The Yahoo property that was compromised was Yahoo Voice, which has been outsourced to another company (Jajah) for operation since 2008.

Re:lastpass

[Feyshtey]

I might want that, because the government guy at the very least doesn't have a short-term financial incentive to skimp on doing a decent job of it.

Short-term? No. Long-term? Absolutely. You start pointing out that your supervisors, coworkers and senior IT architects are idiots and your career path starts looking like a dead-end dirt road.

Re:lastpass

[Anonymous Coward]

Only if your retarded enough to store your .kdb files online e

Re:lastpass

[Anonymous Coward]

Usually, everyone knows that. The problem is on the trainee you hired for almost nothing, and as (s)he costs almost nothing, you don't want to invest time in them, so they are alone in their cubicle. They commit things and nobody looks it over.

Of course, they're trainees, n00bs that don't know better than to concatenate strings to build sql queries.

All in all, in a fair amount of these cases, I'm sure it's bad management instead of poor technicians/developers.

That's only half the problem.

The other glaring problem has little to nothing to do with SQL Injection or the n00bs that were hired to sling cheap code... data segregation.

It's very handy to be able to do a join from profile info to login credentials and back, but it's not necessary.
Put the sensitive information in a separate location, and treat the code that deals with it with greater care and concern - ie. don't let n00bs touch anything related to authentication or credit cards (and maybe some other stuff too).

Put the auth system somewhere very safe, and have a very simple but secure API to get to it (ex. HTTPS basic auth). You can keep the login name on the main system if you want, or get a return id and use that as the main systems way to figure out who it belongs to in the main system.

That's just one way to do it, but it's a design decision that is simple and would be well within the budge of Yahoo (ie. can afford separate servers for that), and there's no way any sql injection in the millions of lines of code elsewhere can affect it.

If you know there's a common security issue that shows up time and time and time again, design stuff with the expectation that it'll happen to you. Rather than making sure there isn't a single line of vulnerable code anywhere, make it so you only only have to be sure of a couple hundred lines, and do you best with the rest of it.

Lastly, provide a way for people to find out if they were affected. Why isn't that the first line of every one of these articles - just enter you login name, and it says if it's in the list or not.

Re:lastpass

[nobaloney]

injection AGAIN? There's just no damned excuse for it.

Sure there is; they said it was a union attack. You get a thousand of those union goons coming after you with needles, and you succomb quickly.

Re:lastpass

[bhiestand]

I'm not sure I fully follow, but LastPass does support various forms of multifactor authentication. I could give you my LP password and feel reasonably secure you won't be able to get in.

Re:lastpass

[mlts]

Authentication != encryption. A place can require a lot of passwords and other things before allowing access, but that means nothing if an intruder can snarf the backend database and dump it.

Two factor encryption is very useful. TrueCrypt supports keyfiles which are XOR-ed with the user's passphrase. No keyfile? No way to figure out the passphrase that unlocks a container.

Another implementation can be public/private keys where the master key is encrypted to list of public keys, which the OpenPGP format is for. This way, device A's key can unlock and modify data, as well as device B which has a different public key. All of this can be done with the backend seeing nothing but encrypted data. Of course, there are some attacks that can be done via traffic analysis.

Multifactor authentication is useful. However, for storing very sensitive data like passwords, multifactor encryption is critical, especially if the backend is remote.

Re:lastpass

[bhiestand]

Good point. It looks like I [mostly] wrongly assumed that LastPass was also using multifactor tokens for encryption. Apparently they do use the Yubi Key's static key in the local encryption process, but I can't find the specifics.

Given your reply, I'd agree that there's still some room for improvement. However, assuming they aren't compromised and nobody discovers my password, LastPass has dramatically increased my security. KeePass had terrible browser integration and a UI that didn't work for me, so I didn't use it for many passwords.

With LP, I was able to go through and upgrade all of my passwords, using security check to look for duplicates and weak passwords. Actually, I just checked. I have 394 unique passwords.

Re:lastpass

[mlts]

This isn't to say LastPass is bad. I just prefer to "pack my own parachute" and use clientside encryption.

In theory (and this is pure conjecture, mind you), a cloud provider with a dedicated client can push a single update to a person with modified code that would log the key when typed in and send it up. Then another code push would wipe the evidence.

Say we have a cloud provider. I can't think of a good name, so will use $PROVIDER. $PROVIDER offers a service where users can store data as backups similar to Mozy or Carbonite. $PROVIDER's client uses a key only stored on the user's machine for encrypting files before they sre sent up. Sounds well and good because no cleartext ever is stored on the cloud provider's servers.

Later on, someone who doesn't like a user pays $PROVIDER some cash in return for some files that would get "accidently" divulged. $PROVIDER pushes out a simple update quietly to that single user. The update grabs the key stored, be it a keyfile or typed in text, and uploads it. Then the code removes itself.

It is highly unlikely in the real world, but it can happen. It tends to be harder to make multiple entities collude than it is to demand one organization do a small and likely undetectable code modification.

Re:lastpass

[Dr. Evil]

You're suggesting to protect against SQL injection by passing unsanitized user input as parameters?

Re:lastpass

[dkleinsc]

Thing is, with civil service rules, you don't lose your job in that kind of situation.

I have an acquaintance who actually is dealing with that right now. He publicly demonstrated that the methods that his supervisor demanded he use to determine the purity of gold in coins at the US Mint were faulty, allowing corrupt dealers to substitute in other metals. In the private sector, he would have been fired. In the public sector, he still has a job: his supervisors have done their best to make that job miserable (making a GS-13 bag coins all day), but they aren't able to stop him from keeping a roof over his head.

Obligatory

[Lumpio-]

I'm more surprised that Yahoo still had almost half a million users.

Re:Obligatory

[Anonymous Coward]

It won't be long until they are forced to rebrand to Ya-who? As they continue their relentless decline into total insignificance...

Re:Obligatory

[Anonymous Coward]

In the US (5% of the world).

Re:Obligatory

[Anonymous Coward]

Remember Lycos? Yeah... didn't think so... History provides many examples of firms with shitty management that everybody eventually forgot. Yahoo has just been circling the drain for so long people are starting to believe it could defy gravity.

Re:Obligatory

[ElmoGonzo]

About 15 years ago, I had a yahoo email address and managed to lose/forget the password. There was no recourse so I stopped using that account. Hmmm, I wonder if it is one of the ones that got leaked and I can find it now.

Re:Obligatory

[Cro Magnon]

For me, it's the other way around. I quit using the yahoo address, and now I have no clue what the password was.

Re:Obligatory

[Anonymous Coward]

For me, it's the other other way around. I forgot my Yahoo games account name and stopped playing pool. Those were good times though.

Re:Obligatory

[bughunter]

According to Email Marketing Reports, Yahoo! Mail has somewhere between 275 million and 310 million users.

Therefore, if you have one Yahoo! Mail account, the odds of your password being in the leaked list are about 0.15%, or about one in 666.

There is some information that the email addresses and passwords are not for Yahoo! Mail but for Yahoo! Voice, which is supported by a look at the list. It includes a lot of non-yahoo domains, including many for gmail and hotmail. This seems to support that conclusion, although those could be what Yahoo! calls the "primary email address," which is an address an account creator must provide for authorization, and to which account notices, warnings, etc. are sent.

Re:Obligatory

[Anonymous Coward]

Yahoo has plenty of users. Their removal of any standard way to report abuse of their services by spammers and scammers ensures repeat business. Maybe it's fixed now, but a few months back the only way I could find to report abuse was to first sign up for a Yahoo account. Not even abuse@yahoo.com works, and their dupport site links for contact led to nothing but irrelevant help articles and broken links. Fuck Yahoo, their management and their users. All aboard the roflcopter for an ariel view of Yahoo being fucked over.

Re:Obligatory

[Anonymous Coward]

For me, it's the other way around. I quit using the yahoo address, and now I have no clue what the password was.

This is your golden moment...you can find it out now!

Ah, injection attacks..

[Rei]

when will people ever learn? And not just SQL injection attacks. I had to actually write a destructive exploit for a popen injection attack on a MMORPG before the rest of the dev team would believe me that it was a serious vulnerability (it had code that if you said a URL, people could click on it... except they were just passing what the user wrote to popen, tacked to the end of your browser-launch string). People just never seem to wrap your head around the fact that you never use raw user input for anything that a parser will look at, at any point in time!

Here's probably the funniest discussion thread on injection attacks, ever.

Re:Ah, injection attacks..

[Simon Brooke]

Here's probably the funniest discussion thread on injection attacks, ever.

That is indeed funny, in a most terrifying way!

Re:Ah, injection attacks..

[ArcherB]

People just never seem to wrap your head around the fact that you never use raw user input for anything that a parser will look at, at any point in time!

Here's probably the funniest discussion thread on injection attacks, ever.

So, can I trust YOUR link?

Re:Ah, injection attacks..

[alphatel]

So, can I trust YOUR link?

Only an arse would parse the terse farce of vars in pairs.

File

[Anonymous Coward]

Does anyone have a link to the leak? You know, I want to check if my password was leaked.

Re:File

[Anonymous Coward]

http://it.slashdot.org/comments.pl?sid=2974701&cid=40627163

Re:File

[Anonymous Coward]

Just type it in a reply below, like mine.
It will show ******* if it is still there!
******

Re:File

[Chessphoon]

This page lets you check your email address to see if it is part of the leak: http://www.afterdawn.com/yahoo_password_leak.cfm

Re:File

[HyperQuantum]

hunter2

Re:File

[Anonymous Coward]

Does it say "Now it is!" when you submit yours?

Re:File

[Amouth]

+1 thanks

Re:File

[amw]

*******

Did you mean to type those?

Re:File

[Rude Turnip]

You just typed *******

Re:File

[broggyr]

I sure hope this is meant as a WHOOSH

Re:File

[broggyr]

Shit. Looks like I've been whooshed lol

Re:File

[dsinc]

https://d33ds.co/archive/yahoo-disclosure.txt The server is belly up, though, as I write this (7:15am PDT). Please mirror, if you can get your hands on the list. Another list of the compromised accounts (search enabled, no passwords), is here http://dazzlepod.com/yahoo/

Re:File

[N0Man74]

I'm paranoid, so I wondered the same thing about these "enter your address" lists on the 2 sites (that I had never heard of before) mentioned here.

However, it works with partial search too. You don't have to have the entire address to match.

Re:File

[Thelasko]

Does anyone have a link to the leak? You know, I want to check if my password was leaked.

Here you go.

Re:File

[Anonymous Coward]

http://thepiratebay.se/torrent/7436152/yahoo-disclosure.txt

Any site hosting it is getting hammered.

Re:File

[Anonymous Coward]

My Yahoo email is on there, but with an old password I use for throwaways. So, this isn't a dump of main Yahoo accounts but of accounts used to sign up for some Yahoo service that doesn't use the main Yahoo accounts. I would've only used that password to post a comment or a message board or something like that.

Re:File

[Anonymous Coward]

Thank you.

Now, mods, why is my question at +5 and the answer (entered 20 minutes later) at +2?

Re:File

[kasperd]

Does anyone have a link to the leak? You know, I want to check if my password was leaked.

I don't want to take part in distributing the plaintext version, so what I did instead was as follows.

1. I found the plaintext version and downloaded it
2. I computed a new version of the file where everything was salted and hashed
3. I created a torrent of the protected version

So if you just want to check if your password was leaked, you can download my version and check. If you want to use the list for something else, such as statistics on used passwords or attacking affected users, then you'll need to keep looking for the plaintext version.

who uses yahoo

[Anonymous Coward]

450000? so about 15 are real email accounts that people use.

Re:who uses yahoo

[Zaiff Urgulbunger]

450000? so about 15 are real email accounts that people use.

I only skimmed TFA and it seemed to indicate that these were probably related to the Yahoo! Voice service... whatever that is.

As for their email, probably quite a lot of people do use it as some ISPs use Yayhoo! to supply their own-branded email. BT Internet in the UK for one anyway.

Re:who uses yahoo

[Anonymous Coward]

450000? so about 15 are real email accounts that people use.

I only skimmed TFA and it seemed to indicate that these were probably related to the Yahoo! Voice service... whatever that is.

It was data that was used to sign up for Yahoo Voices / Yahoo Content Network (formerly Associated Content). There's yahoo, gmail, hotmail, and all kinds of other stuff in there. If people signed up to the service using a different password from their email account password (and using the same password is always a really bad idea) then they're not at risk.

From the Yahoo! press release:

"We confirm that an older file from Yahoo! Contributor Network (previously Associated Content) containing approximately 450,000 Yahoo! and other company users names and passwords was compromised on July 11. Of these, less than 5% of the Yahoo! accounts had valid passwords."

Re:who uses yahoo

[Anonymous Coward]

As for their email, probably quite a lot of people do use it as some ISPs use Yayhoo! to supply their own-branded email. BT Internet in the UK for one anyway.

Yes, SBC (now AT&T) started doing that around 10 years ago. Every email you see from sbcglobal.net or any of the other AT&T customer domains is actually hosted by Yahoo.

common security pratics ?

[Rachael]

Seems to be common pratics that sites store plaintext password this days, one would think the programmers knew better, is it in an attempt to try and speed optimize things, they leave out hashing ?
Or is there a more sinister reason, someone twisting their arm around.

Re:common security pratics ?

[Kyrene]

Once worked in a place where the "architect" swore up and down that his "philosophy" was that if people were to hack into the database, they wouldn't then get the keys to the account, they'd go for other details like credit cards and what-not, so there was no reason for encryption. Very glad I'm not working there anymore because arguing with him was useless. Once his mind was made up, that was that.

Re:common security pratics ?

[Rei]

I think in most cases, they honestly don't know any better, followed by as the next most likely reason, they were too lazy. Sinister reasons is probably number three. I doubt optimization makes the top 10.

Re:common security pratics ?

[shentino]

The only answer is that if the guy who owns the fucking playground doesn't want you on their toys, leave.

Re:common security pratics ?

[Anonymous Coward]

I wrote my first php/mysql application about 3 months ago, and even I knew better. So I think you have the first 2 mixed up: In most cases, they were just too lazy.

Subsuently, posted this as AC, because I'm too lazy to login...

Re:common security pratics ?

[arth1]

I think in most cases, they honestly don't know any better, followed by as the next most likely reason, they were too lazy.

Never underestimate the push of S&M to get things out the door, not as soon as possible, but earlier than that. Waiting days or weeks for proper authentication to be implemented and tested means days or weeks without sales bonuses for them. They'll likely be long gone by the time anyone breaks in anyhow.

It doesn't matter much if the developers and technical admins say that it's sheer lunacy if the CFO says you need to release nao because S&M told him so.

It's even worse in companies that work on a project model where they move all devs and techs who know the project off it at release, without ever looking back. Then it's a certainty that it'll never get fixed.

Re:common security pratics ?

[QuantumRiff]

But this time it was okay.. It was probably on a development system, and everyone knows nobody can get to the server, its behind "The Firewall".

Re:common security pratics ?

[RabidReindeer]

Seems to be common pratics that sites store plaintext password this days, one would think the programmers knew better, is it in an attempt to try and speed optimize things, they leave out hashing ?
Or is there a more sinister reason, someone twisting their arm around.

Any sytem that can't handle the overhead of a hash function is already on the edge of the abyss to begin with.

As for "sinister reasons", try "We get our programmers for Lower Prices Everyday[TM]".

Re:common security pratics ?

[snookums]

If it's not programmer incompetence, it's usually a push from the product manager to have "email me my password" as the password recovery mechanism.

Re:common security pratics ?

[mauhiz]

Yeah, those S&M guys really like to have us suffer...

Re:common security pratics ?

[Kyrene]

Thankfully it was a contract so that's just what I did.

stinking unions

[reasterling]

they managed to access the subdomain by leveraging a union-based SQL injection attack.

So, the republicans are right. Unions are evil. ;)

Re:stinking unions

[Anonymous Coward]

they managed to access the subdomain by leveraging a union-based SQL injection attack.

So, the republicans are right. Unions are evil. ;)

Nah, they tried to hire scabs, they just couldn't find anyone that was qualified to do the work.

Re:stinking unions

[Tablizer]

If you think UNION is bad, try the ENRON or MADOFF command.

Re:stinking unions

[Culture20]

they managed to access the subdomain by leveraging a union-based SQL injection attack.

So, the republicans are right. Unions are evil. ;)

Nah, they tried to hire scabs, they just couldn't find anyone that was qualified to do the work.

Hey! Didn't your mother ever tell you to not pick on the scabs!

I've used yahoo voice in the past

[circletimessquare]

Just changed my password.

Thanks Slashdot, seriously.

Re:I've used yahoo voice in the past

[sticks_us]

Just dumped all my yahoo accounts (had two spam accounts and one personal account).

I've had them since the late 1990s, and while I hate to kick someone while they're down, the service has only gotten worse lately--spam, unwanted yahoo! instant messenger robot requests, "Temporary Problems Accessing Your Account" messages--the whole deal.

This kills it for me. I interviewed with Yahoo! about six years ago (didn't make it past the second cut, so yeah, I'm a moron) and being VERY impressed with how smart their teams were. Wonder if all the good ones left or got fired somewhere. Too bad, really.

Sorry guys, but thanks for the great 15 years!

Re:I've used yahoo voice in the past

[circletimessquare]

did you use yahoo voice? only yahoo voice customers were affected

not that this story shouldn't change your opinion of yahoo, and therefore dumping them is a good choice on your part

i'm just saying the article specifically mentions yahoo voice customers as the victims, which i was about 2 years ago, but, if you weren't, you should be ok

Re:I've used yahoo voice in the past

[fatphil]

"Wonder if all the good ones left or got fired somewhere."

I do remember reading of several firing sprees in the last few years. The best are often the first to leave even when the firing spree is only intended to clear out deadwood.

Re:I've used yahoo voice in the past

[g1zmo]

And this is why the message doesn't go in the title, folks.

Re:I've used yahoo voice in the past

[sticks_us]

Nice. My bad for not reading the article thoroughly enough, thanks for pointing it out.

That doesn't mean Yahoo! gets a 'pass' though. For a company with as much talent/infrastructure/experience as they should have, this kind of thing is definitely a warning sign.

Enjoying my !yahoo mail right now :D

That explains things

[halcyon1234]

That explains why, about a month ago, I got a whole rash of "omg funy click here" spam mails for friends with yahoo email addresses (and only yahoo email addresses). I wonder how recent this password dump is. I might have to recommend another round of reset-to-something-complex. My first recommendation was STOP USING YAHOO FFS!, but no one does that =(

Re:That explains things

[unixisc]

Thanks for saying what it was. A month ago, I saw a whole bunch of message unsuccessful to everyone in my contact, which actually is a huge number since I have all job contacts there. Two or three people told me that I was infected w/ a virus. I used Thunderbird at the time as my e-mail client, but following this, I changed my password. I recognize that I may have to migrate this account, but it has too much of stuff to make it a trivial exercise. And since I use plenty of folders, Gmail won't do here.

This was scary, b'cos I thought my PC might have a virus, despite the anti-virus that I have. And the auto-signature that Yahoo! attaches every time makes one pause to wonder.

If it was just my personal e-mail to a few family members & friends, switching would be no big deal. Unfortunately, in my case, it's the e-mail that I use for all my job contacts, bank info contacts and so on, so changing all that is by no means trivial.

Re:That explains things

[deicide]

And since I use plenty of folders, Gmail won't do here.

Gmail works fine with folders. You can set up Thunderbird with Gmail's IMAP and then drag/drop your Yahoo folders onto it to migrate all your old mail.

Re:That explains things

[Anonymous Coward]

I saw that start right after the twitter password grab. It was most certainly for those that used the same password for both. An added wrinkle was that when I was assisting some people after that, their online administration password had been changed but not the pop/smtp ones for those that had email addresses from the companies that had partnered long ago, sbc, bellsouth, etc. So they had to call customer support to change passwords if they had not added extra password protection during all the sbc/yahoo/att churn over the years.

Re:That explains things

[Runaway1956]

Your antivirus only protects you from old, obsolete viruses. It doesn't protect you from anything current. Go to infectymypc.com and check it out!

Re:That explains things

[Bengie]

Newer antivirus engines use heuristics. Vipre was reviewed to have about 95% effectiveness on 0-day unknown malware. If I ever get an anti-virus, that will be the one. So far the Microsoft one works just fine.

Re:That explains things

[Anonymous Coward]

So, essentially, what you are saying is if I'm exposed to 200 0day viri / exploits per day that I will have contracted statisticly speaking 10 different strains of something that my av will have missed?

I feel so much safer nao... Statisticly speaking...

90% of all statistics are made up on the spot...

From Mikko Hypponen

[Orm]

"I'm really surprised that Yahoo leaked 450,000 user passwords. I had no idea Yahoo still had that many users." (link)

"Had another look at the latest Yahoo password leak. There are two users with the password 'hunter2'. (See QDB: http://bash.org/?244321)" (link).

This company 'd33d'

[Anonymous Coward]

First they sound a bit on the childish side with the silly name, second - why do they do it? They aren't getting money from this are they?
Can someone explain this?

Re:This company 'd33d'

[ledow]

1) To show they can
2) To make Yahoo look bad (and boy should they look ashamed at the moment!)
3) To highlight a security flaw that Yahoo may have been knowingly ignoring
4) Because they stumbled across it and realised they COULD dump all the passwords and then it snowballed.

Or a million and one other reasons. Hell, I've found sites where I could have done all sorts of damage via SQL. Not everyone is nice enough to inform them and if you inform them and are ignored ("nobody would ever try to do that on our live website, so we won't fix it"), would you rather someone else found out, or you forced that site to tighten up?

Just think - if they hadn't done it, 450,000 people would have their emails and passwords floating around on hacker forums eventually anyway and it wouldn't make the news at all.

Re:This company 'd33d'

[Anonymous Coward]

YHOO dropped about 1% since yesterday (the news broke before trading this morning). I wonder if they pulled the money out of that.

Re:This company 'd33d'

[Anonymous Coward]

dumping people's passwords isn't forcing Yahoo to tighten up without harming the end user. if they want to be a knight in shining armor they should find a way to do it without harming the end user.

File here:

[Anonymous Coward]

http://d33ds.co/archive/yahoo-disclosure.txt

Slashdotted, more info here:
http://dazzlepod.com/yahoo/

SQL Injection, in this day and age?

Fuck yahoo, fuck the cloud, fuck all the big providers...

Re:File here:

[jonwil]

Thanks for that link, looks like my password was not stolen.

Re:File here:

[ledow]

Because not having your password appear on a single leaked list of a limited number of usernames hacked from Yahoo by an SQL injection from a public site from an unhashed database is obviously reason to just relax and know that everything is okay.

Who cares if you're on the list? If you're using Yahoo, change your password, change your account, change your online service provider to anything but Yahoo.

SQL injection on public sites with unhashed passwords stored in open databases. This is like saying "Hell, my house wasn't burgled this week - Phew! I can continue using the security company whose alarms don't work, their security personnel never arrive and they leave all my doors unlocked!"

Re:File here:

[MikeS2k]

Seems they are having bandwidth problems, anyone have a mirror?
Anyone know if the passwords leaked were part of a particular service (I read something about Yahoo Voice) or are they just a random selection of normal e-mail accounts?
I work at a school and am trying to decide whether to e-mail my users with advice about changing their passwords or not (judging by outgoing smtp over half of them have yahoo accounts.. I wonder why it is so popular?)

Re:File here:

[Anonymous Coward]

Who cares if you're on the list? If you're using Yahoo, change your password, change your account, change your online service provider to anything but Yahoo.

One of my garbage accounts is on yahoo and I *would* change the password. As I checked the list and appear (relatively) safe, I will assume all is well. Like I said, it is one of several garbage accounts.

Re:File here:

[Anonymous Coward]

http://74.208.167.77/archive/yahoo-disclosure.tar.gz

Yahoo Mail?

[Jason Levine]

Does this include Yahoo Mail accounts?

I know that, awhile back, my account was logged into from some other country (someplace in South East Asia, IIRC) and a bunch of spam links were sent to my contacts. I had a complex password and they didn't change any information. (Odd, since I thought one of the first things a hacker would do is change the password to hold onto the hacked account.) I changed my password and sent folks notice about the hacking. (No, I didn't click on any links or run any programs that would have caused this. I'm extremely careful about security.)

Months later, for a few weeks, I kept getting notices about someone trying to reset my Yahoo Mail password. I kept a close eye on the situation, but it never seemed to progress beyond trying to use the password reset tool to get into my account.

I don't even actively use my Yahoo Mail address anymore. Over the years, it got too clogged with spam and I much prefer GMail. Still, I keep it around just in case.

Re:Yahoo Mail?

[ledow]

I don't know, it seems to be quite limited. There's tons of gmail and other domain addresses in there. I think it could be either what you signed up to Yahoo Voice as, or what you signed up to Yahoo as and they only got some addresses before they got caught (or aren't posting all the adddreses they captured).

There's even a few old Geocities addresses in there, which were later changed to "username.geo@yahoo.XXX" addresses when Yahoo took over:

http://dazzlepod.com/yahoo/?email=.geo%40yahoo

If nothing else, given their lax security and data protection (Completely unhashed passwords? Really?), I'd change any account password on a Yahoo account, and any password on an account you've used on Yahoo (e.g. if you've plugged your GMail or messenger or any address into your Yahoo acccount for whatever reason - e.g. POP3 collection of other accounts or whatever).

Still don't know my yahoo password...

[Anonymous Coward]

My yahoo password has been forgotten for some time now and I can't remember any of the "registration details" that I used to make it anonymous, so a reset is also not impossible. I was hoping that maybe this password dump would help me out but no... they didn't dump the password to my account... grmpf!

Re:TWO moronic 'Americanisms' in one sentence!

[Dog-Cow]

You are not an idiot. Idiots are brilliant in comparison to what you are.

The alternative is worse

[XB-70]

Having my password leaked online with all the potential that that holds is far less abusive than what Yahoo! does with the information in my emails.

something missing?

[issicus]

im sorry, maybe i missed something, how do i know if my password was stolen ? also YELLING isnt always a bad thing CAPS.

how about checking

[Anonymous Coward]

how about checking more than just this leak...

have a look at http://bit.ly/rosGrL

regards

John Jones

xkcd reference...

[jelle]

Obligatory xkcd reference

http://xkcd.com/327/

Am I missing something...?

[Assmasher]

I presume that you cannot actually reach the DB directly (it is shocking how many people in smaller companies have their DB actually in their DMZ), so they must be pushing the SQL injection through an actual Yahoo API, right?

How hard is it to evaluate a string for potential danger?

Surely API calls can be divided into context and 'grammars' of a sort, then these API calls can identify whether a given string is more or less likely to be a threat by keywording, if anything is suspicious (and at this level there will likely be a lot of false positives) you perform a more thorough evaluation based upon the context of the call, and so on...?

Anybody out there do this for a living? Insights please :)

Re:Am I missing something...?

[TheNinjaroach]

How hard is it to evaluate a string for potential danger?

If you are evaluating a string for danger, you're doing it wrong.

I'm starting to think that web developers should be licensed before they're allowed to generate a single statement of SQL.

Re:Am I missing something...?

[JDG1980]

How hard is it to evaluate a string for potential danger?

Pretty hard, if you don't want to corrupt user data. A botched attempt to do so is how the bogus word "medireview" was created.

What they really should be doing is using parameterized queries so that the user-input strings cannot be treated as SQL commands, but will always be treated as data.

Re:Am I missing something...?

[Assmasher]

I'm not sure I understand where you're going with this, I evaluate ALL external input (not just from users) for danger.

I'm not a web developer though (mobile/thick client/enterprise only) which is why I asked if I was missing something since this seems trivial to do...

Re:Am I missing something...?

[Anonymous Coward]

I'm not sure I understand where you're going with this, I evaluate ALL external input (not just from users) for danger.

I'm not a web developer though (mobile/thick client/enterprise only) which is why I asked if I was missing something since this seems trivial to do...

"Evaluate for potential danger" sounds like it's searching the string for certain characters. The proper way to do it is to escape strings before using them in SQL statements. Or even better, to use a library that does it all for you so that you don't get caught out by some obscure syntaxes you didn't think about.

Re:Am I missing something...?

[Assmasher]

I didn't say "correct potential danger", I said "evaluate." Replacing things is (a la medireview) is a flat out stupid approach anyhow, lol (thanks for the link - it made me laugh.)

I agree that everyone should use parameters instead of string concatenation, but that doesn't make things safe, it just makes them a little bit safer. Parameters don't help if someone passes the user name "';drop table important_table"

ALL input MUST be sanitized whether you use parameterized SQL or not; ergo, you must evaluate the data in some context.

Re:Am I missing something...?

[drkstr1]

Not all dangers can be known, so it is better to parse for what you need (white list), and use it as data in a type safe command (ORM, stored procedure, etc). This insures that only operations that will run are the ones you have written yourself.

Re:Am I missing something...?

[Anonymous Coward]

Yes, it does. You are an idiot. If that works, then the way the parameter is escaped is wrong. SQL injection IS NOT MAGIC.

Re:Am I missing something...?

[fatphil]

> How hard is it to evaluate a string for potential danger?

Utterly trivial.

If it came from an external source, it's a potential danger.

Never ever put anything that is potentially dangerous anywhere where it could do anything dangerous. E.g. do not build queries out of it. This may have many false positives, but it has no false negatives. And if you're going to fail, fail safe, don't fail unsafe.

Re:Am I missing something...?

[Fwipp]

Actually, parametrized queries do completely eliminate the 'pass the user name "';drop table important_table"' vector.

Re:Am I missing something...?

[Jeremi]

If it came from an external source, it's a potential danger.

I'm sure I'm just being naive here, but it seems to me that user-supplied strings are only dangerous if your site ever passes strings to an SQL parser that converts them into database commands and then executes those commands. If your site never does that, then even the most evil SQL string is nothing more than a sequence of inert character data.

Given that, one way to avoid SQL injection would be to simply disable the database server's SQL parser and never use it. The site's own code could still do SQL queries, etc, by building them programatically using an API, rather than by expressing them as character strings. That way there is no mechanism by which trusted code and the untrusted data might be unintentionally intermingled.

Re:Am I missing something...?

[marcosdumay]

Ok, several questions...

- Many small companies have their DB at the DMZ because they only have a DMZ. Most of the time, they also only have one server at the DMZ... It is a significant saving for them. Also, as a rule, putting your DB inside a firewall doesn't protect against SQL injection.

- In a SQL injection attack, you inject the SQL by the application. In this case, that means they send the SQL for the web server, executing whatever software Yahoo uses. Then, the application executes your SQL on the database. The "application" here could be either Yahoo web pages, it's APIs or anything else that is reacheable by the web.

- I don't get where you want to go with "evaluating a string for potential danger". As a matter of policy, you just don't create situations where a user entered string can be dangerous. That means that if the user enters "'; DROP TABLE students;--" in a text field, you just don't evaluate it, you put exactly "'; DROP TABLE students;--" into your database. That may require that you analize the string and escape the right parts, but it is not exactly "evaluating it for danger".

Re:Am I missing something...?

[Assmasher]

- Many small companies have their DB at the DMZ because they only have a DMZ. Most of the time, they also only have one server at the DMZ... It is a significant saving for them

Significant saving? It is seriously cheap to put a linux box in the DMZ and use it as a firewall (probably cheaper than their monthly expenditure for network access.)

Also, as a rule, putting your DB inside a firewall doesn't protect against SQL injection

That depends, lol, the same type of company that would leave their DB server in the DMZ would likely have a default/no security on it.

In any case, putting it behind the firewall means that it is MUCH more difficult to reach that DB in any way except through software/services configured to make use of it. It means your DB isn't listening for just anyone to connect to it from anywhere on the net.

As a matter of policy, you just don't create situations where a user entered string can be dangerous. That means that if the user enters "'; DROP TABLE students;--" in a text field, you just don't evaluate it, you put exactly "'; DROP TABLE students;--" into your database. That may require that you analize the string and escape the right parts, but it is not exactly "evaluating it for danger".

That's exactly what it is doing. You're sanitizing input. Escaping strings IS evaluating strings for dangerous elements...

Serious SQL injection attack security requires many things including parameterization, properly packing those parameters when using them in a stored procedure (for example), pattern matching the input, role based DB security, et cetera...

Re:Am I missing something...?

[fatphil]

No, you're not being naive, but in part you're missing the point. If "they are only dangerous if X", then they are potentially dangerous. Basically by definition.

And yes, when you have something potentially dangerous, you never interpret it outside a sandbox that permits only the behaviour you explicitly want the external entity to be able to invoke. That looks like a fancy way of saying something quite similar to "check that it's safe", or whatever you said earlier. However, in this instance you must have full control over that interpreter, and trust that you never write code with bugs. You must carefully sanitise them of all possible threats. But how can you be sure you know what all possible threats are? (years of experience, and being perfect seem to be 2 requisites) Instead, the correct (safe) attitude to take is that unsafe data should never be passed to anything that interprets them - they should be passed as an arbitrary string of bytes, nothing more. The technique for this in SQL is called using "Prepared Statements" - all the parsing is done in the absense of the external data, in such a way that the external data is, as you say, inert data. It requires self control to do this, and most programmers don't have the patience to do it *always*. The mechanism to mix trusted code and untrusted data isn't just there in almost every web-oriented programming language, it's the *easiest way of doing things*. This is why the mistakes are so often made. And why harsh (but fair) code review is so important.

Of course, even that's not enough paranoia, as you must make sure that you don't pass that data on to any other entity that isn't as untrusting. The browser "trusts" the web server, in general, which means that if you're sending potentially-dangerous (i.e. any) externally-provided data (such as something pretending to be a blog comment) to a browser, it is your job to ensure that you escape the data in a way that the browser won't attempt to interpret it. (c.f. javascript injection)

Re:Am I missing something...?

[Anonymous Coward]

You do not understand how SQL parametrized statements work. Please do everyone a favor and avoid working on any production projects involving SQL; if you don't, it is likely that you will be the author of the next exploitable code.

Re:Am I missing something...?

[shutdown -p now]

Given that, one way to avoid SQL injection would be to simply disable the database server's SQL parser and never use it. The site's own code could still do SQL queries, etc, by building them programatically using an API, rather than by expressing them as character strings. That way there is no mechanism by which trusted code and the untrusted data might be unintentionally intermingled.

That much is true - if you use, say, Hibernate criteria APIs, or something like LINQ, then the issue simpy doesn't arise.

But that approach is overkill for the sole purpose of preventing injection (it has other advantages, though). For that, all you need is the ability to identify placeholders in a string SQL statement where data values should be inserted, such that it is always properly handled in a way that inserted data is always treated as data and not as part of the command. In other words, parametrized SQL queries.

Re:Am I missing something...?

[marcosdumay]

Significant saving? It is seriously cheap to put a linux box in the DMZ and use it as a firewall (probably cheaper than their monthly expenditure for network access.)

You are assuming that they have a LAN, that they have physical space at the same place they have their servers, and that they have separated application and DB servers. If you own a datacenter and have specialized servers, putting the DB ou of the DMZ is a no brainer. Most small business aren't in that situation.

That's exactly what it is doing. You're sanitizing input. Escaping strings IS evaluating strings for dangerous elements...

Now, if that is what you meant, ok. The way you phrased it didn't make it clear.

Re:Am I missing something...?

[Assmasher]

...? I've never heard of a small business that had a database for serving information online that didn't have a LAN...

Most small businesses have LANs, my father in-law's little store has a LAN, my accountant has a LAN, the restaurant I am typing this at has a LAN, et cetera... ;)

Sorry I wasn't clearer about the input sanitizing.

Google for it?

[k(wi)r(kipedia)]

Try it. Requires some G-fu but the https:/// URL is discoverable within minutes.

Plaintext passwords again?

[gr8_phk]

SQL injection AGAIN? There's just no damned excuse for it.

Several people have made similar comments. What worries me is that they are not also slamming them for storing passwords in plaintext AGAIN. User passwords should not be stored anywhere on the system. You store a salt and hash of the password - this is fine for login, but fairly useless for hackers should they get it.

Re:Plaintext passwords again?

[Anonymous Coward]

SQL injection AGAIN? There's just no damned excuse for it.

Several people have made similar comments. What worries me is that they are not also slamming them for storing passwords in plaintext AGAIN. User passwords should not be stored anywhere on the system. You store a salt and hash of the password - this is fine for login, but fairly useless for hackers should they get it.

You don't store just any hash, you should store one that is expensive to compute, by using PBKDF2, bcrypt, scrypt or similar.

Re:Plaintext passwords again?

[Bengie]

Expensive hashes are only good for weak passwords. Users shouldn't have week passwords. Just use a strong salted-hash, that's Good Enough(tm), don't care about slowness.

Re:Plaintext passwords again?

[Anonymous Coward]

What's wrong with users changing passwords every week?

Re:Plaintext passwords again?

[Anonymous Coward]

Expensive hashes are only good for weak passwords. Users shouldn't have week passwords. Just use a strong salted-hash, that's Good Enough(tm), don't care about slowness.

But as we all know, users do use weak passwords.

Re:Plaintext passwords again?

[arth1]

What's wrong with users changing passwords every week?

I'll tell you what's wrong with that: Most users are human, and won't be able to remember their passwords if they change them often. Especially since most people have a handful or more passwords and PINs they have to remember.

Frequent password changes lead to either simplified passwords with a single short element that changes, or passwords that are written down on a post-it note or similar.

The greatest enemy of safe authentication is the CFO. After him or her, it's the user. You have to get both to play ball, and you don't do that by annoying either of them.

Re:Plaintext passwords again?

[Svippy]

What's wrong with users changing passwords every week?

I'll tell you what's wrong with that: Most users are human, and won't be able to remember their passwords if they change them often. Especially since most people have a handful or more passwords and PINs they have to remember.

Frequent password changes lead to either simplified passwords with a single short element that changes, or passwords that are written down on a post-it note or similar.

The greatest enemy of safe authentication is the CFO. After him or her, it's the user. You have to get both to play ball, and you don't do that by annoying either of them.

Correct, but I think he was pointing out that Bengie wrote 'week passwords' rather than 'weak passwords', i.e. I think the post was meant to be humorous.

Re:Plaintext passwords again?

[Anonymous Coward]

Expensive hashes help regardless. You're always in a race against computing power. Take whatever handicaps you can get.

Re:Plaintext passwords again?

[gmuslera]

Will be for most users changing passwords 7 times a week. One for changing it, the other 6 for the "i forgot my password" link. Is a problem, not a solution. One password for each service is bad enough, forcing to change it to something different every week would be killer.

Anyway, that most are 123456 or password, and that the server stored it in plain text or in a format where is easy to obtain the original one puts the problem several layer over the forcing changing it or not one.

Re:Plaintext passwords again?

[somejeff]

What's wrong with users changing passwords every week?

I agree. I do it. This week it's Yahoo$20120708

Re:Plaintext passwords again?

[Dishevel]

Just because my password can take 15.7 trillion years to crack dose not mean the it will take that long.

Re:Plaintext passwords again?

[LordLimecat]

From the article:

It is still unknown whether the passwords were retrieved in the clear text format or were decrypted by the attackers afterwards.

Its possible they were stored hashed, and simply cracked. That, however, WOULD strongly imply either no salt or a single global salt.

Re:Plaintext passwords again?

[Bengie]

You're always in a race against computing power.

Even if a hash was O(1) and took one clock-cycle no matter the password length, a 14+ char password will be safe for a very very long time. If you had EVERY computer in the world working on colliding your hash, to find your password, it would take decades even if they're lucky and found a way to make 500ghz graphite chips.

In the real world, hashing scales with the stream length and takes several cycles per char, plus look-up times and no 500ghz chips.

If someone wanted your password so badly, they would just buy a wrench and some thugs.

Re:Plaintext passwords again?

[TheLink]

But why should I waste my time typing strong passwords for sites I don't care that much about?

Especially if they're going to get pwned and my password ends up visible to the whole world? Because too often the idiots store the passwords in a reversible format. From what I see some of those yahoo passwords released aren't that trivial e.g. %5M%us$@7U
What are the odds the attackers brute-forced that and the other harder passwords?

If they can dump the hashed passwords for brute forcing, it usually means they can pwned the site in so many other ways that it doesn't really make a big difference.

My suggestion is to use a different password for each site that you care about.

Re:Plaintext passwords again?

[tokul]

User passwords should not be stored anywhere on the system

Check how challenge-response authentication systems work. IMAP CRAM-MD5 or DIGEST-MD5 for example.

Re:Plaintext passwords again?

[budgenator]

back during the dot com boom, the boss registered the name poiuyt.com. The emails began to pile up quickly, mostly password confirmations for people who didn't want to give up the real emails, it was quite amazing how many user poiuyt had qwerty as their passwords, second was qwerty as the user with poiuyt as the password.

Re:Plaintext passwords again?

[zifn4b]

He was just being funny about "week." However, you are correct there is indeed a logical problem with imposing more "secure" password policies on users that are simply not feasible for humans to be able to remember the passwords. These policies force users to have to store the passwords somewhere in plain text in order to remember them. Surprise! We just defeated the whole goal of not having passwords stored in plain text except in our heads because it's now on a sticky note under your keyboard or wherever.

The types of policies that are contributing to this are, among others, 1) Requiring frequent changes of passwords, 2) Requiring passwords to be strong in character selection rules, must contain numbers, letters and symbols, cannot be any consecutive letters or numbers, etc. This makes the passwords incredibly difficult to remember as a mnemonic device and 3) Password lengths. We are being required to have longer passwords. Steve Gibson has a very interesting tool called Haystack demonstrating that 8 character passwords are insufficient and trivial to crack with today's computing power.

What is the solution? Heck if I know, but it probably isn't passwords. As computing power increases, the length and complexity of the passwords will also have to increase in order to defeat or greatly discourage brute force attacks. But they will also render passwords useless because no on can remember them.

Re:Plaintext passwords again?

[charlieman]

I think I'll start using variations of "FUCKYOUSTOPUSINGPLAINTEXTFORSAVINGPASSWORDS!!!" as my password. Too bad /. only allows 20 characters.

Re:Plaintext passwords again?

[kasperd]

You don't store just any hash, you should store one that is expensive to compute, by using PBKDF2, bcrypt, scrypt or similar.

I don't see what is wrong with using a cryptographic hash function, which has had lots of review, like for example SHA256 or SHA512. I'd much rather use a fast hash, which has been reviewed by many cryptographers than a slow one, which has not had as much review.

Making changes that slows down legitimate usage by the same factor as brute forcing is not the kind of improvements I like to see. You can do it, but then you are going to make your service vulnerable to DoS attacks.

Last time this discussion was on slashdot an interesting question was raised about whether you can offload some of the CPU heave calculation to the client, to be performed in javascript. I made a proof of concept, which demonstrates how you can slow down password brute forcing without requiring more CPU usage on the server.

Since then I have thought about another scheme, which I think would be even better. Instead of the client performing calculations that have no purpose other than being slow, why not use those CPU cycles for something that can actually improve the security in other ways. The idea I came up with works as follows:

1. Client uses sitename, username, and password as input for a cryptographic PRNG
2. Client uses pseudorandom output as input for a key generation algorithm
3. Client sends public key of generated keypair to server
4. Server retrieves a salted hash of the public key from a database
5. Server verifies that the public key is correct
6. Client proves that it is in possession of the corresponding secret key

This approach not only requires a CPU intensive calculation to be performed by the client before it even has a value, that the server can compare against the salted hash. It also provides extra security since the password and secret key never reaches the server.

It could be done all in javascript. A different login page could be provided for users without javascript. The version without javascript would then be less secure since the password is sent to the server for validation, it would also be slower, since the server probably has less spare CPU cycles than the client, and during a DoS attacks only users with javscript will be able to login. It could also be done as protocol extension, which would be even faster and even more secure, since then the client code could be native code, and the javascript code couldn't be modified to send password to the server. It is entirely possible to design in such a way that the same entry stored in the database would work with all different methods.

Of course my approaches need to be review before they are used for any real system. Until then I suggest people stick with SHA256 or SHA512.

Re:Plaintext passwords again?

[Anonymous Coward]

Everything.

Re:Plaintext passwords again?

[Grant_Watson]

The biggest problem is that those cryptographic hashes tend to be easily parallelizeable on a commercial GPU, resulting in a brute force attack many times faster than an ordinary CPU. Hashes like bcrypt are much less GPU friendly.

Re:Plaintext passwords again?

[kasperd]

The biggest problem is that those cryptographic hashes tend to be easily parallelizeable on a commercial GPU, resulting in a brute force attack many times faster than an ordinary CPU.

I still prefer that compared to the alternative of using algorithms that haven't had sufficient review. If you combine the algorithms in a construction that can be proven to be secure, then you may be on to something. For example if you passed the output of bcrypt through SHA512 together with the password, you could probably produce an actual security proof based on an accepted property of SHA512.

I guess a proof can be given for the security of storing salt||h(salt||password||f(salt||password)) with h being a cryptographic hash function with some standard property. Then plug in h=SHA512 and f=bcrypt.

Re:Plaintext passwords again?

[Anonymous Coward]

PBKDF2 is a wrapper around whatever hash function you want to use (say SHA-256 / 512, whatever). It was invented by some of the premier cryptographers in the world and has been thoroughly vetted.

That you don't know this already means you shouldn't be involved in this discussion.

Re:Plaintext passwords again?

[marcosdumay]

The solution is writting your passwords down.

We've reached a point where passwords that you can keep on memory are clearly not strong enough, by a huge margin. The best solution would be to use tokens that you carry everywhere... But that ain't gonna happen, so just write your passwords down.

Re:Plaintext passwords again?

[marcosdumay]

That's an email password. There are two kinds of accounts people must care about, banks and emails.

Now, about they leaking anyway... Yeah, it is already time to get out of Yahoo.

Re:Plaintext passwords again?

[marcosdumay]

I'd much rather use a fast hash, which has been reviewed by many cryptographers than a slow one, which has not had as much review.

That's why you should use a slow hash that has been reviewed by many people. More often than not, it consists of just a fast hash repeated several times intercalated with salting.

Re:Plaintext passwords again?

[marcosdumay]

For example if you passed the output of bcrypt through SHA512 together with the password, you could probably produce an actual security proof based on an accepted property of SHA512.

Sorry, but you don't seem to understand it. If you pass the output of bcrypt through SHA512 you'll have a hash that is weaker than either bcrypt or SHA512 alone.

Please, just use a hashing function that is suitable for passwords. Better yet if you get it in a library that takes care of encoding, algorithm updating and salting for you.

Re:Plaintext passwords again?

[kasperd]

PBKDF2 is a wrapper around whatever hash function you want to use (say SHA-256 / 512, whatever). It was invented by some of the premier cryptographers in the world and has been thoroughly vetted.

However PBKDF2 doesn't even specify how to store information in a database, which can be used for password validation. It's a password based key derivation function. That means it can be used to generate a cryptographic key from a password, the key can be used for such usages as encryption and HMAC. It is not complicated to go from a key derivation function to validating a password with a database, but it is not specified in PBKDF2 how to do so. One seemingly obvious approach for that last step is to compute an HMAC on the password itself, and store that HMAC along with the salt in the password. But is that last step secure? It isn't specified in PBKDF2 what you should do, so that part hasn't been reviewed.

I am not very worried about the usage of PBKDF2 for such purposes though, I am more concerned with the recommendation for using other methods which have had much less review. Last time I tried searching for cryptographic papers on bcrypt, I didn't succeed in finding any.

Re:Plaintext passwords again?

[kasperd]

If you pass the output of bcrypt through SHA512 you'll have a hash that is weaker than either bcrypt or SHA512 alone.

Such an extreme statement, with no evidence backing it up. Should I even be taking that serious?

There are two requirements for a hash function used for password storage. The risk that an invalid password is accepted must be small, and it must be difficult to deduce the password from the hash.

If you look carefully at what I wrote, you'll see that the only way it could possibly accept an invalid password was if a collision happened in the SHA512 step. Thus in that respect it is trivially proven that the construction is secure if SHA512 is secure. Additionally I have seen no documentation of any way in which a SHA512 hash would leak information about the input.

Finally if it was true in general that applying a hash function and then applying a hash function again would weaken the security, then iterated hashes would get less secure the more iterations you use.

Those are the reason I have not to believe what you are saying. You have not given me even one reason to believe what you just claimed.

Re:Plaintext passwords again?

[Anonymous Coward]

Blaming the negligence of the users for their own faults will not get them any where. If they know the users will not act like they want, they need to force them to or add more security on their end so weak passwords aren't as much of a problem.

Re:Plaintext passwords again?

[sh00z]

From what I see some of those yahoo passwords released aren't that trivial e.g. %5M%us$@7U

Not sure what you're looking at, but I just went to yahoo to change mine, and the only characters allowed are letters, numbers, - and _ .

Re:Plaintext passwords again?

[mpe]

What worries me is that they are not also slamming them for storing passwords in plaintext AGAIN. User passwords should not be stored anywhere on the system.

Possibly the system has (or had in the past) a requirement to be able to recover passwords.
There are also systems which do something like "Give the second, third and sixth character of the password". The easiest way to do this is to store the plaintext. Even though such systems are often touted as "secure".

Re:Plaintext passwords again?

[Anonymous Coward]

You guys, this is a silly argument.

Let's just start with advocating salted pwd hashes and leave the details to whomever, because it really isn't worth arguing over. Consider that presently, you can net 400k users in the clear, for free, using basic sql injection hacks.

It's like arguing over what mustard ingredients are shown in a lab to be best for your health when all the big vendors are still putting ketchup on hotdogs (like fucking savages).

Re:Plaintext passwords again?

[Anonymous Coward]

You can enforce good passwords. Many sites do.

But this is besides the point. Using any standard salted hash mechanism is already infinitely better than plaintext behind pitifully vulnerable sites that serve millions of people. Nobody wants to crack anything, unless (at worst) they'll likely have matches in rainbow tables.

When you're Facebook, you can worry about the very marginal benefits of one algo over the next with regard to computational expense. Nobody here needs to worry about that. Just focus on getting people not to store credentials in the clear behind shitty sites without user input sanitizing.

Re:Plaintext passwords again?

[Anonymous Coward]

Such an extreme statement, with no evidence backing it up. Should I even be taking that serious?

No, you should use it as a starting point for your own research so you can see for yourself if there is any merit. Unless of course that would take up valuable time that could be used for being condescending, that would be a real bummer.

Repeat after me: "Slashdot isn't Wikipedia". Think a claim is suspect? Great! Skepticism is a good thing. Now go to Google and do your own legwork like a big boy who doesn't need Mama to spoonfeed him anymore. If you won't do that because it's not important enough to you then stop pretending you care so much about it.

Re:Plaintext passwords again?

[isorox]

SQL injection AGAIN? There's just no damned excuse for it.

Several people have made similar comments. What worries me is that they are not also slamming them for storing passwords in plaintext AGAIN. User passwords should not be stored anywhere on the system. You store a salt and hash of the password - this is fine for login, but fairly useless for hackers should they get it.

I used to think that, (and also assume no site on earth stored plaintext passwords) until I looked it up after the linked-in decable.

A modern $200 GPU can calculate every hash for a 9 character (A-Za-z0-9) password in just over a month *

I now use a basic 12 character password, and prepend it with a site specific part which I store in a file on my laptop. This gives me a password length of 15-18 characters.

There's a few stupid sites (password must be 8-12 characters etc -- agean airlines want a numeric password, and my bank only let me have 4 friggin numbers!), but on the whole it works well. Even if you got hold of my local password, you'd still need to crack the 12-char suffix.

Unfortunately it broke down with my UK Labour Party conference applicaiton -- they emailed my password back to me in plain text! Morons that haven't got a clue, no wonder they didn't get in.

* http://mytechencounters.wordpress.com/2011/04/03/gpu-password-cracking-crack-a-windows-password-using-a-graphic-card/ et al

Re:Plaintext passwords again?

[ras]

Should I even be taking that serious?

Yes you should, because he is right. The major weakness of a hash is a collision attack. By chaining the hash's the way you have the potential for a collision attack is the sum of the parts. A better solution might be: salt||(h(salt||password) XOR f(salt||password)).

then iterated hashes would get less secure the more iterations you use.

Maybe they are. The enhanced security comes from it taking longer compute. Chaining may actually increase the chances of a collision, but at least chaining the same hash doesn't combine the weaknesses of two hashs.

You have not given me even one reason to believe what you just claimed.

Yes, he is being an arrogant prick. He comes off as more interested in demonstrating how l33t he is, not in discussing the issue at hand.

Re:Plaintext passwords again?

[Anonymous Coward]

Whoosh ...

Re:Plaintext passwords again?

[DaleSwanson]

From the article:

It is still unknown whether the passwords were retrieved in the clear text format or were decrypted by the attackers afterwards.

Its possible they were stored hashed, and simply cracked. That, however, WOULD strongly imply either no salt or a single global salt.

A quick look at the dump shows one of the passwords was: h2Kmn7WGrH4IORsDYbvL

I doubt that was hashed and cracked.

Re:Plaintext passwords again?

[Johann Lau]

That's a side of Bruce Springsteen I never heard about before! Thanks for sharing.

Re:Plaintext passwords again?

[anyanka]

Except that you don't need to find the password, just a string that has the same hash. And the chance of that depends on the hash function, not on the length of the original password.

Re:Plaintext passwords again?

[slamb]

Even if a hash was O(1) and took one clock-cycle no matter the password length, a 14+ char password will be safe for a very very long time. If you had EVERY computer in the world working on colliding your hash, to find your password, it would take decades even if they're lucky and found a way to make 500ghz graphite chips.

If you actually pick a totally random password of that length using an alphabet of (26 alphabetic + 10 numeric + 11 punctuation keys) * 2 characters/key (shift) + 1 space character = 95 practical characters, and the hash is >= 92 bits or better yet >= 184 bits so there are relatively few collisions in that search space, then that appears roughly correct. But very few people do that; the passwords are too painful to type. Password crackers work by checking a much smaller search space of likely passwords. That combinatoric implosion makes the search practical without having 10+ million of these magic 500-billion-hashes-per-second chips available.

Re:Plaintext passwords again?

[kasperd]

By chaining the hash's the way you have the potential for a collision attack is the sum of the parts.

At least that statement is easily falsifiable. Even if a collision happened in the innermost hash, then that value is going to be concatenated with the salt and password before being hashed again. Thus the combined hash can only collide if the outermost did. That means in terms of collision resistance the combination is at least as secure as the outermost hash. And the outermost hash is supposed to be one which has had sufficient review to be expected to be collision resistant.

Chaining may actually increase the chances of a collision, but at least chaining the same hash doesn't combine the weaknesses of two hashs.

The entire point of the construction is to shield you against most of the possible vulnerabilities in the innermost hash. The outermost hash is supposed to be one which is believed to be collision resistant, and the only reason you didn't use that one alone is that you feel it is too fast.

Proving the combination is collision resistant is the easy part. The hard part is to prove that given a hash you cannot compute the password without computing the entire input to the outermost hash.

He comes off as more interested in demonstrating how l33t he is

Then he failed. Anybody can make extreme statements without proof.

Re:Plaintext passwords again?

[ras]

At least that statement is easily falsifiable. Even if a collision happened in the innermost hash, then that value is going to be concatenated with the salt and password before being hashed again.

Sigh.

If the inner hash collides, then it doesn't matter what the outer hash does. In the case of a collision the outer hash will always produce the same result, because operates on the same values. The salt and password are after all constants.

Re:Plaintext passwords again?

[Fr33z0r]

I want to live in a world where a secured system is the only thing that holds login info - one server, sitting on its own behind a firewall with a single port open, running a trimmed down OS and effectively airgapped save for a barebones service listening on that one port for user/password combos from a host it trusts, when the user tries to log in, the trusted box processing the login sends the username and password to the secured service on the secured port, which simply responds with a 1 or a 0 for a hit or a miss. No possible way to slurp user details en-masse. No feasible way to even harvest a single username.

Re:Plaintext passwords again?

[Anonymous Coward]

I've got a better idea. How about changing passwords every nanosecond? That way if someone is using a computer to crack a billion passwords per second, you just have to hope the one to which you're changing it isn't the one they're checking. Of course, the natural problem with this idea is your keyboard is going to become worn out very quickly.

I think there's a few things we can do in order to reduce damage.
  If the username is the same for more than one account, don't use the same password.
  Don't use the same password for the any account which is tied to an e-mail address. If one is compromised, the other could easily be compromised.
  Don't use secret question answers which can be found out on social networking sites and the like.

Why not use stronger passwords? Start out with something simple to remember, but randomly generated. Over time, make it longer. Of course, this flies in the face of those who suggest password expiration.

Re:Plaintext passwords again?

[xkpe]

Considering there were passwords from multiple services it were probably passwords for service integration.
They still shouldn't store those tho, they should use OAuth and just store the session.

Re:Plaintext passwords again?

[hidave]

I have 265 website accounts. I'm supposed to go through and change the passwords on them every week? Are you crazy?

Re:Plaintext passwords again?

[Anonymous Coward]

The salt and password are after all constants.

FAIL!

Re:Plaintext passwords again?

[RockDoctor]

Expensive hashes are only good for weak passwords. Users shouldn't have week passwords.

And as someone who, from your tone of speech, considers themselves a uberleet, ultra-secure geek, who never uses any password that is less than 36 characters of mixed upper-case, lower-case, digits and punctuation, which passwords never use more than 3 consecutive characters that appear anywhere in a dictionary of any Latin script language, and who spends 3 hours every day solely on changing passwords on sites he visits once a month or more often ...

The fact that you make a spelling mistake in a 4-character string of symbols illustrates perfectly why "luser" level users will continue to use "password" as a password on every site they ever log onto.

Or were you trying to be funny?

Passwords link

[Anonymous Coward]

Passwords, 17MB, do not open, save as instead

http://d33ds.co.nyud.net/archive/yahoo-disclosure.txt

Not to worry...

[Anonymous Coward]

Nothing of value was lost, ask any insurance company.

how many passwords?

[Anonymous Coward]

Technically, it was around 4500 unique passwords. The remaining half million oddly enough were all "free2rhyme"...

slashdotted?

[synapse7]

Lots of sites are reporting this, and apparently enough ppl still have yahoo accounts that they care enough to change the password on, I wasn't able to login.

Re:slashdotted?

[synapse7]

I was able to get it. Is it possible to change the site to prefer SSL?

Re:TWO moronic 'Americanisms' in one sentence!

[DynamoJoe]

Hey, you're right. You're a nobody and you noticed. Attaboy, AC!

Password Recoevery

[Fls'Zen]

Maybe my 1990s-era Yahoo account password was leaked--I'll finally be able to regain access to my account!

Re:TWO moronic 'Americanisms' in one sentence!

[Runaway1956]

Is that a nice thing to say about an obsessive compulsive anal retentive person?

Unencrypted? Meaning plain text?

[Anonymous Coward]

I think the real news is Yahoo stores passwords "unencrypted", though one rarely does encryption for passwords just hashing. Maybe the story meant they are stored "unhashed" or "plain text".

And another!

[wicka_wicka]

I'm starting to think I should just not have an account anywhere. That's hyperbole, of course, but there's a new hack every week and I don't have a good enough memory to use completely unique passwords for every account.

sigh.... anyone found it yet

[TheCarp]

I did some quick looking around but, can't find a link to the actual list of accounts and passwords. Anyone found it?

Seems to me that just a few months ago, before pastebin got their panties in a bunch about password lists, it was a lot easier to check and see if your accounts are on the list.

Not even sure if mine are, or if any are that I care about, most of them, I think, have good passwords but fuck, it would be nice to know. Hell, there is no garauntee that even a good password doesn't hash to the same thing as some bad one that ends up in the rainbow tables.

Shit even just a list of accounts without the passwords would be nice...though.... it is always fun to laugh at other people's passwords. Actually, I know for a fact that my "insecure password" that I use for free throwaway websites is used by someone else because of leaks like this.

Re:sigh.... anyone found it yet

[synapse7]

The list is linked in posts above. Since yahoo sites share a common login, yahoo mail accounts would also be compromised if the user used a yahoo address to register. Users that registered iwth an address from another domain that also use the same password everywhere may also be in trouble.

Now we wait...

[hesaigo999ca]

...for the yahoo stocks to plummet until they go bankrupt.

Funny how there's no list this time.

[multicoregeneral]

Usually, when you see one of these happen, you can find a list somewhere, so you can see if you're on it. I can't seem to find the actual list this time. Does one exist?

Re:Funny how there's no list this time.

[akeeneye]

Just google "yahoo-disclosure.txt"

Re:Funny how there's no list this time.

[multicoregeneral]

Much appreciated.

Cleartext??

[ternarybit]

Sure, SQL injection shouldn't work, but it wouldn't matter as much if Yahoo hashed passwords in bcrypt or similar. Why the hell do they store cleartext passwords in a database?

BTW, the file is called yahoo-disclosure.txt.

Now maybe I can get the passwd my old account!

[Ricochet]

Dang I can't recall the last time I logged in there but I do recall that I had forgotten the password. Now maybe I can log in again. Hmm wonder what my aol, compuserve and Prodigy passwords are too?

And I don't mean Young

[Impy the Impiuos Imp]

Stickin' it to corporations is one thing, but huge numbers of people? Didja never see the end of Frankenstein?

Woosh

[michelcolman]

He was just making a joke about the phrase "Users shouldn't have week passwords".

But you are right, of course. Frequent password changes are not good for security.

Yahoo's focus is all wrong

[Anonymous Coward]

They've spent the past several years now making things AJAXy and Web 2.0 compliant. All it does is piss off longtime users like myself, who started using the service with a handful of tags and don't find much value in the AJAXy features. It *doesn't* make them cool in the eyes of potential new users.

It's not a problem unique to Yahoo; but they still need to be called out on it.

AJAX has its place. Streaming quotes are great--on a streaming quote page. They're not so hot when they are displayed on all your pages whether you were looking for quotes there or not. They absolutely suck for things like ads, stupid little FaceBook widgets, etc. Oh, and FaceBook widgets??? It's like Coke selling Pepsi. What's up with that?

If Yahoo would just quit forcing us to buy new hardware to use their pages, they might have a chance. Oh, and all those other sites out there that don't test on IE now. Too cool for IE, are we? Fuck you.

Must be those great Yahoo engineers

[Anonymous Coward]

You know, all those smarter than American H1B south Asians I see every day on the light rail near there. They sure know how to prevent SQL injections.

How many fuck are there?!

[G3ckoG33k]

Fuck! How many fucking fucks are there?! I didn't count them all but I got some 15 passwords including the four letters "fuck" per ten thousand passwords.

Hibernate?

[CosaNostra Pizza Inc]

I'm far from an expert in this area but don't certain ORM frameworks like Hibernate automatically prevent attacks through SQL injection? Though if they're storing plain-txt passwords, I doubt they're using any such frameworks.

Hmmm

[MrL0G1C]

I had a strong password "sXbi51VN" and I don't use yahoo voice and I checked out ok with the compromise database but my password was still changed! Got the account back thankfully.

Hashing?

[Tarlus]

Maybe I don't know enough about user account management, so if I am misinformed, somebody please fill me in.

Is there a reason that so many of these big-name corporations are not employing hashes? I mean, the SHA algorithms (for example) aren't exactly hard to come by so it's not like they have to reinvent the wheel. Every DBMS worth its salt has these functions built into it. Is SHA1($password) too much for them to type?

I just cannot fathom why they would ever store unobfuscated passwords...

Re:Hashing?

[FitForTheSun]

Yes, there is a reason, but it's a bad reason. The reason is that they are incompetent. I've never implemented a password-storage system in my life, and I know not to store unsalted hashes.

Actually, that's not true, I once implemented the weakest of all password schemes, and I employed a salted
MD5 hash. So I guess it wasn't quite the weakest of all.

I imported them into Excel...

[Gordo_1]

For your viewing pleasure, here are the top 20 passwords by number of occurrences in the Yahoo hacked set. Enjoy!

Password Count
123456 1673
password 804
welcome 439
ninja 333
abc123 255
123456789 226
princess 216
sunshine 213
12345678 208
qwerty 177
michael 167
writer 166
monkey 165
freedom 164
password1 162
111111 160
iloveyou 142
tigger 136
baseball 136
shadow 134

Re:I imported them into Excel...

[mianne]

I'm so glad that the password I use everywhere, "peanut", is not on that list. I must be perfectly safe then right?

Re:I imported them into Excel...

[BitterOak]

I'm so glad that the password I use everywhere, "peanut", is not on that list. I must be perfectly safe then right?

Yep. You should be. My universal password, gandalf, should be safe as well.

Re:I imported them into Excel...

[Anonymous Coward]

I imported them into Excel...

uniq -c not good enough for you?

Re:I imported them into Excel...

[glitch!]

I was halfway expecting to see "joshua" in the list, but I guess anyone who saw and remembers Wargames would not be such a dumbass to use such an obvious password.

Thanks god for mysql_escape_string and mod_sec

[detain]

Thanks god for mysql_escape_string and mod_security. Certain large companies like Yahoo you just assume they have the money and time to make sure all of there code is tight, this is pretty lame on their part.

Re:Thanks god for mysql_escape_string and mod_sec

[Anonymous Coward]

Are you sure it ist mysql_escape_string_for_real or mysql_escape_string2 or something like that? Weren't there like 5 versions that all didn't quite fully work?

Also: DON'T USE mysql_escape_string, USE PREPARED STATEMENTS AND YOU ARE IMMUNE FROM INJECTION ATTACS!

Re:Thanks god for mysql_escape_string and mod_sec

[shutdown -p now]

Surely you meant to write "mysql_real_escape_string"?

(I'm not asking if you meant to write "PDO prepared statements" - but you really should have, if you insist on working with madness that is PHP)

Re:Thanks god for mysql_escape_string and mod_sec

[detain]

yeah actually originally i was but it wouldnt fit in the subject line :P .. neither would all of mod_security.

Re:Thanks god for mysql_escape_string and mod_sec

[isorox]

Also: DON'T USE mysql_escape_string, USE PREPARED STATEMENTS AND YOU ARE IMMUNE FROM INJECTION ATTACS!

+5, far too many php zombies around the place.

That said, "select * from log where id IN (?)" doesn't tend to work with a prepared statement. At least in Java or Perl. You have to be careful, and if you're running perl obviously you're using -t.

Real, but...

[Anonymous Coward]

My Yahoo! email address is real, but not my main email address. Still, it has its uses.

I was wondering ....

[PPH]

... what little Bobby Tables was doing with his summer vacation.

OpenID?

[Galestar]

Please and thank you.

Re:OpenID?

[marcosdumay]

Yeah, Yahoo is an OpenID provider. You're welcome.

Yep, Yahoo Mail, this goes further than reported

[almechist]

I have an att.net email account which for some reason has to be accessed through Yahoo, I guess they're corporate partners or something... The point is, I have always protected my email address with religious fervor, and as a result I do not get spam, ever, period, not once. Until today, that is. Make of it what you will, but to me this is just way too much of a coincidence. I strongly suspect it will come out that the hack went deeper and compromised much more than what is currently being reported. To repeat, I have had a totally spam-free yahoo mail address for 5 years and all of a sudden today I get spam, despite the fact that my address is NOT listed in the list of compromised accounts. Make of this what you will, but personally I'm not very happy with Yahoo at the moment.

techfun89's high

[Anonymous Coward]

Uhhh, list is not removed, its actually still the first google result....