Hack of Cupid Media dating website exposes 42 million plaintext passwords

http://arstechnica.com/security/2013/11/hack-of-cupid-media-dating-website-exposes-42-million-plaintext-passwords/

by fmavituna • 13 years ago

181 166 13 years ago

arstechnica.com

ibsathish• 13 years ago

Still in web 0.0 storing passwords in plain text? Awful.

MattBearman• 13 years ago

I can't get my head around how this still happens.

I few years back I took over development of an old PHP website, which had a horrible code base (no framework or library, not even MVC). This site had around 30,000 users, all with plain text passwords.

It took me all of a couple of hours to get the site using bcrypt.

I'm not saying I'm some kind of super-rock-ninja-star developer, just that this is so easy to fix, even on monstrosity, legacy code bases.

There really is no excuse.

mattmanser2• 13 years ago

Because of this:

If a site is using plaintext password often the owner asked for it. They wanted their users to be able to recover their passwords. And the dev didn't understand why this was a bad idea. They need to be educated, convinced and then convinced that the time you're about to spend on fixing this is more important than the 101 other things going wrong because the original dev wasn't very good. And isn't actually causing a single problem right now.

That also means that the password recovery function uses this code. Maybe there's an auto-user generator when you sign up for the newsletter. The email system obviously also uses that code. That also sometimes even means the password is stored twice, once in the framework's user mgmt tables and once in a user or person or the tblPRSN_UPDATED_OPTIMIZED_mc table. And just deleting that column might cause all sorts of other problems. Setting it null might cause bugs. Setting it empty string might cause a massive security hole as there's a login mechanism you haven't even found yet. (remember the dropbox breach?)

It's never a 3 hour job to fix unless you're very bad at estimating, are working on something extremely trivial or do a half-ass job, potentially introducing a far worse security hole.

jiggy20115• 13 years ago

It's quite possible the dev knew it was a bad idea and maybe even argued against it but was told to implement it this way anyway.

The problem a dating site probably has is people who sign up accounts and then stop using them. They want to send these users reminder emails in the hope that some of them re-engage.

Problem is that some of these users have probably forgotten which password they use for that website, and some % of those will not bother using the password reset mechanism.

So someone in marketing has the bright idea of sending emails that include the username/password combo, the dev explains why this is a terrible idea and then gets overruled.

Keyframe• 13 years ago

Most of the times I think it's due to owner and/or developer wanting to harvest passwords. I've seen it happen.

ohwp• 13 years ago

Well they were lucky you fixed it.

There are loads of sites built year ago that just work so nobody is looking into the code base ever.

wikwocket• 13 years ago

Sure, it's not hard to use bcrypt for passwords. It's also not hard to make your login forms use https, or to do weekly backups, or to use source control, or to keep Wordpress up to date. Yet many many websites/apps/companies do not get these right.

The barrier is not difficulty. The barriers are lack of time to spend on infrastructure/security improvements, lack of motivation, and distraction due to new feature requests.

Of course forgoing these things will bite you in the end, but this is the internet age; people don't tend to plan that far in advance.

mfkp• 13 years ago

Had to look it up - unrelated to okcupid. For those interested, here's a list of their web properties: http://www.cupidmedia.com/services.cfm

onion2k• 13 years ago

Ironically, one of their sites is "OnlineDatingSafetyTips.com".

nyrina• 13 years ago

I don't think that is the kind of safety they are talking about

matthuggins• 13 years ago

Pretty sure it's not ironic since dating safety != system security.

jaynos• 13 years ago

Two thoughts: 1. Thanks for the tip. I came to commetns mainly to see if I needed to change my okcupid password.

2. There are a lot of specialty dating sites out there.

jwcrux• 13 years ago

.cfm

Looks like coldfusion to me, which has had a host of vulnerabilities pop-up in the past couple years. Wouldn't be surprised if that was an easy entry point.

stfu• 13 years ago

