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.
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 ?
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.
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.
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.
“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.
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.
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.
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
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.
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".
This is a really common technique in the UK, especially with online banking. “Enter the 1st, 4th, and 7th characters of your password.” Apparently the point is to prevent replay attacks.
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.
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.
44 comments
[ 2.8 ms ] story [ 88.6 ms ] threadHoping this blows up. Time to short.
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 understand though that no one being able to know the password except the user is utmost security, but why not encrypting it ?
"What if this doesn't happen because our security is amazingly good? ^Käthe"
This is begging for it.
And doubling down as well, that’s a bold strategy.
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.
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.
[1] https://twitter.com/fabricio_giglio/status/98236273592413798...
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.
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)
Is N=14, r=8, p=1 good enough?
I wonder how this feature came to be? What were those meetings like?
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".
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.
At what point do we just have to leave these people behind?
This needs to end. Kinda like building a bank without locks. Insane.
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.