Weak Excuses after Weak Security :: Mozilla's user a/c on Public Server

now this year has been filled with loads of news related to user-data getting leaked from different websites... but it wasn't much disturbing as web-vulnerabilities in Facebook are well known and accepted as cons of the deal and neither 1.3m a/c details leaked from Gawker came as a shock (it was more of a Tweet-Flood)

but
On Dec-17-2010, Mozilla was reported about availability of its user-accounts (partially, which were used on addons.mozilla.org) over a public server.
They have projects like Firefox (super famous web-browser), NSS (one of the most famous libraries for developing secured client-server application), and more... if an organization like them do a mistake like this, oh yeah... hackers paradise

it's how they defend themselves...

• database included 44,000 inactive accounts using older
  

  but don't you think... even inactive users on a site deserve their privacy, and if they were inactive and not important then better purge the information pertaining to account... why keep it instead

• md5-based password hashes
  

  they don't use it now... for active users they support SHA-512 per-user-salt mechanism; now that's good
  

• current addons.mozilla.org users and accounts are not at risk

  so if I don't use Mozilla anymore... they wouldn't respect my a/c details anymore and still keep it... so that in future they could 'arrrrgh sorrry' me, brutally nice

• incident did not impact any of Mozilla’s infrastructure

  it was available on a public server and not a hacked-n-fetched... bravo

• only outsider who accessed the data was the security researcher that reported the mistake to Mozilla

  how are they so sure... if none else reported it doesn't mean that none else saw it, and it is not necessary that everyone accessing it will 'remain in' logs.

References:
http://blog.mozilla.com/security/2010/12/27/addons-mozilla-org-disclosure/
http://www.thetechherald.com/article.php/201052/6620/Mozilla-password-disclosure-a-non-event

bypass of user level restrictions, a case of bug in 'Scribd.com'

http://www.youtube.com/watch?v=g-ETsFjRhqsFew weeks back, saw Scribd.com offering me to buy/upload something for downloading a Document uploaded on it. Second time when I opened some document, in another browser it shows disabled 'download', 'print', and 'mobile' option.

As I didn't get that Document to download, I didn't felt like reading it online also... so just thought why not try to download it and if I succeed, then I'll read it online.
And I read it online :)

So, here is a bug (which  has now been fixed) in Scribd.com... that allowed users to get a local copy of documents which were devoid of download and print options.

It's how layered limitation can be broken, and why restrictions must be implemented root-level-up and not just as user-level module.

@YouTube: http://www.youtube.com/watch?v=g-ETsFjRhqs
How-To [ download the not-allowed ]
example: Bypass Scribd.com disabling Downloading/Print/Mobile on some links

Example Website Bug : a bug of Scribd.com (reported & got fixed) from aBionic@Vimeo

so, now you can either Print the document or create a PDF/image printing this document using softwares like PDFCreator.

only '.org' and '.net' domains under DNSSEC protection till now, WHAT ABOUT YOU

Are you protected with DNSSEC:
[] in mid-2010, DNSSEC got deployed over 'root-DNS-server' and '.org' domain
[] on 10-Dec-2010, Verisign deployed DNSSEC in '.net' zone too
   {securing more than 13million registrations online}
[] preparations are up to sign the '.com' zone in first quarter of 2011

Verisign has even launched a cloud based DNSSEC implementation service to ease its implementation in organisations.

Refer to http://www.securityweek.com/verisign-launches-new-dnssec-signing-service
For those who are not much familiar with DNSSEC, its a security layer standardized to be implemented over traditional DNS services... it will help the users counter DNS vulnerabilities exposed by researchers like 'Dan Kaminsky' including DNS poisoning attacks.
Refer to http://www.dnssec.net

Its implementation would require more processing power, bandwidth usage and more storage needs as it uses intensive encryption mechanism over all DNS traffic.

Though, I was surprised hearing initially of its implementation over root DNS server as its alterantive DNSCURVE (suggested by Dan Kaminsky) was conceptually better in security and easy on resources too. Don't know it was fair selection or just another political/community-biased decision.

=begin :footer

# waited about a week to have time doing this post in detail... 

# but more delay would deny its usability... so its here

=end :footer