Live data from Hacker News

MDN Database Disclosure

blog.mozilla.org

31–40 of 50 posts

Re: MDN Database Disclosure

#31
I have been wondering who leaked my address after I started getting the "E.N.L.A.R.G.E...Y.O.U.R....." spam exactly about a month ago.

Initially I thought that it might have been my fault for entering the email address where I shouldn't have. I am disappointed that such processes are even architecturally possible at Mozilla where internal data is exposed externally.

Also, this has raised a question. Almost everybody knows that passwords must be hashed and salted. But I haven't see anywhere encrypted email addresses. Are there any strongly negative consequences to encrypting sensitive personal data in databases?

Re: MDN Database Disclosure

#32
post #31

I have been wondering who leaked my address after I started getting the "E.N.L.A.R.G.E...Y.O.U.R....." spam exactly about a month ago. Initially I thought that it might have been my fault for entering the email address where I shouldn't have. I am disappointed that such processes are even architecturally possible at Mozilla where internal data is exposed externally. Also, this has raised a question. Almost everybody…

I don't think encrypting an email address would create any issues. In fact, if I was to provide a service, I'd save the hash email address for easy authentication (ie hash the email given during a login and compare with the hash you have) and one encrypted version of the email address so I can use it if needed (to inform the user or whatever).

I started getting a lot of spam about one month ago too and even emailed LastPass a bit angry. But this Mozilla incident could well be the cause of the spam...

Re: MDN Database Disclosure

#33
post #13

Earlier quoted context omitted.

It's what django uses, and this site uses django.

Django 1.3 or lower. Django uses PBKDF2 [1] since 1.4 (March 23, 2012) [2]. [1] https://docs.djangoproject.com/en/1.5/topics/auth/passwords/... [2] https://docs.djangoproject.com/en/dev/releases/1.4/

MDN was on Django 1.2 for a while, albeit with monkeypatched password hashing (since Django at the time was still defaulting to SHA1, I believe). With the switch to Persona, it no longer matters -- for a new account -- what hasher is used, since Persona doesn't involve storing a password.

Re: MDN Database Disclosure

#35

There is much that could be done to improve this announcement: 1- What does "encrypted, salted passwords" mean? MD5 with a static salt? Holy shit, that's a problem. bcrypt? Less so. I have no context to know how concerned I should be, or any indication of how incompetent, or awesome, Mozilla's existing processes and defenses are. Fail. 2- They talk about a "data sanitization process" failing, but then talk about a "d…

>What does "encrypted, salted passwords" mean? MD5 with a static salt? Holy shit, that's a problem. bcrypt? Less so. I have no context to know how concerned I should be, or any indication of how incompetent, or awesome, Mozilla's existing processes and defenses are.

Given that this leak happened at all, incompetent to criminally negligent would be my estimation.

Re: MDN Database Disclosure

#36
post #11
post #9

Earlier quoted context omitted.

Sha256+salt. See https://github.com/mozilla/kuma We are still working on the rest.

Why did you decide to use sha256 instead of a kdf like bcrypt or pbkdf2? I'm not attacking you, genuinely curious.

As the number of logins per core increases the login latency with these functions increases fairly quickly.

Re: MDN Database Disclosure

#37
post #29

In Dezember 2013, Mozilla MDN switched to their self developed Kuma wiki software (from a hosted wiki solution). An open source wiki software written in Python and using the Django framework. https://developer.mozilla.org/en-US/docs/MDN/Kuma , https://news.ycombinator.com/item?id=6876636

We launched Kuma on August 3, 2012. That post is about the MDN redesign we launched in 2013.

Re: MDN Database Disclosure

#38
I don't understand why they had to do this, couldn't they just use a schema dump with random data? They are already setting the passwords to null and names to a random number in their sanitization script...

Re: MDN Database Disclosure

#39
post #16

There is much that could be done to improve this announcement: 1- What does "encrypted, salted passwords" mean? MD5 with a static salt? Holy shit, that's a problem. bcrypt? Less so. I have no context to know how concerned I should be, or any indication of how incompetent, or awesome, Mozilla's existing processes and defenses are. Fail. 2- They talk about a "data sanitization process" failing, but then talk about a "d…

A process failed, and the DB dump that is published to help contributors improve the MDN site got out unsanitized. The sanitization/publication process will be redesigned to include stricter controls. For now, it is shut down. MDN has been using persona for a while now, meaning that most accounts don't have passwords in the database. But older accounts still had the SHA256 salted hash that Django creates. We traced b…

Who exactly are these "known contributors", and why did they have access to this data? Why did they not report the problem earlier?

And if it was downloaded "mostly" by "known contributors", who was involved with the rest of the detected downloads?

Re: MDN Database Disclosure

#40
post #32
post #31

I have been wondering who leaked my address after I started getting the "E.N.L.A.R.G.E...Y.O.U.R....." spam exactly about a month ago. Initially I thought that it might have been my fault for entering the email address where I shouldn't have. I am disappointed that such processes are even architecturally possible at Mozilla where internal data is exposed externally. Also, this has raised a question. Almost everybody…

I don't think encrypting an email address would create any issues. In fact, if I was to provide a service, I'd save the hash email address for easy authentication (ie hash the email given during a login and compare with the hash you have) and one encrypted version of the email address so I can use it if needed (to inform the user or whatever). I started getting a lot of spam about one month ago too and even emailed L…

The encrypted e-mail address has to be read somehow, so it's just as likely that an attacker gets the decryption key as the database itself (unless you use e.g. a hardware security module). That's probably good enough for e-mail addresses, but as you likely know, not acceptable for passwords.
Post reply on HN