TMobile confirms they store passwords in plaintext, don't see why it's a problem(twitter.com)
twitter.com
TMobile confirms they store passwords in plaintext, don't see why it's a problem
https://twitter.com/tmobileat/status/981418339653300224
10 comments
Is it okay to sacrifice security because some members of society are either too old/dumb/misguided/whatever to bother?
At what point do we just have to leave these people behind?
At what point do we just have to leave these people behind?
As long as the institutions are insured against fraud, they have a greater incentive for usability than security.
Yeah, but when they’re facilitating fraud...
Can we please pass a law to make it criminally negligent if you store passwords in plaintext?
This needs to end. Kinda like building a bank without locks. Insane.
This needs to end. Kinda like building a bank without locks. Insane.
How is it at all like building a bank without locks? It jeopardizes users who reuse passwords which has been a security faux pas since passwords. I feel like people dwell on this pattern of hashing passwords to show off that they know what hashing is. In the age of weekly leaks and multi gig dictionaries, assume your password is in a dictionary if not really long, high entropy, and unique to that site. Even the "gotcha" xss someone demonstrated on T-Mobiles site has nothing to do with this. If somebody has every password, they won. If they have your hash table, they still won. Yes, passwords would have to be changed site-wide, but you'd want to do that either way. At least since it's a phone company, they would know how to reach you. It's embarrassing to see another post of developers harassing a social media pr person.
Because it’s a minimum level of due care. Not meeting a minimum level is called negligence.
I think most people would agree that in this day in age, leaving passwords in plain text is like not even making the effort.
If you didn’t lock the doors on a bank, that would be the same thing - not making an effort, even though many criminals can pick a lock. So yes, the analogy holds up.
I think most people would agree that in this day in age, leaving passwords in plain text is like not even making the effort.
If you didn’t lock the doors on a bank, that would be the same thing - not making an effort, even though many criminals can pick a lock. So yes, the analogy holds up.
Here comes the damage control https://twitter.com/TMobileHelp/status/982334382806454272
Hoping this blows up. Time to short.
Hoping this blows up. Time to short.
I'm not entirely sure, this seems to be US only, we were talking about T-Mobile Austria.
At the end of the day, it's the same company.
That doesn't mean they have the same account management setup
According the T-Mobile USA CEO, "US customer care reps can't see passwords, nor are they stored in plain text."
https://twitter.com/bkurbs/status/982373984695042048
That's not true, though, because there is a "phone PIN" that you give to an operator when you need their help, and you can get it txted to you using a special SMS command.
Not a t-mobile customer nor in the US so can’t say I have much experience with their process to know if it’s “secure” or not. But the command to request a support code could trigger a code to be generated, salt and hash it (yeah I know hashing a 4 digit pin is pointless if their validity was longer than say 30 mins as you would have to breach and call up right away), stored an a DB along with the salt and not be displayed to the CS agent. When you call they then ask for the pin, enter it into their system and their system could then validate the pin entered by the CS agent by adding the salt and hashing and comparing what’s in the DB.
After a valid pin has been entered or X invalid tries by the customer service agent the customer needs to request another support pin.
Now this doesn’t doesn’t mean that the transmission of SMS is 100% secure but as they operate the network they could be in a much better place to validate that a request came from and was delivered to a phone and sim on their network (if the customer is on network and not roaming, but would be a bit of a shit customer support experience if you could only get support on network).
Just saying that the one time, limited lifespan support code system can be done securely so let’s not throw them under the bus just yet.
Edit: Using support pins delivered to the phone should only be treated as proof of being in possession of the sim and not proof of being the account holder.
After a valid pin has been entered or X invalid tries by the customer service agent the customer needs to request another support pin.
Now this doesn’t doesn’t mean that the transmission of SMS is 100% secure but as they operate the network they could be in a much better place to validate that a request came from and was delivered to a phone and sim on their network (if the customer is on network and not roaming, but would be a bit of a shit customer support experience if you could only get support on network).
Just saying that the one time, limited lifespan support code system can be done securely so let’s not throw them under the bus just yet.
Edit: Using support pins delivered to the phone should only be treated as proof of being in possession of the sim and not proof of being the account holder.
I'm wondering. Why would encrypting the password be any more worse than hashing ? If the private key of encryption is well kept, I don't see why they couldn't do that.
I understand though that no one being able to know the password except the user is utmost security, but why not encrypting it ?
I understand though that no one being able to know the password except the user is utmost security, but why not encrypting it ?
Long story short, an encrypted password can be decrypted. There is no reasonable scenario here under which this is preferable to a non-decryptable hash. This creates a scenario where the only possible outcomes that are added involve security breaches of password texts.
Presumably the application that accesses encrypted passwords in the database also has the decryption key close at hand. So if that application is compromised the attacker has access to both the encrypted data and the key to decrypt it. If the password is just stored hashed there is no way to directly decrypt it, you can only verify that a clear text string matches the hash. I'm not sure how relevant it is these days, it seems like there's enough CPU / GPU power that any password that's short enough to be practical can probably be cracked from it's hash quickly.
Because they do not need it for the task at hand. Password security has clear best practices which are also simpler to implement than encryption. The very fact that someone can somehow read your password is a breach of privacy.
People reuse passwords. The mere possibility of someone being able to see it is bad.
"Well, what if your infrastructure gets breached and everyone’s password is published in plaintext to the whole wide world?"
"What if this doesn't happen because our security is amazingly good? ^Käthe"
This is begging for it.
"What if this doesn't happen because our security is amazingly good? ^Käthe"
This is begging for it.
I can’t fault a low-level employee too much for enthusiastically defending their company. I can’t expect someone at that level to know about sound development practices.
What’s often lacking though is a clear path for reporting security issues to people such as this representative. They don’t have a process to flag something for the security team.
What’s often lacking though is a clear path for reporting security issues to people such as this representative. They don’t have a process to flag something for the security team.
If they're storing passwords in plaintext, the reason they don't have a process to flag something for the security team is probably that there is no security team.
“Excuse me? Do you have any idea how telecommunication companies work? Do you know anything about our systems? But I'm glad you have the time to share your view with us. ^Käthe”
And doubling down as well, that’s a bold strategy.
And doubling down as well, that’s a bold strategy.
> Do you have any idea how telecommunication companies work?
I know, and it ain’t fucking pretty. Plaintext passwords (and stupid customer service) are just the tip of the iceberg.
Telcos are right up there with internet-connected industrial control systems when it comes to security and the huge fallouts of a breach.
I know, and it ain’t fucking pretty. Plaintext passwords (and stupid customer service) are just the tip of the iceberg.
Telcos are right up there with internet-connected industrial control systems when it comes to security and the huge fallouts of a breach.
"challenge accepted"
Looks like someone found a XSS vulnerability at T-Mobile Austria website [1]
[1] https://twitter.com/fabricio_giglio/status/98236273592413798...
[1] https://twitter.com/fabricio_giglio/status/98236273592413798...
LunarPages, a large web hosting company, does this too and doesn't see why it's a problem. It's terrifying.
All the other sites on http://plaintextoffenders.com do
So does Plusnet in the uk
Here's the proof (it's my tweeter account)
https://mobile.twitter.com/alex_duf/status/61472768376378163...
Re-reading myself, I should have been more polite and less smug I think, the community manager never asked for that.
https://mobile.twitter.com/alex_duf/status/61472768376378163...
Re-reading myself, I should have been more polite and less smug I think, the community manager never asked for that.
The company sure did, I think you handled yourself fine.
Ag fuck Shoulda randomized
Whats stopping someone from creating a list of what strings trslate to each hash
Hashcat running on a Amazon p3.16xlarge (8 Nvidia Tesla V100 GPUs) does 115 BILLION salted SHA-1 hashes per second. Based on that, most weak passwords are cracked in seconds, even if you have per user salts.
https://github.com/crypto101/book/blob/master/Crypto101.org#...
While that was true before GPUs
>To a modern attack, salts quite simply don’t help.
Everybody should really move to key derivation functions (ideally scrypt)
While that was true before GPUs
>To a modern attack, salts quite simply don’t help.
Everybody should really move to key derivation functions (ideally scrypt)
What parameters do you recommend?
Is N=14, r=8, p=1 good enough?
Is N=14, r=8, p=1 good enough?
The usual answer is to choose the parameters in such a way that targets the largest verification time that your servers can stand. I'm not aware of a recommended minimum value. In general, though, you're making a pretty good choice by choosing bcrypt, and so long as you're using the above you should have far better security as compared to sha*/md5/etc
BTW this is called a Rainbow Table :)
Salt.
One possibility could be that they store only the first four characters plaintext, and keep a hash of the whole password (which is also bad).
I wonder how this feature came to be? What were those meetings like?
I wonder how this feature came to be? What were those meetings like?
Is this TMobile USA? I worked in engineering when they were still Voicestream Wireless. We were acquired by Deutsche Telekom and rebranded as TMobile. We had virtually no interaction with the European "T-Mobile."
Ummmm... the link in this thread leads to a verified "T-Mobile Austria" Twitter account, so what do you think?
Every T-Mobile (including the US one) is owned by Deutsche Telekom, but most of its subsidiaries are named differently. For example, Macedonian is called "Makedonski Telekom" instead of "T-Mobile Macedonia".
Every T-Mobile (including the US one) is owned by Deutsche Telekom, but most of its subsidiaries are named differently. For example, Macedonian is called "Makedonski Telekom" instead of "T-Mobile Macedonia".
God, they're making matters worse--
So, you never worked for us in Austria though. But thank you very much for sharing your opinion.
Thanks for stating that you seemingly haven’t understood what we’re trying to tell you.
Oh, I do get it. I hope you enjoyed my response
The problem with telecom companies is they have customers from a wide spectrum of technical capabilities. Their systems need to be able to support the baby boomer who calls support because they can’t remember their password, pin, or something...
I’m not defending these practices by any means, but these society-spanning institutions are facing challenges of balancing usability and security that many companies do not need to worry about.
If a company wants to implement a system like this, fine. But please tell me before I enter my password so I know not to reuse another password of mine.