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 ?
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.