Just a random question: Is there anything that gives companies incentive to prevent such hacks? It seems that there is no consequences at all, except for some loss of reputation in tech community. Is there a way to put legal pressure on tightening up security?

mogrim• 13 years ago

That's pretty much country dependent, local legislation on data protection varies. (And even then AFAIK is limited to sensitive data, such as race/religion/banking, not the password to some website...)

l0gicpath• 13 years ago

You are looking at necessity products built by large corporations whose products are usually regarded as the best of breed in the market.

If you are a designer for instance, you'll most likely come to depend on Adobe Photoshop. That means at some point you've created an account. Adobe got breached and your data got leaked, you'll likely whine a little about it online but unless you are willing to:

- shift your work and relearn a new tool than Photoshop

- navigate your way around closing your account (with the assumption that your data is actually deleted after account closure) which is rather hard in most cases, no one likes losing users.

Then you'll likely just suck it up, do what you can and hope for the best.

On the other hand, you got small time (but growing - not web-scale yet-) services/products that can't really afford losing a large number of users. Those would worry most about security. Ironically, they'd stay off the grid for long enough and wont become attack targets until they make it big.

But that's just really the security industry, no system is 100% secure. And you never know if you've tightened your security enough until someone drills a hole. Then you patch it.

Any self respecting corporate will have a security auditing policy. The so called white-hat hackers or pen-testers. Good companies will run security audits every now and then in hope to discover new security holes introduced by software updates, system policy changes...etc.

As for legal pressure, it depends on what we are talking about. If you are a payment processing company then any data breach is a violation of your PCI compliance, which leads to a lot of bad PR and legal consequences.

If Facebook got breached and data was exposed, I doubt there is anything in the law that reacts to such issue. Unless someone sues Facebook for damages, then that's a whole different ball game.

The incentives are there for any business of all sizes. Legally? It depends. It's those schmucks that screw us all, plaintext passwords and shit.

Edit: Fixed formatting.

rmc2• 13 years ago

In the European Union we have the Data Protection Directive, which means that organisations that store personal data are legally required to protect that data.

aestra5• 13 years ago

I often wonder, when there is a massive password breach if anyone outside the tech world even really knows about it, even if they are affected by the breach.

I mean most people don't really understand about web security or computers right? So if their email gets "hacked" they think "hackers" magically get access to their computer/email/etc. and Adobe, etc. isn't at fault.

markdown4• 13 years ago

This is getting ridiculous.

When are we going to see legislation enacted to take these people to task?

Surely there is a case to be made that their negligence causes (or has the potential to cause) real harm to their users.

We need a Saul Goodman to put together a class action.

camus2• 13 years ago

When are we going to see legislation enacted to take these people to task?

And how would you enforce this ? mandated paid audits provided by companies that have lobbyists and friends in Washington ? Enough with the laws, laws are not an answer to every problems. If there is harm , let the users sue, but stop with your laws...

bruceboughton• 13 years ago

Pro-active enforcement is not always necessary. The possibility of a large fine if found in breach of the law is usually enough for responsible companies to take the matter seriously.

Of course, you also need guidelines for implementation.

markdown4• 13 years ago

And how would you enforce this ? ... mandated paid audits

No, that would be quite silly and wouldn't work.

It could simply be reactive rather than proactive. When an incident occurs where sensitive user data is exposed, simply launch an investigation into whether there were "adequate" protections in place. If it is found that sensitive data was stored unencrypted, for example, put the directors of the company behind bars for negligence.

I'm dreaming of course. Steal a loaf of bread, life in jail without parole. Expose the private data of millions... have a strong whisky, put out a press release, head to the golf course.

danenania2• 13 years ago

Yes, the government would surely do a great job legislating development standards. Just look how terrifically they've handled software patents.

TomGullen• 13 years ago

Free markets currently doing a pretty awful job of it as we keep learning. Perhaps some government legislation would help.

markdown4• 13 years ago

Who are you responding to? It can't have been me, because I didn't say anything about the government legislating development standards.

