T-Mobile Database Breach Exposes 2M Customers' Data
databreachtoday.com
databreachtoday.com
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.
Imagine if this were to happen to a journalist or politician. The stakes are quite high.
My wife used this for her business since it was free at the time. It cost her literally thousands of dollars of missed/unconnected calls and dozens of hours of customer service.
I'm not sure that the lack of repercussions is a reasonable excuse. I know companies will use it. I know we might throw our hands in the air and just say its a fact of life. But it doesn't have to be.
https://motherboard.vice.com/en_us/article/a3qpk5/t-mobile-h...
If you're asking why they don't notify all customers of the breach, well, you don't spread bad news you don't have to.
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.
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.
edit - just want to state that if they disallow special characters it really is a terrible policy, my point is just that resetting your password isn't proof they are stored in plaintext
Maybe they could have analyzed the plaintext password and stored information about the types of characters it contained and number of characters. Then they salt+hash the plaintext password and store the resulting hash. Now they know a little about the characters and length of the password without knowing the password itself.
Again, I doubt they did this.
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...
(T-Mobile Austria has since figured out that storing this is a bad idea and promised to change how they do it. Dunno what they have done as I'm not a customer of them nor live in Austria, I just remember the the shitstorm on twitter about it.)
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.
"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.
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.
Instead how about companies have complete financial liability? That way they'll need insurance, and their premiums will skyrocket if they get breached.
> T-Mobile declined to comment. "We don't discuss publicly how we encrypt passwords,"
That is unacceptable, data breach or not.
They should instead have a minimum fine per-user that gets paid in cash directly to the impacted individuals. Paying $10 x 1M accounts would make businesses wake up to this problem much faster. Maybe even have the fine be tiered based on the level of data that was compromised:
Email - $10
Hashed Password - $25
Plaintext Password - $100
SSN - $500I'd rather them give basic compensation to anyone with breached data (even if it is $10) in addition to covering the costs of anyone who had problems after the breach. The first year, I'd think it would be best if the consumer didn't have to prove it was their fault as that could be too much of a burden for folks.
I'd give an exception for companies that went over and above on their own security and still got breached. After all, security doesn't make one completely safe (much like places can still get robbed), simply less likely.
Instead the notice is buried here which doesn't even appear to be a linked to on their home page.
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'.
Your mistake is the illusion of choice. There are no good mobile carriers, only the least worst.
Workaround: Pay monthly, resist their pressure to sign up for auto-pay. Shift bill payment chore day to third week of each month, to deal with T-mo's 17-day window between billing and overdue dates.
All that said, from what I've seen, the competing providers are worse still.
(In general, though, SMS 2FA is a bad idea; device, not SIM-based, things like Google Authenticator are much better and render SIM hijacks toothless as far as 2FA is concerned. You're still hosed with respect to your payment method, address, carrier credentials, etc. of course.)