Slashdot Mirror

← Back to Stories (view on slashdot.org)

As We Speak, Teen Social Site Is Leaking Millions Of Plaintext Passwords (arstechnica.com)

Posted by msmash on from the security-woes dept.

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.

126 comments

  1. Exposing those who store plaintext passwords by Anonymous Coward · · Score: 1

    I've tried being nice, writing to CIOs and CISOs to let them know of their security lapses, but they rarely do anything. Is there anything short of hacking them that will get their attention?

    1. Re:Exposing those who store plaintext passwords by infolation · · Score: 1

      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.

    2. Re:Exposing those who store plaintext passwords by NatasRevol · · Score: 1

      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.

      --
      There are two types of people in the world: Those who crave closure
    3. Re:Exposing those who store plaintext passwords by geekmux · · 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.

      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.

    4. Re:Exposing those who store plaintext passwords by NatasRevol · · Score: 1

      That's not really how it works in the real world.

      --
      There are two types of people in the world: Those who crave closure
    5. Re:Exposing those who store plaintext passwords by OrangeTide · · Score: 1

      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.

      --
      “Common sense is not so common.” — Voltaire
    6. Re:Exposing those who store plaintext passwords by Anonymous Coward · · Score: 0

      Not enough people use /. to /. anyone anymore. Even a piece of shit node.js site on a $10 VPS can keep up with the traffic we generate.

    7. Re:Exposing those who store plaintext passwords by sg_oneill · · Score: 1

      That's not really how it works in the real world.

      I'd bet Ashley Maddisons subscriber count is way down.

      --
      Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
    8. Re:Exposing those who store plaintext passwords by Anonymous Coward · · Score: 0

      In some countries you can set specialized police-units on them, specifically countries with strong privacy laws.

    9. Re:Exposing those who store plaintext passwords by gweihir · · Score: 1

      They need to be found guilty of gross negligence and sent to prison. Before that happens, nothing will change.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    10. Re: Exposing those who store plaintext passwords by Anonymous Coward · · Score: 0

      Why is hacking them even an option? What does that even accomplish aside from boosting your own ego.

      Publish and submit articles. Make people aware. That's what you should be doing if you feel that passionate about it.

    11. Re:Exposing those who store plaintext passwords by OrangeTide · · Score: 1

      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.

      --
      “Common sense is not so common.” — Voltaire
    12. Re:Exposing those who store plaintext passwords by arglebargle_xiv · · Score: 1

      It's not so bad, fully 50% of the users were actually FBI agents pretending to be 14-year-old girls. The remaining 99.999% were guys pretending to be teenage girls. The one genuine girl on the site has said she's not too fussed since she didn't use it that much anyway, it was too full of FBI agents and guys.

    13. Re:Exposing those who store plaintext passwords by Anonymous Coward · · Score: 0

      I've tried being nice, writing to CIOs and CISOs to let them know of their security lapses, but they rarely do anything. Is there anything short of hacking them that will get their attention?

      Totally!

    14. Re:Exposing those who store plaintext passwords by TheRaven64 · · Score: 1

      Make sure that you let them know that, because you have gone through responsible disclosure, if they are compromised then you will happily testify in court that they were aware of the insecurity of the personal information and that this makes them liable for increased damages for any compromise resulting in a failure to address the issue in a number of jurisdictions.

      --
      I am TheRaven on Soylent News
    15. Re:Exposing those who store plaintext passwords by kc7rad · · Score: 1

      IMHO you will get nowhere contacting CIOs and CFOs. Do a little poking and contact the network admins or engineers. Have done that a few times and generally received thanks (and a few t-shirts and mousepads).

    16. Re:Exposing those who store plaintext passwords by TechnoJoe · · 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 generally accepted security practice, like PBKDF2 as an example.

      The AG letter got the site to respond. They specifically refuted the need to store the passwords according to any generally accepted standard, saying there was no law requiring them to. However, I got them to stop sending out unencrypted passwords in plaintext.

      You might think this is a hollow victory, but the victory comes if/when the site is hacked. If hacked, and if someone sues the site over the hack, the site’s refusal to implement generally accepted password encryption will show up during discovery. It will be very damaging to their case, and it may even make the case eligible for punitive damages.

      Given an uncooperative/hostile site, I think this is the best anyone can do.

  2. It's a pity... by OpenSourced · · Score: 4, Funny

    It's a pity that they didn't enroll little Bobby Tables in that website. That would have taught them to sanitize their SQL input.

    --
    Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
    1. Re:It's a pity... by ShanghaiBill · · Score: 3, 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.

    2. Re:It's a pity... by KFK2 · · Score: 4, Insightful

      So then the hash becomes a plain text password?....

    3. Re:It's a pity... by Anonymous Coward · · Score: 0

      Salting and hashing on the client just means you're sending a different plaintext password to the server. Granted, it might be harder to guess ("1234" is going to salt/hash to something like "aajejfe823adj1283" or whatever, but if somebody grabs a copy of it from the server they can still log in by sending that as the salted-crypted password.

    4. Re:It's a pity... by Anonymous Coward · · Score: 0

      You should use trusted methods for password handling and not make up your own schemes that seem secure to you.

      Passwords SHOULD be sent to the server, but over an encrypted channel. There is no real security value in salting and hashing on the client as you say. There is the potential that you have obscured the password that the user may be using on other sites, but this is moot if you use a secure channel and appropriately salt the password on the server.

      All you are doing when you do the salting and hashing on the client is changing the 'real' password from 'password' to hash('password'+'salt'). The resultant hash *is* effectively your password and is just as susceptible to password leaks via weak encryption or bad caching practices.

      The real problem in this instance (I did not RTFA yet so this is just based on the summary text) is DO NOT STORE THE PASSWORD ON THE SERVER!!! This, of course, includes caches.

    5. Re:It's a pity... by Anonymous Coward · · Score: 0

      passwords .. should be salted and hashed on the client.

      Nobody does that. There are some systems that try to avoid sending a password over the wire (e.g. SRP), but they aren't widely implemented.

      Most of the time, we depend on https to keep passwords secure.

    6. Re:It's a pity... by The+MAZZTer · · Score: 2

      Yup. Sending the plain text password to the server is the way to go, since you can't and should not trust the client to do any cryptographic work for you with it. But what you SHOULD do for sure is use HTTPS... then it doesn't matter that it's plain text, using HTTPS will be your encryption for sending it over the network. Chrome has started flagging pages that have login forms submitting to HTTP to notify users the page is not secure. Good move.

    7. Re:It's a pity... by ShanghaiBill · · Score: 1

      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 all of that is even if neither you nor any of your employees are stupid enough to actually store it in a DB.

      Plain text passwords should never leave the client.

    8. Re:It's a pity... by Anonymous Coward · · Score: 0

      Right, you need to transmit the plain-text password to the server with encryption, then they salt/hash and compare.

    9. Re:It's a pity... by Anonymous Coward · · Score: 0

      Nobody does this, but maybe they should. The memory side-attacks and honesty of the backend developers are real risks here.

      Some may argue that it's still open to attack by the front-end developers and, of course it is. But why not reduce the attack surface if possible. Sure this means 'double' hashing and salting (So that the intermediate password - the salted hash of the original password - is not stored in plaintext on the server), but that's not that expensive these days.

    10. Re:It's a pity... by ShanghaiBill · · Score: 1

      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.

    11. Re:It's a pity... by Todd+Knarr · · Score: 1

      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.

    12. Re:It's a pity... by ShanghaiBill · · Score: 1

      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?

    13. Re:It's a pity... by Anonymous Coward · · Score: 0

      It sounds like you're talking about Digest authentication, which does *not* require storing the plaintext password, but does require storing a hash derived from that password, which is effectively an authentication token for that server. This is not great but it is not as bad as you are making it sound.

      The difference:

      - If an attacker obtains a database of Digest hashes, they can use those to impersonate any user on the server. They can also attempt to guess passwords, at a cost of one MD5 hash per guess per user.

      - If an attacker obtains a database of plaintext passwords, they can use those to impersonate any user on the server. They can also immediately compare passwords to see which users are likely the same people, attack unrelated servers where the same users might have used the same or similar passwords, look for private information like birthdays or pets' names within the passwords themselves...

      The other common HTTP authentication method, other than Digest, is Basic, which requires *transmitting* the password in plaintext but allows the server to *store* the password database in whatever (safely salted) format it prefers.

      I do not know of any widely deployed password authentication scheme that doesn't at some point require the server to be in possession of a piece of information that could later be used to impersonate the user. You could devise such a system, based on public-key crypto, but I don't know of any efforts to do so. In the end, I guess that the "Basic" approach is regarded as good enough; if an attacker is in a position to intercept plaintext passwords (that are of course being sent through an encrypted channel) then they also have the ability to do a lot more damage directly, and passwords probably aren't what you're worried about.

    14. Re:It's a pity... by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    15. Re:It's a pity... by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    16. Re:It's a pity... by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    17. Re:It's a pity... by ShanghaiBill · · Score: 1

      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?

    18. Re:It's a pity... by ShanghaiBill · · Score: 2

      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 have prevented the leak described in TFA.

    19. Re:It's a pity... by ShanghaiBill · · Score: 1

      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?

    20. Re:It's a pity... by ShanghaiBill · · Score: 1

      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?

    21. Re:It's a pity... by Anonymous Coward · · Score: 0

      I do not know of any widely deployed password authentication scheme that doesn't at some point require the server to be in possession of a piece of information that could later be used to impersonate the user. You could devise such a system, based on public-key crypto, but I don't know of any efforts to do so. In the end, I guess that the "Basic" approach is regarded as good enough; if an attacker is in a position to intercept plaintext passwords (that are of course being sent through an encrypted channel) then they also have the ability to do a lot more damage directly, and passwords probably aren't what you're worried about.

      ZKPP is commonly used where it matters (see SRP). There's even a JavaScript implementation.

    22. Re:It's a pity... by gweihir · · Score: 2

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    23. Re:It's a pity... by Anonymous Coward · · Score: 0

      Stop arguing with these people, they're idiots who don't know anything about security.

    24. Re:It's a pity... by Anonymous Coward · · Score: 0

      Nigel, is that you?

      I've had this exact argument with a developer that had implemented this in a thick client/server application with a non-encrypted channel. Needless to say, I quickly switched it to encrypted channel, plaintext password transmission with salt+ hash on the server.

      If you salt+hash on there server you're transferring the trust point to the client. If someone sniffs the hashed password off the wire or pulls it from the db, they can use a hacked client to just send the hash. In essence, you've destroyed the original password and replaced it with a different plain text password.

      If you salt+ hash on the server, the salt never needs to leave the server, and there client has no option to skip the hashing during the log in process. This means an attacker must acquire the actual password somehow rather than just the hash.

    25. Re:It's a pity... by Anonymous Coward · · Score: 0

      And how, please tells us, would it be better, in any way, to send the plaintext password instead?

      From a web browser perspective, I can see a few issues:

      1) If the client doesn't have JavaScript enabled, this scheme is doomed from the start. Those users will just be locked out (although I will concede this in itself is an *extremely* secure approach :) ). I see enough rage here about JS being such a security liability that if we are to be believe the hype, any security gained from using this scheme would be offset by the necessity of having JS enabled in the first place.
      2) The client browser would have to store their salt somewhere locally for long-term reuse (e.g. client-side cookie or maybe localstorage). This would be prone to easy loss, and consequently requiring a full password reset. Inconvenient but perhaps not a dealbreaker. Also, I've not looked into it in depth but imagine it is probably massively insecure to do so anyway (essentially akin to storing the user's password in a cookie). I suppose you could get the user to store the salt somewhere external to the browser and get them to input it again alongside their password, but, y'know... usability.
      3) How would the user share this salt easily amongst multiple browsers? Every time you sat down at a new machine you'd need to reset your password.

    26. Re:It's a pity... by Anonymous Coward · · Score: 0

      ... from dishonest/incompetent employees

      Since you're suggesting we supply the client with the hashing code, this suggestion doesn't either, really. It's vulnerable to man in the middle attacks as it's trivial to change this code on the wire to just output 'foobar' for the hashed password for every user not bother hashing at all (resulting in plaintext passwords being sent). For this reason you'd still have to salt/hash everything again on the server anyway.

      Frankly, it's not a great idea, provides limited value and ultimately is making things *less* secure as it is obfuscating the harsh truth:

      Good password policy is entirely the domain of the user and they should not be reusing the same password on different sites!

    27. Re:It's a pity... by Anonymous Coward · · Score: 0

      The server could provide the salt to the user. The salt does not have to be *secure* information. Its only purpose is to mitigate dictionary attacks against generated hashes.

    28. Re:It's a pity... by Anonymous Coward · · Score: 0

      The reason is to stop the users password being potentially leaked. A password that he may be using on other sites.

      Yes, this provides no extra security for the credentials of the site in question, but it does for the users password.

    29. Re:It's a pity... by Anonymous Coward · · Score: 0

      He's talking about hashing it on the server AND the client.

      You salt + hash on the client, this gives you an intermediary 'password' that gets sent to the server. Because it's been hashed, the password he has typed in is not at risk to being leaked by insecure encryption, server memory(cache) attacks or disloyal employees. Even accidentally - say someone is running a TCPdump on a network where they offload the TLS in the load balancer (Very common).

      Of course, this is not done INSTEAD of salting+hashing on the server. The server should treat the client-generated hash as the password and salt+hash it accordingly before storing it in the DB. Yes, a malformed client could send the intermediary hash directly, but the original password would still be secure.

      Yes, people should not use the same password on multiple sites but newsflash, they do. It's human nature. Let's try to make it a little more user-friendly rather than fuck-you-user-you're-doing-it-wrong.

    30. Re:It's a pity... by Anonymous Coward · · Score: 0

      So no more logging in unless you have Javascript enabled?

    31. Re:It's a pity... by Anonymous Coward · · Score: 0

      Of course, I meant rainbow table lookups, not dictionary attacks :)

    32. Re:It's a pity... by Anonymous Coward · · Score: 0

      And how, please tells us, would it be better, in any way, to send the plaintext password instead?

      Because if the coder isn't a complete dingbat, like you for example, the plaintext password is never stored anywhere. The hash algorithm and the salt remain secret on the server and only the result of the salted hash is stored on the server. In your scheme the transmitted password, which was hashed on the client before being transmitted, is the same one stored by the server which means that all an attacker has to do is intercept the transmission or steal the stored passwords and it's game over for you. Do us all a favor and don't write security code. It's people like you who continue to make SQL injection and bad password handling a thing because you don't know what you don't know.

    33. Re:It's a pity... by Anonymous Coward · · Score: 0

      Have you noticed how often these "web developers", who love their flavor-of-the-month Javascript, think that they're too cool for school when it comes to handling operations, even very necessary ones like security, on the server side? What's up with that? Seriously, their arrogance is astonishing.

    34. Re:It's a pity... by Anonymous Coward · · Score: 0

      You are wrong.

      The transmitted password, which was hashed on the client before being transmitted, is *NOT* the same one stored by the server. It gets hashed and salted on the server and THAT resultant hash is stored in the DB.

      However, when you send the plaintext over an encryption channel, you open up the following potential attack vectors:

      * Encryption stack vulnerabilities (And there have been plenty discovered in the SSL/TLS protocols over the last few years)
      * Unencrypted passwords in the network stack in the event of TLS offloading - a very common practice. TCPDumps by malicious employees can then reveal the user passwords for any in-traffic login requests. Also, any vulnerabilities in IPS systems coudl potentially leak passwords.
      * Unencrypted passwords in application caches. Even if the developer does not specifically use a cache, those variables that transiently hold the password for the code to compare against are not stored using magic. They use system memory. Thus, an attack on the server memory could reveal the passwords during login requests.
      * Untrustworthy employees. They could, if they liked and if they have the means to edit the code, just dump the passwords to a text file to collect user passwords. They could then try them on other sites.

      By hashing on the client first before hashing on the server, there is no risk of leaking the original users password (The one (s)he typed into the password field). As much as we would like users to follow best practice and not re-use passwords across multiple sites, they do and they always will until we have a paradigm shift in how the average non tech-savvy user considers password security.

      Of course, this method does not improve security on the site where this is implemented. As many have said, the client-generated hash can just be used directly on this site if it's leaked (using any of the methods above) - there is no escaping this either way, but now the leaked hash cannot be used to try and get into other sites used by the user.

    35. Re:It's a pity... by Anonymous Coward · · Score: 0

      Umm.. One of us is missing the point here...

      So your proposal is that when someone types in their password it is salted and hashed on the client side.. So in otherwords, a bit of Javascript executes on submit that salts and hashes what is in the password field and sends it to the server. The server takes that and stores it in the DB.

      So now from the server's perspective that salted hashed password is the plain text password. I.E., if I know the salted hash I can just post that straight to the server and login. It is as good as a (very complex) plain text password.

      But way more importantly, Javascript is obviously readable by the client. So... the javascript you send to the client to perform the salt and the hash will, obviously, need to include said salt. So now the end user and attackers know your salt... Which makes it pointless.

      And since it is Javascript, it can be modified by the client.. To change the salt or hash. MiTM to alter what is being sent to begin with which, since the backend is treating the sent password as already hashed, is as good as replacing someone's plain text password mid transport.

      That's at least how I read what you are talking about, if I am wrong please tell me as I'm very interested.

      Now how is this normally done?

      The password is sent by the client in plain text (over HTTPS, obviously). The server side takes said password, salts/hashes and stores the salted hash in the DB. Any time that user logs in in the future they send their plain text password from client to server, server side salts/hashes and compares the result to the one in the DB. Plaintext password is never stored and if the database is leaked the attackers get the salted hashes which are, hopefully, not reverseable or easily brute forced.

      Here's the very simple cheat sheet. Data coming from the client is never, ever trusted. You can do validation on the client side, but that is for end user convenience, not for security. The end user can modify your Javascript as needed. All security must be done at the server side away from the end user's ability to modify what is being executed and see what you are verifying.

    36. Re:It's a pity... by Anonymous Coward · · Score: 0

      Umm.. One of us is missing the point here...

      So your proposal is that when someone types in their password it is salted and hashed on the client side.. So in otherwords, a bit of Javascript executes on submit that salts and hashes what is in the password field and sends it to the server. The server takes that and stores it in the DB.

      Wrong. The server takes that and then salts and hashes it and puts the result of THAT in the DB.

      So now from the server's perspective that salted hashed password is the plain text password. I.E., if I know the salted hash I can just post that straight to the server and login.

      Yes

      It is as good as a (very complex) plain text password.

      Yes - Better in fact as it's incredibly unlikely that this complex plain text password is used on other websites. This is the point here.

      But way more importantly, Javascript is obviously readable by the client. So... the javascript you send to the client to perform the salt and the hash will, obviously, need to include said salt. So now the end user and attackers know your salt... Which makes it pointless.

      No. Yes everyone knows the salt, but that's OK. Salts do not need to be a secret. They just need to be different for each user on a given platform. This is to prevent rainbow tables being an effective method of finding the passwords.

      And since it is Javascript, it can be modified by the client.. To change the salt or hash. MiTM to alter what is being sent to begin with which, since the backend is treating the sent password as already hashed, is as good as replacing someone's plain text password mid transport.

      No. The backend is treating the sent (already hashed) password as a regular password, it still hashes it for the DB.

      That's at least how I read what you are talking about, if I am wrong please tell me as I'm very interested.

      Now how is this normally done?

      The password is sent by the client in plain text (over HTTPS, obviously). The server side takes said password, salts/hashes and stores the salted hash in the DB. Any time that user logs in in the future they send their plain text password from client to server, server side salts/hashes and compares the result to the one in the DB. Plaintext password is never stored and if the database is leaked the attackers get the salted hashes which are, hopefully, not reverseable or easily brute forced.

      It works the same, except by hashing it on the client first, the real plaintext password (That the user may be using on other sites) never exists in the backend infrastructure at all. With the conventional method, it has the potential to exist in many places as such:

      However, when you send the plaintext over an encrypted channel, you open up the following potential attack vectors:

      * Encryption stack vulnerabilities (And there have been plenty discovered in the SSL/TLS protocols over the last few years)
      * Unencrypted passwords in the network stack in the event of TLS offloading - a very common practice. TCPDumps by malicious employees can then reveal the user passwords for any in-traffic login requests. Also, any vulnerabilities in IPS systems coudl potentially leak passwords.
      * Unencrypted passwords in application caches. Even if the developer does not specifically use a cache, those variables that transiently hold the password for the code to compare against are not stored using magic. They use system memory. Thus, an attack on the server memory could reveal the passwords during login requests.
      * Untrustworthy employees. They could, if they liked and if they have the means to edit the code, just dump the passwords to a text file to collect user passwords. They could then try them on other sites.

      Here's the very simple cheat sheet. Data coming from the client is never, ever trust

    37. Re:It's a pity... by Anonymous Coward · · Score: 0

      roflmao you don't hash on the client

      This is security 101 stuff.

    38. Re:It's a pity... by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    39. Re:It's a pity... by Anonymous Coward · · Score: 0

      I did not know we had so many teens anywhere. Surely are we losing a few with each leak?

  3. Private industry doing it better than government by smooth+wombat · · Score: 2, Insightful

    Just last week we had the half billion accounts from Yahoo! leaked and now this website, after being notified it has a problem, leaves things in place to continue leaking credentials.

    Yeah, private industry is so great compared to government.

    --
    We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
  4. Ah yes... by The-Ixian · · 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....

    --
    My eyes reflect the stars and a smile lights up my face.
    1. Re:Ah yes... by Anonymous Coward · · 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....

    2. Re:Ah yes... by Anonymous Coward · · Score: 0

      That's Captain Neckbeard to you, sonny jim!

    3. Re:Ah yes... by The-Ixian · · Score: 1

      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...

      --
      My eyes reflect the stars and a smile lights up my face.
    4. Re:Ah yes... by tlhIngan · · Score: 2

      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...

      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.

    5. Re:Ah yes... by Qzukk · · Score: 1

      I'm sure there's a third "security best practice" that's not being followed.

      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.

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    6. Re:Ah yes... by Anonymous Coward · · Score: 0

      If Slashdot knows its users are all neckbeards, WTF am I seeing an ad for a trick to remove eye bags and wrinkles?

    7. Re:Ah yes... by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Ah yes... by Anonymous Coward · · Score: 0

      Why bother?
      Our users are stupid and even after a full 'hack' they still keep using our site. and we still keep making money.

      fuck security. that costs time and effort. and our TOS says you cant sue us anyway. so go away.

    9. Re:Ah yes... by Anonymous Coward · · Score: 0

      I'm sure there's a third "security best practice" that's not being followed.

      I'd bet money their signup confirmation email includes the password and/or their "Forgot My Password" feature emails the user their password.

    10. Re:Ah yes... by Anonymous Coward · · Score: 0

      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?

      The good ones have, but they cost too much so the CEO had the brilliant idea to outsource the whole project to Bangalore where some hack named Sandeep, who has exactly two weeks coding experience, looks up the "answer" from some cut and paste code site and throws it up without having any real idea of what he's doing. In short Sandeep knows nothing. If he even knew that he knew nothing that would be something, but he doesn't. In fact, his only virtue is that he works for dirt cheap. Of course, hacks like him are what you get when outsourcing to bottom dollar sweat shops instead of hiring competent Americans, but CEOs don't care about that until they get hacked and it's all over the news.

  5. Re:Private industry doing it better than governmen by BarbaraHudson · · Score: 1

    I-Dressup? Sounds like a cross-dresser forum. Either way, it's like the Yahoo and Ashley Madison passwords - nothing of value was lost.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  6. *sigh* by Anonymous Coward · · Score: 0

    Its almost like plaintext passwords are a well known massive no no. Who'd have thought it?

  7. Re:Private industry doing it better than governmen by LeftCoastThinker · · 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.

    --
    If you disagree, please post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like
  8. Re:Private industry doing it better than governmen by The-Ixian · · Score: 2

    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.

    --
    My eyes reflect the stars and a smile lights up my face.
  9. Teenage Girls by Anonymous Coward · · Score: 0

    I'm sure they're one-in-a-million braniacs.

    CAPTCHA: Piddle. You really can't make this shit up.

  10. Re:Private industry doing it better than governmen by BarbaraHudson · · Score: 1

    Only a perv would want to steal kiddie log-ins. Be a good way to track them down by "accidentally" leaking them.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  11. full destruction by XparXnoiaX · · Score: 1

    Full destruction of the company is the only way to stop these kinds of stupid things from happening. Plaintext passwords are negligent, have been known to be negligent for longer than the internet has existed.

    --
    Irresponsible disclosure is responsible
    1. Re:full destruction by OverlordQ · · Score: 1

      No, that's not what responsible disclosure is.

      --
      Your hair look like poop, Bob! - Wanker.
  12. Re:Private industry doing it better than governmen by The-Ixian · · Score: 1

    I was thinking spammers.... but ok....

    --
    My eyes reflect the stars and a smile lights up my face.
  13. Re:Private industry doing it better than governmen by sims+2 · · Score: 1

    So when do the forced Yahoo password changes start?

    --
    Minimum threshold fixed. Thanks!
  14. Re:Private industry doing it better than governmen by Anonymous Coward · · Score: 0

    Just last week we had the half billion accounts from Yahoo! leaked and now this website, after being notified it has a problem, leaves things in place to continue leaking credentials.

    Yeah, private industry is so great compared to government.

    Just wait till some jackass leaves his laptop or blu-ray disc(s) lying around in the back of a taxi or train.

    This also has the added problem of containing all the necessary content, without worrying about if the compromised users have changed their passwords as it's all right there; no authentication walls to worry about.

  15. Re:Private industry doing it better than governmen by Anonymous Coward · · Score: 0

    You're right, government IT gets a bad rap compared to the myriad private fails we never hear about. Then again, we rely on government to have *AND ENFORCE strong legal protections against mismanagement, fraud, etc. This means strong, reaching regulations (*which we also say are untenable) and a hungry interest in protecting the public interest (*which of course doesn't exist anywhere in actual governance.)
       

  16. Re:Sexist pig by Anonymous Coward · · Score: 0

    Well, I don't know any guys that dress up unless they have to.

  17. Re:Private industry doing it better than governmen by NatasRevol · · Score: 2

    Teens also have credit cards, 976 number redialing, botnet possibilities.

    In spite of BarbarHudson's ignorance, anything at this scale is very valuable.

    --
    There are two types of people in the world: Those who crave closure
  18. You must be THIS... by Anonymous Coward · · Score: 0

    tall/smart/age to use The Internet.

  19. Re:Private industry doing it better than governmen by rudy_wayne · · Score: 1

    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.

  20. Re:Private industry doing it better than governmen by BarbaraHudson · · Score: 1

    None of this is of any value if you don't give your kids access to your credit card. And if you do, then you're already exposed to bigger threats.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  21. Re:Sexist pig by Anonymous Coward · · Score: 0

    well guys suit up, but it's more or less the same thing anyways, just with pockets.

  22. Re:Should have used apps! by Anonymous Coward · · Score: 0

    You must be THIS stupid to use apps.

  23. Re:Private industry doing it better than governmen by Anonymous Coward · · Score: 0

    mmmm.... live underaged passwords.

  24. Re:If more of those girls wanted to be programmers by Anonymous Coward · · Score: 0

    "If more of those girls wanted to be programmers..."

    LOL . . good one!

  25. Re:Private industry doing it better than governmen by smooth+wombat · · Score: 1, Insightful

    The good thing about private industry is that there are laws penalizing them for this kind of behavior,

    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 either force or encourage better behavior. The above two examples do not fall into the category and from the look of things, nor do other penalties for data breaches.

    --
    We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
  26. In the eternal words of Grumpy Cat... by Gravis+Zero · · Score: 1

    GOOD.

    --
    Anons need not reply. Questions end with a question mark.
  27. Re:Private industry doing it better than governmen by NatasRevol · · Score: 1

    "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.

    --
    There are two types of people in the world: Those who crave closure
  28. Re:Private industry doing it better than governmen by Mycroft-X · · Score: 1

    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).

  29. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  30. you forgot the sarcasm tag. by publiclurker · · Score: 1

    wouldn't want anyone to think you were serious.

  31. Re:Private industry doing it better than governmen by pr0fessor · · Score: 1

    This also covers teens who have jobs and their own bank accounts...

  32. Re:Private industry doing it better than governmen by ShanghaiBill · · Score: 4, 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.

  33. Re:Private industry doing it better than governmen by HornWumpus · · Score: 1

    Your SIG:

    Are you saying Frankenferter is not a transexual?

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  34. You might want to double check that... by Anonymous Coward · · Score: 0

    > And how often has anyone received a meaningful punishment for this sort of thing? That would be somewhere close to . . . never.

    Depends, if they're subject to HIPAA or PCI laws, then there are large fines.

    For a dressup site? I doubt they're subject to much of anything, save that they might be bad if they're collecting data on children under 13.

    That said, people should still worry because too many people are bad about reusing passwords and the usernames & passwords stolen from here will be used to search for and attack accounts on other sites.

  35. The Real Question by Anonymous Coward · · Score: 0

    Does the leak also indicate which of them will put out and are easy lays?

    1. Re:The Real Question by Anonymous Coward · · Score: 0

      As we keep on talking, they keep on leaking.

  36. Re: Should have used apps! by Anonymous Coward · · Score: 0

    Natalie Portman's hot grits was a better /. meme.

  37. Passwords for Teenage girls? Giddiddy, giddiddy by Anonymous Coward · · Score: 0

    Oh!!! Giddiddy, Giddiddy, goo. All right!.

  38. ROFLCOPTER by Anonymous Coward · · Score: 0

    It goes without saying that a man pretending to be a woman has no interest in moving on the the real world.

    1. Re:ROFLCOPTER by NatasRevol · · Score: 1

      Now that's funny.

      --
      There are two types of people in the world: Those who crave closure
    2. Re:ROFLCOPTER by Anonymous Coward · · Score: 0

      Good thing she's not. But I'm not even going to bother to log in to explain it anymore, because I'm sick of willful ignorance. Instead, this is yet another great reason to vote Clinton!

      Remember when you vote, you're exercising political authority. That means you're using violence. Come at me bro.

    3. Re:ROFLCOPTER by BarbaraHudson · · Score: 1

      Too ban that the law, my birth certificate, my ID, and my doctors all disagree with you. I'll take educated specialists over some know-nothing internet troll.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    4. Re:ROFLCOPTER by Anonymous Coward · · Score: 0

      How about Your genome?

    5. Re:ROFLCOPTER by BarbaraHudson · · Score: 1

      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 profiling is illegal when trying to enforce a law. So unless you're ready to check everyone's birth cert (and who the hell carries one around with them anyway), you're open to a federal law suit, doesn't matter what the state law says. So saith the Supreme Court :-)

      Must suck to be on the wrong side of the law.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  39. Re:If more of those girls wanted to be programmers by Anonymous Coward · · Score: 0

    iknorite. Too bad it triggered some sjw and they gave it -1.

  40. Re:Private industry doing it better than governmen by Mal-2 · · Score: 1

    Are you saying Frankenferter is not a transexual?

    He's from Transsexual, but actually just a sweet transvestite.

    --
    How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
  41. Re:Private industry doing it better than governmen by BarbaraHudson · · Score: 1

    Then the people who have unreal expectations of how benign the real world is will learn the hard way. That's how people learn in the real world - by experience.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  42. Re:Private industry doing it better than governmen by BarbaraHudson · · Score: 1

    Kids who have their own bank accounts and jobs wouldn't be on a site that caters to tweens (kids between 8 and 12). It's a site built around a flash game where kids can dress up their i-dolls and save them. and make stamps. teen-agers wouldn't be caught dead there.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
  43. A crazy idea by Anonymous Coward · · Score: 0

    A crazy idea: maybe some could go by their office ( apparently a suburban house in San Jose) and knock on their door?

    I know, I know, it's means going outdoors, and it's not nearly as cool as white hat hacking to bring the site down, buts it's a "reach out" that Ars and the other site didn't mention trying.

  44. This is it by Anonymous Coward · · Score: 0

    ... leak that's exposing plaintext passwords ...

    So this is what happens when children learn to code. Just because they can't see what's on the inter-tubes, doesn't mean everyone else is blind. That everyone can see plain-text is obvious and thus a really, really, really dumb idea. The unspoken point is the so-called web-developers haven't bothered to use the simplest security measure, HTTPS.

    The subscribers are so mindless they don't check the padlock icon and so young they don't ask "Who's getting screwed?".

  45. Re:Private industry doing it better than governmen by houghi · · Score: 1

    Your kids won't grow up to be capable and responsible adults if you shelter them from reality and make every decision for them.

    This is so true. Know a girl that was "protected" by her parents. She was not even allowed to play with any other kids. Then at 18 she was an adult and was aset free. Within 2 months she was known as the school slut.

    --
    Don't fight for your country, if your country does not fight for you.
  46. Re:Private industry doing it better than governmen by Anonymous Coward · · Score: 0

    Within 2 months she was known as the school slut.

    You say that like it's a bad thing.

  47. Re:Private industry doing it better than governmen by r2rknot · · Score: 1

    Let me tell you about my SSN, and PII being lost/exposed/incorrectly released by government employees. Multiple times, multiple agencies.

    --
    "...whenever any Form of Government becomes destructive...it is the Right of the People to alter or to abolish it..."
  48. Re:Private industry doing it better than governmen by pr0fessor · · Score: 1

    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.

  49. Re:Private industry doing it better than governmen by operagost · · Score: 1

    You just discovered that there are incompetent IT professionals in both the public and private sector. Congratulations.

    --

    Gamingmuseum.com: Give your 3D accelerator a rest.