possibilistic• 13 years ago

I agree that there should be legislation against saving plaintext passwords. Otherwise there is no repercussion for these kind of parties that put confidential information at risk.

Honestly, people are not going to change their password habits, i.e. we can't expect users not to reuse the same password at different sites. Moreover, I would wager that most people trust that websites are inherently secure and that password-related functions are safe.

The party to blame, then, is squarely the website that allows the leak of unhashed, unsalted passwords.

I believe we should seek legislation similar to HIPAA wherein the damages are inversely proportional to the ignorance and mitigation preparedness of the party to blame. (Damages might also be directly proportional to number of accounts breached, but only after the former is considered.)

As an example, imagine that a kid acting alone gets his forum or website broken into. There's probably not much that a teenager would have known about password security. Additionally, they probably weren't servicing millions of users as a part of a commercial service. You can apply this same kind of situational blamelessness to small businesses, clubs, churches, and so forth.

If, however, a multi-million dollar company gets breached, it's a likely different story. Such a company has employed engineers that are familiar with such topics as scaling and cross-browser support. If these types of business concerns are known and handled, then it's almost a certainty that they also know about password hashing. (If not, I would bet that new legislation would result in widespread education on the issue.)

If the cost of changes is estimated to be too high, we could even go as far as to lower or absolve damages if the 3rd party were to inform its users that its passwords were not hashed or not salted; a "use at your own risk" notice, if you will.

I feel strongly that we need to do something drastic about unhashed/unsalted passwords. This is becoming absolutely ridiculous; it makes our profession look like a circus show, and all for something that can be easily avoided.

nly14• 13 years ago

Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing.

Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide:

https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

The sooner we stop pretending there are no better answers than sending the contents of a password field raw over the wire, over SSL or not, and the sooner the web browser vendors and W3C start fixing this, the better. TLS-SRP is a ray of hope, but we need lighter, easier to deploy solutions that work at the application level rather than below HTTP.

On what alternate reality are we living where the W3C are working on Javascript cryptography before improving basic, fundamental, built-in authentication?

facorreia• 13 years ago

I agree, trusting remote services (and the communication infrastructure in between) is naïve.

Meanwhile, I use KeePass and generate a different key for each service.

nly14• 13 years ago

I also use Keepass....but why the smeg do I need to do this? My browser should be deriving per-site passwords for me at a minimum

maxtaco2• 13 years ago

Another alternative is https://OneShallPass.com. Free, auditable and open-source.

richardwhiuk• 13 years ago

Realistically we need HTTP digest authentication [0] to use a better hash function then md5, and we need it to be deployed by websites.

[0] http://en.wikipedia.org/wiki/Digest_access_authentication

andrewaylett3• 13 years ago

The trouble with digest auth is it requires the password or a usable representation thereof to be stored in recoverable form. This means that if you can get a dump of a site's database, you can use the stored credential data to authenticate to that site, which isn't possible when you store hashed passwords.

This is better than transmitting passwords in the clear, but worse than transmitting them over an encrypted link.

nly14• 13 years ago

Kinda. The important thing to note is that back in 1997, when the digest auth RFC was written, we recognised the hashing before going over the wire... and somehow we lost sight of that

MichaelGG• 13 years ago

Additionally, you'd need new browser APIs (AFAIK) to detect failed logins, render the login UI, etc. Otherwise, it's going to look out of place and confusing. Product managers are unlikely to accept the default browser/OS handling.

And digest auth means a DB dump has enough information to authenticate as a client, which is considerably worse for security if a server gets compromised.

revelation• 13 years ago

Realistically the problem with that isn't even MD5, it's the modal popup that hasn't changed in any browser since 1999.

It's so unbelievably popular, Chrome copied the behavior despite not existing in 1999. It's all over mobile, too...

tschellenbach• 13 years ago

What about Facebook login (or other oauth based systems)? Seems to me this solves most of the problem.

chalst2• 13 years ago

