Slashdot Mirror

← Back to Stories (view on slashdot.org)

Email Mishap Leaks Google Staff Data (thestack.com)

Posted by msmash on from the email-mishap-at-email-giant-house dept.

An anonymous reader writes: Google has suffered a data breach which compromised the security of its employees, after the company's staff benefits vendor mistakenly sent an email containing sensitive data to the wrong recipient. Google has sent a formal apology to an undisclosed number of affected employees. The letter notifies of the data breach and advises staff to register for free identity protection checks and credit monitoring for the next two years. The document explains how the third-party company, which provides Google with benefits management services, sent the personal information to a benefits manager at another firm by accident. The data included staff names and social security numbers, among other sensitive details.

33 comments

  1. time for dynamic ssn by Moblaster · · Score: 2

    This kind of thing has only been getting more commonplace. Won't make a dime's worth of difference -- a $10/mo subscription to some credit monitoring service, some apologies to the employees, and a bit of worry, and NO changes -- until there is a system in place for complex, dynamic one-time-use SSN codes that EXPIRE if unused.

    1. Re:time for dynamic ssn by jellomizer · · Score: 3, Informative

      The problem was the SSN was never meant for identification. It was just a number that the government used to track your Social Security benefits.
      Being that it was unique as for one SSN per Person, and most citizens have one it became your identity.

      However to carry are RSA phob for my life to prove my identity is kinda worrisome as well.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    2. Re:time for dynamic ssn by ohieaux · · Score: 4, Insightful

      Humans don't have unique identifiers that are easily accessible. We can use fingerprints, retina or DNA with physical presence, but we need a surrogate key if we want to track people in our digital world. The problem with most surrogate keys is that they have no meaning outside of the system that creates them. A SSN is a perfect surrogate key, in that it has a scope outside of the system (Social Security) that created it. But, that is also it's weakness. Since so many systems (like financial and medical) use this unambiguous key, it can be used for nefarious purposes. Any simple, global, constructed key will have these faults.

      --
      Where all think alike, no one thinks very much.
    3. Re:time for dynamic ssn by NotInHere · · Score: 3, Insightful

      No, SSNs were intended for identification. What SSNs were never designed for was authentication. A system where you give them your SSN in order to prove you are really you is flawed by design.

      The SSNs are unique and that's great for identification purposes as people may share the same name and date of birth. But an SSN should be no secret, because if you send it to all entities you want to prove you really are who you claim to be, the secret ceases to be a secret.

      Replace the SSN by hashes of a public key, and let the services send you challenges instead. That system will work, but probably nobody will want to use it.

    4. Re:time for dynamic ssn by NotInHere · · Score: 2

      Fingerprints are not unique. At least not fingerprints on one finger. Same goes for DNA, you may have a twin with exactly the same DNA, and perhaps one day cloning humans becomes a thing.

      The problem with SSNs is that they are used as some way you can use to prove you are you. But as is with credit card expiration dates, the secret stops being one if you give it to another entity. The problem SSNs are just damn easy to use, unlike public keys. Explain a grandma how to gpg sign a random generated 512-bit challenge.

    5. Re:time for dynamic ssn by sims+2 · · Score: 1, Interesting

      At work we use ssns to identify people in our system its not online it doesn't check that the number is valid and we don't actually care if its real or not.
      The reason why we ask for the ssn is solely so we can find them in our system a year later when they come back. Because many people have absolutely no idea what their legal name is or don't care.

      Name on id: "Fred jones"
      What he says his name is: "Patrick star"
      Oh I've changed my name 3 times in the last year what name do you have me under? Try smith, green, apple, bob.
      *checks ssn* ah here we are "Natsu dragneel"
      Client: oh I forgot about that one that was when I was with my 7th wife.

      Give us something else we can use to persistantly keep track of our customers because names really suck.

      --
      Minimum threshold fixed. Thanks!
    6. Re:time for dynamic ssn by Anonymous Coward · · Score: 0

      The problem is that your institutions are using a shared unique identifier as some kind of "trusted secret". If they used actual security rather than this security-through-obscurity BS, you could post your SSN to facebook, include it in your letterhead, paint it on the side of your house, and it wouldn't matter that everyone knew.

      In the UK, we have various numbers for various things - the National Insurance number is the one you use for tax and employment-related stuff - but it's not supposed to be secret. You need either photo ID (passport, driver's license) or secure single-purpose passcode (chip+pin, online banking etc) to do anything that will result in a liability.

      Fraud still happens, but it's generally a lot easier to socially engineer the victim to comply with the fraud than it is to convince our institutions that you're someone else. And although it's always a PITA to clear up, the onus is on the institutions that got fooled rather than the individual whose name was used.

    7. Re: time for dynamic ssn by cablepokerface · · Score: 1

      Both clones and twins have different fingerprints.

    8. Re:time for dynamic ssn by Anonymous Coward · · Score: 0

      Please learn the facts about SSN before talking about them. Know the facts!
      1) SSN are not unique for a person
      2) SSN are not permeate for a person
      3) SSN are not numbers

    9. Re:time for dynamic ssn by Anonymous Coward · · Score: 0

      They're not even unique:
      http://www.computerworld.com/a...

    10. Re: time for dynamic ssn by Anonymous Coward · · Score: 0

      What?

    11. Re: time for dynamic ssn by Anonymous Coward · · Score: 0

      I've worked in the medical sector and education sector for 10+ years and never experienced this problem. We get the name first; date of birth second, phone third, address fourth. The last two are only needed if doubles are in the system. I'm not sure where you work, but I have never experienced people who don't remember their own names. Or change their names so much they forgot which identity they used.

      Sounds to me like you guys are just being lazy. And using the SSN because It's the easy thing to do. Not sure if that's true but that's what you are making it sound like. As none of your examples seem valid to me. Not even remotely close.

  2. My company does this often on purpose by Anonymous Coward · · Score: 0

    I can't seem to get senior management to stop sending full SSN in unencrypted emails outside of the company. It drives me nuts. I would love to threaten legal action since many of our employees have experienced identity theft. Any ideas what I can do?

    1. Re:My company does this often on purpose by Anonymous Coward · · Score: 1

      Go public, making them stop, and get fired for it.

  3. And those employees get a special bonus, right? by Anonymous Coward · · Score: 0

    Nope. Just words. Just a simple apology for screwing up.

    Now I'm sure they fired the vendor who made this mistake right?

    Double standard. Company screws up, no problem, no extra money in the affected people's paycheck. Employee/vendor screws up, fired.

  4. Encryption by Anonymous Coward · · Score: 1

    End-to-end encryption automatically applied to all emails would provide an additional consistency check to reduce these kinds of incidents.

    Require recipients potentially receiving especially sensitive information to have a private key that is an additional factor to their email address.

    1. Re:Encryption by ohieaux · · Score: 1

      The problem I see with this is that if I select a wrong address, my email will likely assume that's what I wanted to do and encrypt for them.

      --
      Where all think alike, no one thinks very much.
    2. Re:Encryption by NotInHere · · Score: 1

      Yeah, especially the more convenient encyption becomes.

    3. Re:Encryption by Anonymous Coward · · Score: 0

      Which is why you use DLP policies to prevent that kind of thing from happening.

  5. Shouldn't have mattered, BAD Google! by pla · · Score: 4, Insightful

    The data included staff names and social security numbers, among other sensitive details.

    Why the hell would they send sensitive employee data unencrypted over email? It should have made no difference at all if they sent it to the wrong address, because no one but the intended recipient should have the key to access the data. Yet clearly, not the case here.

    People need to start going to jail for shit like this.

    1. Re:Shouldn't have mattered, BAD Google! by Anonymous Coward · · Score: 0

      Even a 500 billion dollar software company can't get software that emails encrypted easily.
      SMIME is massive fail. PGPMIME is a gigafail. Out of the 20 or so linux machines I've had over the last few years, enigmail worked on all of like 3 of them. My current machine says gpg-agent isn't running but it is. Hours spent^H^H^H^H^Hwasted fiddling with something I shouldn't have to spent 2 seconds on. Then of course even if I can get it to work, no one I want to send email to can either, so it's pointless. Even when I can get it to work, I can't blame my friends and family who can't. It's all such utter shit. If someone, somewhere, would for once write software that isn't a giant fucking steaming pile of shit, that would be nice.

    2. Re:Shouldn't have mattered, BAD Google! by DarkOx · · Score: 2

      Most e-mail encryption is done transport level and its opportunistic.

      You Say: STARTTLS
      and see if you get a non-error response code. If you do TLS handshake and the mail is ciphered if not it goes in the clear. Now most of these gateways can be configured to do things like 'require encryption if the destination domain is example.com'

      So you can fix it so all mail to your payroll provider gets encrypted or bounced, but if the client miss-addresses it and sends it to some other valid domain + mailbox, opps.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    3. Re:Shouldn't have mattered, BAD Google! by Anonymous Coward · · Score: 0

      I was thinking the same thing!

      Why in the hell was anything like this sent through EMAIL!!!!????
      That is grounds for dismissal at the very least.

      Encryption is required, but email, is a terrible terrible idea.

    4. Re:Shouldn't have mattered, BAD Google! by Anonymous Coward · · Score: 0

      The parent didn't mention e-mail encryption. The parent talked about encryption of the attached file, which can be done by any software that can encrypt files. But you're right it might not solve the problem: If the client is dealing with multiple companies, they could still get confused and encrypt the attached file with the miss-addressed recipient's key and we'd still have the same problematic outcome.

    5. Re:Shouldn't have mattered, BAD Google! by Anonymous Coward · · Score: 0

      You mean Google hired a third party benefits provider that screwed up. Security Operations at Google don't allow sending of sensitive information over email.

    6. Re:Shouldn't have mattered, BAD Google! by 140Mandak262Jamuna · · Score: 1

      They are still using Email? So 20th century. They should have been tweeting the info, 140 bytes at a time.

      --
      sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    7. Re:Shouldn't have mattered, BAD Google! by Anonymous Coward · · Score: 0

      You'd be surprised. IANAL, I've had to deal with them in both a client and professional role. You'd expect they along with doctors understand what privacy means and act accordingly. In reality they have insurance to shield them not you. Few know what passwords are let alone how SSL works. Sending entire an entire dossier in email is considered normal..

      The joke here is how many of these stories _end_ with a company "offering" credit monitoring - which you have to register for. It's disgusting.

  6. Reporting? by Anonymous Coward · · Score: 0

    This is shameful. This is just a re-wording of the Softpedia article from this morning, including the editor's train of thought when arranging and phrasing paragraphs. The dead giveaway is the mention of the NATO report at the end of the article and the Google quotes in the same position. http://news.softpedia.com/news... Nice work The Stack!!!

  7. ONLY apps can app apps! by Anonymous Coward · · Score: 0

    This is what happens when LUDDITE vendors use LUDDITE email instead of appy app apps!

    Apps!

  8. Are data leaks really.... by Anonymous Coward · · Score: 0

    Are data leaks really a method to:
    1) get people to "self" identify to "force" an opt'ed in status
    2) to setup you for life-time billing after 1yr "free" credit monitoring
    3) allow NSA monitoring, since you are now with a third -party/middle-man with lax security (ie: share with third parties)

  9. Free Credit Protection by ThatsNotPudding · · Score: 1

    This seems such a tepid consolation nowadays.

    It feels like as if a shit Electrician burned down your house thru sheer incompetence and their way of making up for it is providing you a new fire extinguisher.

  10. commentsubjectgoeshere by Anonymous Coward · · Score: 0

    >The data included staff names and social security numbers, among other sensitive details.
    >other sensitive details
    Alright, I guess "sensitive" is a pretty broad term. But it's hard to get me riled up about someone "leaking" a birthday or address. Phone number maybe, assuming it's not right in the gorram white pages.

  11. Corporate-speak by Sir+Holo · · Score: 1

    CORP MEMO: "We do not have evidence that any employee's personal and sensitive information was leaked to outside parties."

    TRANSLATION: "We didn't look for it. Just shut up and keep working."