T-Mobile USA storing passwords in clear? | Hacker News Reader

T-Mobile USA storing passwords in clear?

caseyliss.com

81 pointsewindisch39 comments

Yeah, it was reported to plaintextoffenders.com back in 2011 http://plaintextoffenders.com/post/11763953868/t-mobile-com-...

I'm one of the founders of plaintextoffenders.com and just came in to point that out myself. So happy you beat me to it ;)

Hey, is there an easy way to search that site?

Unfortunately, since Tumblr's search is completely broken, I would recommend searching for the domain name on Google with the modifier "site:plaintextoffenders.com".

For instance, to search for the site something.com, google "something site:plaintextoffenders.com" (sans quotes). I usually remove the TLD because many sites use lots of different TLDs (which we try to find when posting).

FTA: "So, now I’ll just give my money to Verizon, since I can’t give it to T-Mobile."

This, in the USA, normally comes at the cost of getting a Verizon-compatible device.

The Verizon versions of iPad Air, iPad Retina Mini, iPhone 5S and iPhone 5C are identical to those sold for AT&T and T-Mobile, and will work on any of those three networks[1]. (It's different/more complicated for older devices.)

Also, an agreement Verizon signed when buying their LTE spectrum from the FCC says that all Verizon LTE devices must be carrier-unlocked out of the box[2].

However, Verizon will refuse to activate any device that was not originally sold for use on its network (they use a unique device hardware ID for this). AT&T and T-Mobile don't do this.

Therefore, for maximum flexibility, buy Verizon versions of recent Apple devices. You can then switch to AT&T or T-Mobile (not Sprint), or back again to Verizon, at any time, as many times as you wish. This is what the author did[3].

[1]: http://www.apple.com/iphone/LTE/

[2]: https://en.wikipedia.org/wiki/United_States_2008_wireless_sp...

[3]: http://www.caseyliss.com/2014/5/21/tmo-vs-vzw-plans

> Also, an agreement Verizon signed when buying their LTE spectrum from the FCC says that all Verizon LTE devices must be carrier-unlocked out of the box[2].

> However, Verizon will refuse to activate any device that was not originally sold for use on its network (they use a unique device hardware ID for this).

Which is a violation of those FCC rules you linked to. It's monopolistic, shitty behavior.

> AT&T and T-Mobile don't do this.

> Therefore, for maximum flexibility, buy Verizon versions of recent Apple devices.

Or just avoid Verizon entirely. That way you won't be rewarding their bad behavior.

Yeah, I don't get why people use the big-name providers unless they have a family plan. Prepaid services like Net10, Straight Talk, Cricket, Metro PCS, Boost, H2O, Jolt, Redpocket, etc are less than half the cost of the bigger ILECs/CLECs and most of them are or have GSM offerings. I like that Net10 and Straight Talk give you T-mobile or AT&T sims to bring over locked phones.

My personal favorite combo at the moment is Straight Talk's "Unlimited" 30 day service for $45, combined with an AT&T Radiant pre-paid phone ($70 cash). This phone is the same specs as a new Moto-E smartphone but for half the price. (I find it hilarious that I can lose or break my phone 7 times and still pay less than for one iPhone 5)

Just to be clear, most of those are MVNOs -- they basically buy wholesale network access from the big name providers and resell it (and provide support) under their own name.

But they are much cheaper, usually.

Yeah, except Verizon is notably more expensive than the other networks, particularly T-Mobile. Verizon tacks on random fees into your bill that have no explanation. I would rather push T-Mobile to fix this issue than move to Verizon under the guise that I'm switching to something better. Nope.

I switched from Verizon to T-Mobile this year. My bill dropped from $180 to $160/month. That's with 2 lines, data and a new device installment plan. If you didn't have a new device it's at least $20 less per month iirc.

T-Mobile needs to work on their coverage in some spots, but that's supposedly coming with new spectrum purchases and whatnot.

I'd never go back to Verizon.

Virgin UK stores and sends the password in the clear. (Evidence: Whenever I call them on the phone, I have to read out my password, which is the same as the one you use to log in through the website).

TBH I'm not especially bothered by this.

It's entirely possible that the phone representative is entering your password into their system, which then checks it against the stored hash.

Try reading your password to somebody else and getting them to enter it correctly. Unless your password is terrible, you should find that you can tell the difference between them verifying a text field vs. entering it into the system pretty easily.

Yeah. I always use random passwords for the answers to "security questions", and it's fascinating to read them off over the phone. It's obvious that they're stored in the clear, because they don't care about (for instance) case or spacing.

The system could normalize the password (convert to upper/lowercare, remove spaces) before hashing it. It'd be dumb, but not as bad as storing in plain text.

I don't find that likely, though.

Amazon used to do it: http://www.wired.com/2011/01/amazon-password-problem/

Unless it's "CorrectHorseBatteryStaple"

That evidence isn't conclusive. They could be entering the password into an application that verifies with a hashed value.

If you're talking about virgin mobile, I remember reading that they have separate password storage for online and phone - is it possible that you've just set them to the same thing?

Note: This doesn't apply to their phone plan, just their mobile data only plans for iPads/tablets.

I couldn't reproduce this issue for my phone plan as it uses a different management site.

Was there actually a password requirement change? Entering the first 15 chars of my (previously set) longer password actually works. I assumed they were not properly validating (and truncating) the input. In any case this is not confidence inspiring.

Sending, not storing. Not much better, but you don't know whether it's encrypted at rest without actually getting into the code.

It doesn't much matter, given that their frontend either has the means to decrypt the passwords or plaintext passwords are decrypted behind it and passed through it. The problem is plaintext passwords existing on their systems; encrypting doesn't solve that.

Insightful comment from Thomas on this topic: https://news.ycombinator.com/item?id=2582344

When we're talking about passwords stored "encrypted" on customer-exposed applications, I agree.

When we're talking about passwords "vaulted" in non-exposed systems used for customer support, I have a harder time getting upset about it. I don't like systems that work this way, but I see the support/security tradeoff and it's a valid one.

It is likely but not certain that the site in question here did not go through the trouble of setting up a non-exposed secure password vault system for customer support people to use under supervision. Probably they do just store passwords in a column somewhere. But you don't know for sure whether they do.

I agree with the quoted segment, except that in this case they're sending back plaintext to users. As such, even if the passwords are being "vaulted", the plaintext passes back through the customer-exposed systems.

Alternatively however they're sending password reset links in plaintext to users. Either way if the communication chain is compromised so is the user's security.

No; compromising the password reset URL lets an attacker change my password for that service. It leaves a clear audit trace on my end (the email) and it doesn't grant them my plaintext password (way too many people reuse passwords, so a plaintext password is likely to be reusable).

If I didn't request the reset myself, the email alerts me to mischief. If I did, and they use the URL before me, the fact that the URL doesn't work when I use it alerts me.

Being able to send passwords back over email and/or view them as an admin does not mean they are stored in the DB in the clear. It is a fairly common practice to strongly encrypt passwords in the DB and decrypt them when it is necessary for admin personnel to be able to use them.

For practical purposes, that counts as "in the clear". Password should not be encrypted, they should be irreversibly hashed. (Preferably with bcrypt or scrypt or something meant for this use case; in this case I mean "hash" just in the technical sense of "irreversible", not that any ol' hash function is fine.)

For login purposes, it is indeed good to use hashes, this prevents timing attacks and the like. But I fail to see the harm in keeping encrypted passwords for admin purposes. It is very helpful in certain situations.

Where do you keep the decryption key?

If it's stored in the same place as the encrypted password, then you have gained no security over storing it in plain text.

If it's stored in a separate system, then you have substantially increased the complexity of the system, and in general, a more complex system is harder to implement securely.

If the server is hacked, the attacker can decrypt everything. Your users are going to have a lot of problems, and you'll have lost (rightfully) their faith in your service.

Even if only the database is compromised it is still worth trying to find the key to decrypt all passwords whereas cracking a salted 10000 rounds of scypt or bcrypt hash is just not feasible unless you're the NSA on the hunt for Edward Snowden

Even stipulating perfectly correct use of encryption libraries to encrypt passwords (which is, in practice, an enormous stipulation on its own), there is a significant correlation between having enough access to obtain encrypted passwords, and having enough access to obtain the decryption keys and routines. Yes, there are breaks where the hacker can only get one or the other, but that's such a tenuous "security measure" that it's hardly worthy of the term.

I think it should never be possible for admin personnel to access a users' plain password, much less necessary.

Given that you're an admin anyway, you don't need the extra privileges, and there are already established methods for dealing with resetting and recovering accounts without having to decrypt a password.

If it's ever "necessary" for an employee to decrypt and use my password, something very wrong is happening. That is not acceptable practice.

Yeah, most companies worth their salt (so to speak) make a point of saying their employees will never ask for your password. That not only frees them up to do the right thing with password hashing, but gives users a clear red flag when scammers call.

No, no, a thousand times no. Passwords should never be stored in a reversible format. Your users get shafted if you get hacked (more like 'when', these days). Here's a guide to handling passwords properly: https://crackstation.net/hashing-security.htm

Reply on news.ycombinator.com