It solves the problem with offline password cracking, but it introduces the need to trust a third party.

Since the client side of SRP can be implemented in Javascript [1,2,3], there's not really much in the way of compelling reasons not to use it.

[1]: There's a client in the SRP bundle at http://srp.stanford.edu/download.html

[2] https://github.com/symeapp/srp-client

[3] https://github.com/clipperz/javascript-crypto-library

nly14• 13 years ago

Yes, I love trusting the keys to all my accounts to one corporation.

Less tongue-in-cheek, would you trust Facebook login for banking?

rmc2• 13 years ago

Until the site that you use for OAuth gets hacked.

aestra5• 13 years ago

No friggin way. I disabled that for a reason. I won't use Facebook login for anything else except Facebook. I don't want my Facebook identity being shared with a third party.

Isn't good for the tin foil hats.

fauigerzigerk2• 13 years ago

"The answer" doesn't exist and it never will. Everyone has to do their part. Services that store passwords in plaintext should definitely be publicly shamed, every single time.

jiggy20115• 13 years ago

The problem is that "publicly shamed" means "shamed amongst security geeks". Most websites main demographic is not security geeks.

thatthatis6• 13 years ago

A browser plugin that pre-hashes anything in a hidden text field (with a user secret key and the password origination domain) could mimic this as a layer on top of existing technology.

It would have the obvious portability issues, and I'm sure other implementation issues.

jorgem• 13 years ago

I propose a scarlet letter "P" (for plaintext).

jacques_chester3• 13 years ago

This is an is/ought fallacy. As professionals we don't get to propose the ideal universe as the solution to the problems of the actual universe. We have to take what we can get right now.

nly14• 13 years ago

And that's a false dichotomy. Are you saying we should dismiss dangerous flaws in the trust model, just because we have some workarounds for bad industry practice, and can 'make do'? because I'm not saying we shouldn't advocate strengthening existing databases right now. To me, the two concerns are completely separate.

MarkMc2• 13 years ago

I don't think nly was proposing an ideal universe, just an improvement to the current one.

It's not beyond the realm of possibility that browsers might be updated to support some form of Secure Remote Protocol standard. And to encourage web sites to use it browsers could display a little 'padlock' icon similar to the HTTPS icon.

bjourne• 13 years ago

I agree with you that a technical solution is needed. Forcing developers to store passwords securely, experience shows it doesn't work. But how exactly would your solution work? If I work at a computer I haven't used previously, how am I supposed to authenticate to a site without using a password?

MarkMc2• 13 years ago

I think the idea is that the browser would implement SRP. That means you would still type a password into your browser, but it wouldn't be sent to the server. Instead, the browser and server would authenticate you by means of exchanging specially-designed hash codes.

nly14• 13 years ago

The first step in the SRP protocol is to retrieve the cryptographic salt from the server, so you're essentially free to roam.

This step has concerns of its own though... for one thing the request itself reveals that the username/id is valid, and if you cache the userid / salt pair on the client machine it's vulnerable to snooping by other people with physical access. There are some fairly straightforward tweaks that can be made to the protocol to work around these issues though, since the salt isn't sensitive. In fact, I'm pretty confident storing the salt server side can be eliminated.

ye• 13 years ago

What's the point of the key stretching on the client side, if your stretched key gets sent to the server and is stored in plaintext.

It adds no security.

Server-side salting and hashing is the answer.

hobs• 13 years ago

I think the use of that is really just isolating the cross site hacking at that point. You are absolutely correct that if they have your password, its game over on that particular site.

nly14• 13 years ago

It's not a vanilla stretched key that gets send to the server. It is, in effect, the equivalent of your public key (that just happens to be kept secret by the server so it can use it to prove its identity, as the bearer, to you)

maxtaco2• 13 years ago

How does SRP help? With SRP, you still have a server-side brute-forceable table of password hashes. The server stores v = g^x, x = H(s, p), for each user, where s is the salt and p is the password. g is known to the server (and hence the attacker), so if the attacker downloads the database, he can go through the dictionary and brute force. If you're rolling out SRP, you ought to use scrypt for H.

