{"id":925,"date":"2009-02-13T18:12:20","date_gmt":"2009-02-14T02:12:20","guid":{"rendered":"http:\/\/cubist.cs.washington.edu\/Security\/?p=925"},"modified":"2009-02-13T18:12:57","modified_gmt":"2009-02-14T02:12:57","slug":"current-events-monstercom-data-breach","status":"publish","type":"post","link":"https:\/\/secblog.cs.washington.edu\/Security\/2009\/02\/13\/current-events-monstercom-data-breach\/","title":{"rendered":"Current Events:  Monster.com data breach"},"content":{"rendered":"<p>\u00a0<\/p>\n<p>According to MSNBC (http:\/\/www.msnbc.msn.com\/id\/29017452\/), Monster.com along with USAJobs.com (which monster\u2019s parent company runs) was breached, resulting in the theft of user ID\u2019s, passwords, email addresses, names and phone numbers. \u00a0The number of records stolen was not disclosed, nor were any details concerning how the thief obtained access to their databases.<\/p>\n<p><!--more--><\/p>\n<p>As to why this event arose, the large number of users of these sites makes them appealing targets to break into. \u00a0Without any technical details concerning the attack, it is difficult to guess what security was in place (or what wasn\u2019t) that permitted the breach to occur. \u00a0It is also difficult to say what could have been done differently to prevent the attack. \u00a0If this information was not encrypted, that is one thing that could have been in place, such that even gaining the encrypted files does not immediately grant the attacker access to the information.<\/p>\n<p>The article mentions some interesting broader issues with this event. \u00a0Namely, that security breaches are becoming so common that hearing of one is less and less likely to deter customers from using a particular service \u2013 it is \u201cpar for the course\u201d as it were. \u00a0It also mentions the mindset that \u201ceven if you switch services, the service you switch to is not guaranteed to be any safer from your current service.\u201d \u00a0These are interesting trends in the concept of data security. \u00a0On one hand it could be a good thing if customers expected data breaches from certain services, such that they don\u2019t put out any sensitive information that would be cause for alarm if stolen. \u00a0On the other hand, many services require information to function that most would consider sensitive or personal, and as such removing the accountability for a data breach by citing the mindset that \u201cyou have to expect it will happen every so often\u201d is counter productive.<\/p>\n<p>Though it is true that perfect security is generally impossible, \u201cbest practices\u201d should be in place, and companies should be held accountable for reaching those standards. \u00a0If in the wake of a data breach it is determined that the company in question was following current and best practices in data security, then perhaps it is right to say \u201cit just happens sometimes despite all you can do\u201d and move on. \u00a0If, on the other hand, it is determined that negligent practices were occurring, the public should be made aware of that and the company should be held accountable. \u00a0Data breaches may be somewhat inevitable, but if I have to choose between two similar services, one which has had data breaches under negligent circumstances and one which has had data breaches but has shown that they are doing everything they should be, I\u2019ll take the company that\u2019s doing what they should be.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u00a0 According to MSNBC (http:\/\/www.msnbc.msn.com\/id\/29017452\/), Monster.com along with USAJobs.com (which monster\u2019s parent company runs) was breached, resulting in the theft of user ID\u2019s, passwords, email addresses, names and phone numbers. \u00a0The number of records stolen was not disclosed, nor were &hellip; <a href=\"https:\/\/secblog.cs.washington.edu\/Security\/2009\/02\/13\/current-events-monstercom-data-breach\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":116,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-925","post","type-post","status-publish","format-standard","hentry","category-current-events"],"_links":{"self":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/925","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/users\/116"}],"replies":[{"embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/comments?post=925"}],"version-history":[{"count":3,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/925\/revisions"}],"predecessor-version":[{"id":928,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/925\/revisions\/928"}],"wp:attachment":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/media?parent=925"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/categories?post=925"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/tags?post=925"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}