Another South Korean service provider has reported a large-scale data breach, leaking usernames and passwords for subscribers worldwide.
Late last month, cybercrooks made off with the personal information of up to 35,000,000 users of popular Korean sites Nate and Cyworld.
This time, it’s the turn of Seoul-based streaming media service GOMTV to suffer a data-spilling intrusion.
According to GOM TV, the breach happened early in the morning of Friday 12 August 2011 Korean time; the company sent out a warning email to its subscribers on Sunday 14 August 2011. That’s not exactly immediate, but it sets a much better notification standard than the week which Sony made its users wait for information after the PlayStation Network was breached in mid-April.
Dear Valued GOMTV.net users:
We regretfully inform you that approximately at 2 AM KST, Aug.12th, there has been an attack against our web site, GOMTV.net.
We have found that some of the user information from GOMTV.net has been compromised from the attack. We suspect that the following information might have been exposed: name, location (country), e-mail address, GOMTV.net nickname and password.
Payment details and credentials were not exposed, as GOM TV outsources its payment services to PayPal. Unless, of course, you used the same password for GOM TV as you did for PayPal. (You didn’t do that, did you?)
GOM TV subscribers can pick their own password for the site itself, or can authenticate against Twitter or Facebook instead. As Gretech points out in its email: “Users who have signed up with Facebook or Twitter do not have to worry about changing their passwords as they did not have to enter separate passwords at the time of sign up.”
It sounds as though Gretech was storing passwords in a directly-recoverable form on its web servers. As we’ve said many times before on Naked Security, this is almost always unnecessary for online authentication.
You don’t need to save a user’s password permanently to be able to validate it later. Instead, you calculate and store a complex cryptographic hash of the password.
If a user can subsequently provide a password which produces the same hash, you have satisifed yourself they know the password they chose originally. You need to have the password very briefly in memory, but you never need to store it .
(Of course, you need to choose a satisfactory password-hashing system. Don’t try to invent your own. Use one which is already well-known and considered secure. Good places to start are the password hashing arrangements used by OpenBSD and Linux.)
As if that weren’t bad enough, GOM TV included a bright-and-shiny Click to change button in its notification email. The button doesn’t actually take you directly to the company’s password reset page, but it nevertheless sets a risky precedent, especially as it uses an unusual-looking redirect to take you to the company’s website.
Fake warnings which urge users to click on links in the email they’ve just received are the hallmark of scammers and phishers. Avoid doing the same thing in your own alerts: this discourages users from entering confidential data on web pages they have reached via uncertain links embedded in email.