Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MDN Database Disclosure

blog.mozilla.org

Post reply on HN
Print view View original

41–50 of 50 posts

Re: MDN Database Disclosure

#41

Post by nitrogen »

jzwinck wrote: post #10
mp4box wrote: post #6

Can someone explain the meaning of "data sanitization process of the site database had been failing" Isn't that another way of saying SQL injection ?

I wondered about this too. At a guess, perhaps they were doing a straight database dump from a production system which had sensitive information as well as public data. They would then run a script to delete the sensitive columns before posting the dump. This seems likely to have been broken at the design stage: systems should fail safe. The first-order fix might be to check the return value of the sanitizer script a…

Every unattended shell script should start with this:

    set -e

Re: MDN Database Disclosure

#42

Post by jeffbryner »

Pacabel wrote: post #39
jvehent wrote: post #16

Earlier quoted context omitted.

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?

https://bugzilla.mozilla.org/show_bug.cgi?id=932869 was the request for a sanitized DB for folks wanting to develop MDN itself. We could identify most of the handful of IPs that downloaded the file during the time period where it was unsanitized to individuals (i.e. IPs inside Mozilla offices, etc.). However because some IPs were unknown, or public, or potential NAT addresses Mozilla decided it was best to disclose the issue.

Re: MDN Database Disclosure

#43

Post by Pacabel »

jeffbryner wrote: post #42
Pacabel wrote: post #39

Earlier quoted context omitted.

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?

https://bugzilla.mozilla.org/show_bug.cgi?id=932869 was the request for a sanitized DB for folks wanting to develop MDN itself. We could identify most of the handful of IPs that downloaded the file during the time period where it was unsanitized to individuals (i.e. IPs inside Mozilla offices, etc.). However because some IPs were unknown, or public, or potential NAT addresses Mozilla decided it was best to disclose t…

If some of the accesses were by people or systems within Mozilla, can you please address why a month went by before the problem was noticed?

If there was enough need to justify putting forth the effort required to export a sanitized version of these data for developers to use, then why didn't these users notice that something was wrong much sooner? And if they did notice, why weren't the appropriate parties within Mozilla notified sooner?

Could you please provide more specific details about these IP addresses that couldn't be accounted for, too? Perhaps a list of them, for instance? At least then affected users will be able to make their own call regarding their level of risk due to this incident.

Re: MDN Database Disclosure

#44

Post by adrianmsmith »

ygjb wrote: post #28
anaphor wrote: post #11

Earlier quoted context omitted.

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

To provide a bit more context, in early 2011 we made a conscious decision to move towards the password storage methods described here : https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines While we were moving in that direction (upgrading apps, etc) we also launched Persona (BrowserID at the time). Some apps opted to switch to Persona, others opted to upgrade password storage mechanisms.

That's an interesting document.

It mainly contains assertions for what one should do. Do you know if there's an explanation for the rationale anywhere? For example _"Passwords must be 8 characters or greater"_ or _"Privileged accounts - Password for privileged accounts should be rotated every: 90 to 120 days"_.

Re: MDN Database Disclosure

#45

Post by Karunamon »

Karunamon wrote: post #24
[deleted] wrote: post #22

[deleted]

Christ, it's comments like these that make me glad I don't have to write messages for public consumption at large enterprises. People absolutely hang off of every word in the most absurd fashion..

The now-deleted comment was some donwnright vitriolic complaining about the use of the word "like" in the notification email. "We would like to inform you..."

Re: MDN Database Disclosure

#46

Post by jeffbryner »

Pacabel wrote: post #43
jeffbryner wrote: post #42

Earlier quoted context omitted.

https://bugzilla.mozilla.org/show_bug.cgi?id=932869 was the request for a sanitized DB for folks wanting to develop MDN itself. We could identify most of the handful of IPs that downloaded the file during the time period where it was unsanitized to individuals (i.e. IPs inside Mozilla offices, etc.). However because some IPs were unknown, or public, or potential NAT addresses Mozilla decided it was best to disclose t…

If some of the accesses were by people or systems within Mozilla, can you please address why a month went by before the problem was noticed? If there was enough need to justify putting forth the effort required to export a sanitized version of these data for developers to use, then why didn't these users notice that something was wrong much sooner? And if they did notice, why weren't the appropriate parties within Mo…

Sorry, I can't provide a list.

Re: MDN Database Disclosure

#47

Post by Pacabel »

jeffbryner wrote: post #46
Pacabel wrote: post #43

Earlier quoted context omitted.

If some of the accesses were by people or systems within Mozilla, can you please address why a month went by before the problem was noticed? If there was enough need to justify putting forth the effort required to export a sanitized version of these data for developers to use, then why didn't these users notice that something was wrong much sooner? And if they did notice, why weren't the appropriate parties within Mo…

Sorry, I can't provide a list.

Why not?

Re: MDN Database Disclosure

#48

Post by ygjb »

Pacabel wrote: post #47
jeffbryner wrote: post #46

Earlier quoted context omitted.

Sorry, I can't provide a list.

Why not?

Because our privacy policies state that we won't disclose personally identifiable information about users, and IP addresses can be personally identifiable.

Unfortunately security incidents happen, but we won't violate the commitments we have made to our users; in this case, if we revealed the IP addresses we would have another, deliberate information leak on our hands.

Re: MDN Database Disclosure

#49

Post by ygjb »

adrianmsmith wrote: post #44
ygjb wrote: post #28

Earlier quoted context omitted.

To provide a bit more context, in early 2011 we made a conscious decision to move towards the password storage methods described here : https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines While we were moving in that direction (upgrading apps, etc) we also launched Persona (BrowserID at the time). Some apps opted to switch to Persona, others opted to upgrade password storage mechanisms.

That's an interesting document. It mainly contains assertions for what one should do. Do you know if there's an explanation for the rationale anywhere? For example _"Passwords must be 8 characters or greater"_ or _"Privileged accounts - Password for privileged accounts should be rotated every: 90 to 120 days"_.

Not on hand, those decisions were made years ago, and done in email discussions and in person meetings.

That said, the password length requirements were driven by the cost of performing effective brute force attacks against properly hashed and salted values at the time we set that length.

Privileged passwords was basically a stop gap measure to ensure that users were refreshing passwords regularly. The correct solution is to deploy multi-factor authentication.

Re: MDN Database Disclosure

#50

Post by ygjb »

meowface wrote: post #20
billyhoffman wrote: post #8

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…

This was one of the least detailed and helpful disclosures I've ever seen. Reading "encrypted passwords", and then "salted hashes" without any specification of the hash algorithm from a tech company like Mozilla is utterly astonishing to me. I feel like whoever discovered this breach sent it over to the PR department without any sort of final review of the release by an engineer.

Not at all, the decision was made to release the information necessary to help people decide if action was needed. As you can see from this thread, we are happy to provide relevant details, and like most of our other tools, Kuma, the platform that MDN uses is open source, and on github.
Post reply on HN