Email Mishap Leaks Google Staff Data (thestack.com)

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.

Comments

time for dynamic ssn

[Moblaster]

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.

Re:time for dynamic ssn

[jellomizer]

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.

Re:time for dynamic ssn

[ohieaux]

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.

Re:time for dynamic ssn

[NotInHere]

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.

Re:time for dynamic ssn

[NotInHere]

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.

Shouldn't have mattered, BAD Google!

[pla]

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.

Re:Shouldn't have mattered, BAD Google!

[DarkOx]

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.