from Hacker News

T-Mobile Database Breach Exposes 2M Customers' Data

by Nazzareno on 8/28/18, 2:05 PM with 76 comments

• by seibelj on 8/28/18, 2:32 PM

  I have T-Mobile. 6 weeks ago my phone could no longer access the cell network. The support agent told me that someone went into a store, claimed to be me, and was able to change the SIM card. The history showed the employee in the store verified me by my driver's license. We changed the SIM back and supposedly locked the account.

  I use Google Auth OTP for all the accounts that I can, and as far as I can tell nothing was breached or stolen, but I wouldn't rely on your cell phone or number for anything whatsoever, it's way too easy to socially engineer, or have some easily corruptible retail employee steal from you.

• by heywot on 8/28/18, 3:13 PM

  My favorite part about all of this is that, as a T-Mobile customer, this is how I find out about the leak. There's not even an alert when I log into my account. Why can't companies be more responsible about these situations?

• by wegs on 8/28/18, 4:51 PM

  A while back, I ran into a security hole in T-Mobile. Confidential customer data was quite literally available on the Internet via a Google search. This was due to a half-dozen missing very basic security precautions (forms using GET instead of POST, no CSRF, etc., etc., etc.).

  I emailed the CEO. It got moved to a team who assured him there were no problems. The pages got taken down, but the underlying issues were, as far as I know, ignored (the communication to the CEO was essentially that there were no issues, and he believed his team over me).

  I still trust T-Mobile more than Spring/AT&T/Verizon as a company, but data security is non-existent.

  I'm not quite sure what to do with that.

• by kevin_thibedeau on 8/28/18, 4:01 PM

  > But a T-Mobile spokeswoman later told news site Motherboard that "encrypted" passwords were in the batch of data.

  T-mobile stores plaintext passwords. They recently invalidated a password I had been using with them for some time because they changed their rules and disallowed special characters (tons of stupid there). They wouldn't have known to do that if the passwords were properly hashed.

• by mrep on 8/28/18, 3:06 PM

  > T-Mobile's assertion that no password information was stolen - and later clarification that encrypted passwords were exposed

  Call me skeptical considering they said 4 months ago that they store part of their passwords in plain text: https://motherboard.vice.com/en_us/article/7xdeby/t-mobile-s...

• by ourmandave on 8/28/18, 2:27 PM

  Only 2 million?

  Seems low. I wonder if they'll adjust it upwards like every other data breach that happens every week since I can remember?

  Sadly, I don't even care since I was never a T-Mobile customer and they already have my entire life like f*cking Keyser Soze 50x times over.

• by bogomipz on 8/28/18, 5:08 PM

  And it was only 3 years ago that T-mobile that affected 15 million, which they largely blamed on Experian at the time.

  "On Sept. 15, 2015 Experian discovered an unauthorized party accessed T-Mobile data housed in an Experian server. Records containing a name, address, Social Security number, date of birth, identification number (typically a driver’s license, military ID, or passport number) and additional information used in T-Mobile's own credit assessment were accessed."

  T-Mobiles response to that incident was to offer customers 2 years of free credit monitoring service from Experian. That free service would have ended a year ago, just in time for the T-Mobile's next breach.

  Clearly nothing has changed at T-Mobile.

  https://www.t-mobile.com/customers/experian-data-breach-faq

• by RobertRoberts on 8/28/18, 2:56 PM

  Anyone have any good suggestions for what a customer should do when their service provider has been breached?

• by kodablah on 8/28/18, 2:56 PM

  > Ceraolo, who says he was not involved in the breach, says he was able to confirm that the hacker accessed T-Mobile via a vulnerable API.

  I want some details here. Just the other day we had a blog post lauding fairly open API approaches for client UIs (in GraphQL, but I see similar arguments elsewhere). Lock your shit down, don't give the frontend more than it needs, and if you're in a company with some type of ridiculous team separation where the backend has to treat the frontend as a customer that doesn't work for the company it's just a matter of time.

  Not saying this was a frontend API, just saying it's a frequent vector due to the lax auth requirements and "internal" query-like approach they often take.

• by akshayB on 8/28/18, 2:33 PM

  I think its about time US passes laws that any company that suffers a data breach is mandated to give a identity theft protection for 1 year to people who's information was compromised.

• by bogomipz on 8/28/18, 9:15 PM

  In looking at T-mobile's home page there is no mention of the breach. Wouldn't the responsible thing for them to do is post it somewhere high profile that their customer's might see it?

  Instead the notice is buried here which doesn't even appear to be a linked to on their home page.

  https://www.t-mobile.com/customers/6305378821

• by MrEfficiency on 8/28/18, 2:29 PM

  After being a Tmobile customer for 6 years(and leaving this year), I do not trust a word they say.

  Here is a list of unethical things they've done-

  >Claim UNLIMITED when restricting people at 10gb hotspot and 50gb data. Their depriortization is unusable, but they claim otherwise.

  >They sent their social media marketing team to astroturf in an /r/frugal thread critical of tmobile.

  >Their customer service person canceled a plan and added a plan when moving around numbers. I dont know if this was intended or an accident, but after 2 months of paying extra, I asked for a refund, the store wouldnt do it. I had to call. This was a 2 hour process.

  So 2M customer data? Says tmobile.

  So no passwords stolen? Says tmobile.

  I remember when they were 'the good guys'.

• by m52go on 8/28/18, 2:29 PM

  Purism's carrier-less phone cannot come fast enough.