As We Speak, Teen Social Site Is Leaking Millions Of Plaintext Passwords (arstechnica.com) 126
Dan Goodin, reporting for ArsTechnica: A social hangout website for teenage girls has sprung a leak that's exposing plaintext passwords protecting as many as 5.5 million user accounts. As this post went live, all attempts to get the leak plugged had failed. Operators of i-Dressup didn't respond to messages sent by Ars informing them that a hacker has already downloaded more than 2.2 million of the improperly stored account credentials. The hacker said it took him about three weeks to obtain the cache and that there's nothing stopping him or others from downloading the entire database of slightly more than 5.5 million entries. The hacker said he acquired the e-mail addresses and passwords by using a SQL injection attack that exploited vulnerabilities in the i-Dressup website. The hacker provided the 2.2 million account credentials both to Ars and breach notification service Have I Been Pwned?. By plugging randomly selected e-mail addresses into the forgotten password section of i-Dressup, both Ars and Have I Been Pwned? principal Troy Hunt found that they all were used to register accounts on the site. Ars then used the contact us page on i-Dressup to privately notify operators of the vulnerability, but more than five days later, no one has responded and the bug remains unfixed.
Exposing those who store plaintext passwords (Score:1)
Re: (Score:2)
Is there anything short of hacking them that will get their attention?
Slashdot them. And bringing their site to its knees will also stop it leaking passwords so quickly.
Re: (Score:2)
There are a few companies that might respond, but generally the answer is no. Because they have legal resources to threaten you. For exposing their lack of security. Cheaper for them to lawyer up than secure up.
Re: (Score:3)
There are a few companies that might respond, but generally the answer is no. Because they have legal resources to threaten you. For exposing their lack of security. Cheaper for them to lawyer up than secure up.
It's kind of hard to get those "legal resources" to work for you when they suddenly discover you have no revenue left to pay them, due to an incessant stream of constant and successful hacking.
By not addressing security, at some point you'll either run out of customers or money. Either way means death in business unless you're smart enough to respect all of the risks to prevent a premature demise.
Re: (Score:2)
That's not really how it works in the real world.
Re: (Score:2)
I'd bet Ashley Maddisons subscriber count is way down.
Re: (Score:1)
There’s a difference between exposing a lack of security and hacking.
For example, I once found a site that sent me my plaintext password in an email. After receiving no response, I reported the site (which had a local, physical presence) to my Attorney General. I argued that the site’s Privacy Policy said they would take reasonable steps to protect my information, and sending out my password as unencrypted plaintext fell short of that standard. I also argued that they should follow a generall
Re: (Score:2)
They won't do anything unless something has immediate financial consequences. And even when they are hacked, they cry about being the victim and how hackers cost them millions of dollars. They need to be told: No, not spending a few thousand dollars on regular audits is why you lost millions of dollars.
Re: (Score:2)
They need to be found guilty of gross negligence and sent to prison. Before that happens, nothing will change.
Re: (Score:2)
I don't think much will happen, considering business executives don't go to prison for knowingly putting tainted water into the pipes or leaking gas into people's homes. Leaking passwords seems like a minor thing, maybe if the banks and credit companies got tired of paying, but I suspect those guys have figured out a way to pass the costs onto customers or the individual account holders.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
It's a pity... (Score:5, Funny)
It's a pity that they didn't enroll little Bobby Tables [xkcd.com] in that website. That would have taught them to sanitize their SQL input.
Re:It's a pity... (Score:4, Insightful)
The real problem was not SQL vulnerabilities. Plain text passwords should never be transmitted to servers. They should be salted and hashed on the client. It should have been clear to anyone that bothered to look at the data being transmitted that this website had major security problems and was developed by clueless amateurs.
Re:It's a pity... (Score:5, Insightful)
Re: (Score:2)
So then the hash becomes a plain text password?....
... except that it is not plain text because it is salted and hashed, so even if it is later compromised, it is useless for logging into other sites.
If you transmit the plain text password to the server before hashing, you are open to multiple vulnerabilities. It is vulnerable in transit, it is vulnerable to memory side attacks on the server, it is vulnerable to VM compromises if it is swapped to disk, it is vulnerable to compromised software on your server, and it is vulnerable to disloyal employees. And
Re: (Score:2)
HTTP has had this forever: challenge/response authentication. There's one problem with it though: it requires storing the plaintext password on the server so it can be used to encrypt the challenge to check against the client's response. I don't know of any challenge/response algorithm that works with one-way hashes of passwords.
Re: (Score:2)
There's one problem with it though: it requires storing the plaintext password on the server
No it doesn't. You can store a salted hash and then perform the challenge/response against a regenerated hash on the client.
I don't know of any challenge/response algorithm that works with one-way hashes of passwords.
I don't know of any that don't. Why would an algorithm care if the "password" was plaintext or a hash?
Re: (Score:2)
And how, please tell us, are you supposed to do that login without sending the salted hash? And how do you do that salting and hashing on the client in the first place? Push some code to the client? Not smart at all.
Re: (Score:2)
And how, please tell us, are you supposed to do that login without sending the salted hash?
And how, please tells us, would it be better, in any way, to send the plaintext password instead?
Push some code to the client? Not smart at all.
The entire web is based on servers sending stuff to clients. How is sending code over HTTPS any less secure than sending plaintext passwords?
Re: (Score:2)
Indeed. Some people are really clueless. No, the plaintext-passwords can be sent, but the need to be sent over a secured channel and they need to never be stored and erased immediately after comparison.
Incidentally, unless you iterate the hash an appropriate number of times (say at least 100'000 times at the moment, but better use pbkdf2 or far better Argon2 with a similar number of iterations) you will still be insecure.
Re: (Score:2)
No, the plaintext-passwords can be sent
But there is no reason to send them. You are just exposing yourself and your user to unnecessary extra vulnerabilities.
... and erased immediately after comparison.
How do you ensure they are "erased" from your VM backing store, or the kernel cache, or memory that has just been reallocated to another instance owned by another company?
Re: (Score:3)
1. There is also no reason not to send them, as anything you can send instead does not provide any benefit.
2. Please read up on this. This is a solved problem.
Re: (Score:2)
I am not convinced that helps, because suddenly you have pretty complex crypto on the user's side and that may just leak the passwords as well. Especially as passwords handled right on the server side no _not_ leak.
I do agree that the state of web-application security is a very sad one, but this is an attempt to fix the wrong problem.
Re: (Score:3)
Re: (Score:2)
Indeed. Of course you should store the password salted and hashed a few 100'000 times on the server (better do it right and use pbkdf2 or Argon2) and you should dispose of that plain-text password immediately after you have compared it.
Re: (Score:3)
Sending the plain text password to the server is the way to go
There is no advantage in doing that, and many disadvantages.
since you can't and should not trust the client to do any cryptographic work for you with it.
Hashing on the client is an additional level of security, not a replacement for existing levels, so no extra "trust" is required.
But what you SHOULD do for sure is use HTTPS...
Yes. Duh.
then it doesn't matter that it's plain text, using HTTPS will be your encryption for sending it over the network.
HTTPS only protects you during transmission It does not protect you from server side attacks or from dishonest/incompetent employees.
Chrome has started flagging pages that have login forms submitting to HTTP to notify users the page is not secure. Good move.
Yes, that is a good move. The next step would be to warn users if their just typed password is being transmitted in plaintext. That would encourage best practices, and would hav
Re: (Score:2)
if somebody grabs a copy of it from the server they can still log in by sending that as the salted-crypted password.
Only if you use single-factor-auth. If you use a known-client cookie as a second factor, this problem goes away. If the user is logging in from an unknown client, then you ask a security question or send a code to their registered cellphone, or whatever.
Proper security is done in depth. Each level needs to be reasonably secure without compromising convenience. Client-side hashing is not a panacea that solves everything, but it is a simple common sense step that adds an extra layer of security.
Re: (Score:2)
this is moot if you use a secure channel and appropriately salt the password on the server.
... and your system is absolutely perfectly secure in every other possible way, and all your employees are perfectly competent, and their loyalty has been guaranteed by Suk Imperial Conditioning.
The resultant hash *is* effectively your password and is just as susceptible to password leaks via weak encryption or bad caching practices.
... except the consequences of that leak are less severe because it is worthless for attacking other systems. It doesn't make your site more secure, but it makes your users more secure, and it makes us all collectively more secure.
DO NOT STORE THE PASSWORD ON THE SERVER!!! This, of course, includes caches.
How many PHP back end coders know how to clear a kernel cache?
Private industry doing it better than government (Score:2, Insightful)
Yeah, private industry is so great compared to government.
Re: (Score:2)
Re: (Score:3)
I am guessing.... just making a wild stab in the dark here... that these account credentials are the most valuable of all. They belong to a group of people who likely have accounts all over the place all using the same credentials and no 2FA.
Re: (Score:2)
Re: (Score:2)
I was thinking spammers.... but ok....
Re: (Score:3)
Teens also have credit cards, 976 number redialing, botnet possibilities.
In spite of BarbarHudson's ignorance, anything at this scale is very valuable.
Re: (Score:2)
Re: (Score:2)
"If"
Guess what?
The real world is that they HAVE credit cards, debit cards, phones, cars, money, drugs, sex.
Move on to the real world.
Re: (Score:2)
Now that's funny.
Re: (Score:2)
Re: (Score:2)
Who knows? Never been sequenced, probably never will be. Of course, if I were really desperate, I'd just get a bone marrow transplant from a woman and blood tests would then show female, but it doesn't matter, because in the eyes of the law (including the bathroom bill laws) it's what's on your birth certificate that counts, and mine now says female.
Also, the law is unenforceable. They can't just demand to see people's birth certificates because they are suspicious - the US Supreme Court has said that prof
Re: (Score:2)
Re: (Score:2)
This also covers teens who have jobs and their own bank accounts...
Re: (Score:2)
Re: (Score:2)
I don't have any daughters but I have 6 nieces that are 15 to 34 yrs old and two of them still watch Disney shows and little kid cartoons like Dora the Explorer. I wouldn't be surprised if they were into i-dressup also and that's a 22 and 27yr old.
Re:Private industry doing it better than governmen (Score:5, Insightful)
None of this is of any value if you don't give your kids access to your credit card.
My 16 year old daughter has had her own card since she was 10.
And if you do, then you're already exposed to bigger threats.
Like kids who have learned responsibility and basic financial management? Just make sure the limit is low, and let kids make mistakes and learn from them. Your kids won't grow up to be capable and responsible adults if you shelter them from reality and make every decision for them.
Re: (Score:2)
Re: (Score:2)
Your SIG:
Are you saying Frankenferter is not a transexual?
Re: (Score:2)
Are you saying Frankenferter is not a transexual?
He's from Transsexual, but actually just a sweet transvestite.
Re: (Score:1)
Pretty sure they are both doing a crap job at securing sensitive data. The good thing about private industry is that there are laws penalizing them for this kind of behavior, and they can also be sued. For all intents and purposes it is impossible to sue the federal government so there is very little accountability.
Re: (Score:2)
The good thing about private industry is that there are laws penalizing them for this kind of behavior
And how often has anyone received a meaningful punishment for this sort of thing? That would be somewhere close to . . . never.
and they can also be sued.
And how often has anyone been successfully sued over this sort of thing? See the answer to the question above.
Re: (Score:1, Insightful)
Hogwash. Target settled with a $10 million payout: $10K per affected person. $10 million is less than the compensation package for Brian Cornell, CEO of Target, in 2015. That "penalty" barely ranks as an itch on the Target balance sheet.
Home Depot settled for $19.5 million. A bit better but nothing to write home about.
Penalties are supposed to hurt. They are supposed to be designed to ei
you forgot the sarcasm tag. (Score:1)
Re: (Score:2)
So when do the forced Yahoo password changes start?
Re: (Score:2)
The difference being that neither yahoo nor idressup can legally use guys with guns to force me to register on their websites (and that's what it would take, for those two at least).
Re: (Score:2)
Re: (Score:1)
Let me tell you about my SSN, and PII being lost/exposed/incorrectly released by government employees. Multiple times, multiple agencies.
Re: (Score:1)
Ah yes... (Score:5, Funny)
The old SQL injection attack.... been around since the beginning of forever but will web devs ever learn to take simple steps to protect their SQL backends? newp...
Let's make sure we never sanitize HTML and never parameterize our SQL queries... that would just be like soooo neckbeard....
Re: (Score:3, Insightful)
How about not storing passwords in plaintext? That way, simple attack, or more sophisticated attack, you're not just handing them credentials carte blanche....
Re: (Score:2)
Of course... they all go hand in hand.
An SQL injection attack is the easiest thing to close the loop on though. It is the low hanging fruit of security. At least start with that... then we can talk encryption...
Re: (Score:3)
Or hashing.
SQL injectable website, passwords in plain text...I'm sure there's a third "security best practice" that's not being followed.
I mean, geez, plain text passwords hasn't been in on any "industry best practice" since never. If there's any reason to make yourself completely vulnerable to being sued, this would be it.
Re: (Score:2)
I bet one of the accounts on there is a test account for the developer to test with in production, and the username/password is the same as the password to the FTP server or to the DNS registry or some other important service.
Re: (Score:2)
Maybe there is a secret society that is dedicated to keeping old vulnerabilities alive. Would explain why the same tired old mistakes are made time and again.
full destruction (Score:1)
Re: (Score:2)
No, that's not what responsible disclosure is.
In the eternal words of Grumpy Cat... (Score:2)
GOOD.