Edit: and BTW, Cupid.com has nothing to do with OkCupid. They were the cause of much confusion throughout our history. We'd tell people to sign up for OkCupid, and they'd go to Cupid.com. Eventually, Cupid.com had to say, in their radio ads, "Not OKCupid.com, go to Cupid.com!"

nly14• 13 years ago

The server stores v = g^x, x = H(s, p)

Where H() is chosen, and only ever performed by, the client. As you suggested, I'd recommend using Scrypt for H. The poor evolution of SRP is tangential to the concepts and protocol

sillysaurus2• 13 years ago

It's interesting that no one's pointed out that SRP is trivially breakable by having the client send zero as its "A" value.

Of course, you can guard against that particular case. But the point is that SRP has pitfalls, just like every other solution. And those pitfalls aren't well known; the Wikipedia pseudocode makes no mention of that exploit, for example.

Jtsummers• 13 years ago

Yes it does [1]. In the narrative example with Steve and Carol, it states 3 safeguards.

1. Carol will abort if she receives B == 0 (mod N) or u == 0.

2. Steve will abort if he receives A (mod N) == 0.

3. Carol must show her proof of K first. If Steve detects that Carol's proof is incorrect, he must abort without showing his own proof of K.

[1] Ok, the python code doesn't seem to, you're correct. However, that's less a demonstration of a protocol implementation, and more a demonstration of the protocol's math. The page does mention it though in the protocol section. It would be appropriate (and maybe later I'll do this) to break that out so it's more obvious.

tptacek5• 13 years ago

This is flatly wrong. SRP stores serverside verifiers that are derived from plaintext passwords. Stealing an SRP verifier is equivalent to stealing a password hash.

The math for the brute force attack on SRP verifiers is slightly more elaborate than that of a salted hash (it involves a modexp), but is significantly cheaper than bcrypt. Using SRP is, from the perspective of a compromised server, worse than using bcrypt.

You may have become confused about SRP because Thomas Wu goes through some effort to explain how SRP is resistant to dictionary attacks. If so, you've mistaken which specific dictionary attacks he was talking about: previous challenge-response protocols were dictionary attackable off the wire, meaning that a passive attacker could grab the challenge-response sequence and crack that as if it was a password hash.

tedunangst2• 13 years ago

For reference, iirc last time I ran the numbers, SRP brute forcing has a work factor of 1000 compared to a single round of md5. Aka, not enough.

nitrogen3• 13 years ago

Is there a variant of SRP that would provide the same level of protection against a server hack as bcrypt?

Edit: it looks like it should be possible to replace H() in SRP with bcrypt or scrypt. Wouldn't that mitigate brute forcing from server hashes?

nly14• 13 years ago

This is flatly wrong. SRP stores serverside verifiers that are derived from plaintext passwords. Stealing an SRP verifier is equivalent to stealing a password hash.

I'm not wrong, you're just missing the point. The derivation process happens on the clients machine, so they get to 'chose', and verify, how it's performed, and can therefore ensure the KDF is extremely strong. The server doesn't need to know how it's strengthened and cannot, in fact, even discern if the verifier it sees is derived from a random value or through some purely deterministic process.

The objective here is to stop trusting the server with our passwords because they're prone to being lax, not prevent every conceivable technical attack from supercomputers from, and algorithms known only to, the NSA.

Using SRP is, from the perspective of a compromised server, worse than using bcrypt.

First of all, you can use Bcrypt inside SRP, so the password cracking route is a wash. It's the same, by definition. Secondly, I never said SRP6a as currently specified is what we should use. I said a protocol like SRP and even put emphasis on like. Elliptic curves are the way to go for compactness and speed these days.

An attack on the verifier is going to be vastly less feasible than attacking the KDF. The current best algorithms for breaking a good asymmetric verifier would be many orders of magnitude more complex than just bruteforcing any real world password input, even if it's heavily strengthened with Bcrypt or Scrypt.

100ms of PBKDF2/SHA-256 on a modern server CPU gives you maybe ~20 bits of strenghening on top of a weak ass ~30-40 bit password. Scrypt will give you maybe ~16 more bits, with a sigificantly higher hardware (memory) cost. Total, that's still a long way off the ~120 bits achievable trying to solve the DLP on an elliptic curve. In the end, cracking that verifier is more expensive.

SilkRoadie• 13 years ago

What gets me is that security professionals keep talking about layers of security. I don't understand how many recent attacks have resulted in complete breaches.

Adobe had source code taken, vB gave over pretty much complete server access.

You now have Cupid Media not even hashing passwords. The final defense of user information ignored..

It took me 3 days to implement password security on a legacy system. Implemented password strength requirements. Users trying to sign in with weak passwords were flagged and forced to change their password to meet new requirements. Plain text passwords were hashed with bcrypt. One guy.. 3 days.

The UK has ICO. I would like to see these getting involved in cases like this. Where they can fine websites catering to UK users who show negligence when storing user information. If it is not currently within their powers I would like to see a law change. There should be more accountability for website owners.

http://www.ico.org.uk/

16s• 13 years ago

Often times, the hack is through a web front-end. Back-end systems (such as DBs) are heavily firewalled, logged, monitored, etc. and are generally very well protected. Systems guys (OS and DB) know security pretty well and have been doing it for a long time now.

Much of the web software that powers the front-end is complex (PHP, Java, .Net, JS, CSS, SQL, includes, 3rd-party libraries from everywhere, etc). That complexity has a broad attack surface that is difficult and time consuming to test. And many devs are late to the security party (unless we're talking OpenBSD developers).

Management wants to push out new features by X date. Devs have very little time to test and are behind on security anyway. Hackers have all the time in the world to poke at the web front-end and test every possible combination of things until they finally get in.

In a nut-shell, that's the problem as I've seen it.

mattholtom• 13 years ago

We can help in some small way. Advocate for the use of password managers like LastPass and KeePass that use a different securely generated pw for each site.

NKCSS• 13 years ago

And now we wait for the dump to show up... will be usefull, larger then the rockyou plain.

jheriko• 13 years ago

maybe i am just stupid, but how are password managers secure?

i've seen people using them, and if i were of a less honourable persuasion i could abuse that quite easily... on the other hand, its impossible for me to steal information from out of their brain (so far at least).

draugadrotten• 13 years ago

its impossible for me to steal information from out of their brain (so far at least).

It's easier than you think to steal passwords from people. Just ask for it!

http://www.veracode.com/blog/2013/03/hacking-the-mind-how-wh...

lylejohnson• 13 years ago

I've used 1Password (a popular password manager for the Mac) for several years now. How could you "quite easily" hack those passwords, assuming that's what you're implying?

diminoten3• 13 years ago

Keylogger.

dagw• 13 years ago

"how are password managers secure"

Because now you need to steal two things. My password file and my password.

Now admittedly the one weakness is that once you have both those things you have access to all my passwords, but on balance I believe it is an acceptable compromise.

ams6110• 13 years ago

In reality, unless you are using services that do not allow any kind of email-based "forgot my password" recovery/reset, your email account is your password manager.

I use passpack to store different random passwords on all my online services, EXCEPT for my email account. That one is stored only in my brain.

valvoja• 13 years ago

Next article on Hacker News: "Hack of Cupid Media dating website exposes xx million fake dating profiles"?

brudgers2• 13 years ago

What this story shows is that sometimes '12345' makes sense as a password - i.e. when credential security doesn't matter to the user. If I use '11111' to sign up for a onetime visit to a website, then there's no nexus with my online banking account other than an email address - assuming even the most feeble attempt at picking a 'secure' password for my banking.

This is why it is often silly when articles condemn users for weak passwords when a password list is stolen. The proper assumption is that any password I use is stored and transmitted in plain text and just now falling into the hands of bad people.

This is the reason that until I started expressing this idea on HN, that my HN password was "hackernews". If HN was breached, I was no less secure. Sans the pursuit of lolz, it wasn't even worth trying to guess.

Of course, I changed it to something harder to prevent mischief since some individuals might have seen my comments as a challenge.

coldcode• 13 years ago

People who read HN know this. People who know nothing about security don't. Most people are lazy about things they don't know or care about. Thus it is a problem.

driverdan• 13 years ago

Use a password manager that generates a random password for every site.

brudgers2• 13 years ago

Providing strong passwords on throw away accounts provides useful information to an attacker - I.e. that I am using password manager "foo". If "foo" is comprised, then all my passwords generated from it are at risk.

To put it another way, where there is no reasonable chain of trust, I provide useless data for determining my strategy where there is a reasonable chain of trust. Revealing '11111' does not improve the probability of an attacker generating my bank password.

mildtrepidation• 13 years ago

This is a good argument for unique passwords, not for weak passwords. Weak passwords only "make sense" if you really don't care whether your account is compromised due to a very weak password.

leoedin• 13 years ago

But often you don't care. The value of a throwaway account you made to download a file is practically zero to you or an attacker. In the tradeoff in simplicity (all my crappy throwaway accounts have the password 12345... easy!) against security, simplicity wins.

If I only made an account on one of Cupid media's sites because I wanted to see a picture, I wouldn't care whether my password was easily guessable. Additionally, I'm fairly sure that an easy to make account with no access privileges is completely worthless to an attacker as well, and so the likelihood of anyone even attempting to compromise it is next to nothing.

ChikkaChiChi• 13 years ago

This is 100% true in my case. If I value the service, it gets a unique password. If it's Gawker Media, well here's a hash for 12345 and have fun with it.

Lukeas14• 13 years ago

You're not completely in the clear if you still use the same username throughout the web or as the start of your email address. If your account gets compromised on a site that allows users to make public posts (comments, articles, whatever) your online identity is now linked to whatever crap the compromiser posts under your username.

BHSPitMonkey• 13 years ago

So were you one of these accounts?

https://github.com/blog/1698-weak-passwords-brute-forced

brianbreslin• 13 years ago

Tangentially related: I am a lifelock member (not sure if its worth it, but gives me some peace of mind), and recently got email alerts from them saying my adobe login info was found for sale on several blackmarket sites.

jstalin• 13 years ago

Anyone know where to find the password dump?

Achshar• 13 years ago

While this might sound not so appropriate at first but I too would like to have the dump. Can result in some interesting password research.

sawthatcoming• 13 years ago

This was already very clear. The whole website was flawed and it probably was known by individuals for a longer time... Bypass payments, change other people's profile, read other people's messages. It does not stop here.

Torn• 13 years ago

Making matters worse, many of the Cupid Media users are precisely the kinds of people who might be receptive to content frequently advertised in spam messages, including male enhancement products, services for singles, and diet pills.

Oh wow. So Internet dating users are generally stupid, under-endowed, desperate and overweight?

albedoa• 13 years ago

They wrote "many", not "generally".

And yes.

aestra5• 13 years ago

[citation needed]

endlessvoid94• 13 years ago

I was blown away this was included in the article. There's no citation, no explanation or anything. It's just blatant.

Jagat• 13 years ago

After the adobe/cupid breaches, it is high time some governing body mandates every website to reveal on their privacy policy page how passwords are stored on their servers.

diminoten3• 13 years ago

Anyone have a copy of the password list? 42 million passwords would be fun to analyze.

kstop• 13 years ago

So that's what - 30 million male users, 1 million female, and 11 million spam-and-scam bots?

fiatmoney• 13 years ago

Time for civil liability for these breaches. At this point the risk of storing plaintext passwords is known enough that it should qualify as negligence.

Hack of Cupid Media dating website exposes 42 million plaintext passwords

Related Stories