
T-Mobile USA storing passwords in clear? - ewindisch
http://www.caseyliss.com/2014/5/27/tmobiles-clown-shoes
======
sp332
Yeah, it was reported to plaintextoffenders.com back in 2011
[http://plaintextoffenders.com/post/11763953868/t-mobile-
com-...](http://plaintextoffenders.com/post/11763953868/t-mobile-com-sends-
your-full-plain-text-password)

~~~
omervk
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 ;)

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

~~~
omervk
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).

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

~~~
dmdeller
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/](http://www.apple.com/iphone/LTE/)

[2]:
[https://en.wikipedia.org/wiki/United_States_2008_wireless_sp...](https://en.wikipedia.org/wiki/United_States_2008_wireless_spectrum_auction#Google_involvement)

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

~~~
justin66
> 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.

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

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

~~~
jerf
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.

~~~
JoshTriplett
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.

~~~
icebraining
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.

~~~
streptomycin
Amazon used to do it: [http://www.wired.com/2011/01/amazon-password-
problem/](http://www.wired.com/2011/01/amazon-password-problem/)

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

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

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

~~~
akerl_
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.

~~~
sillysaurus3
Insightful comment from Thomas on this topic:
[https://news.ycombinator.com/item?id=2582344](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._

~~~
akerl_
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.

~~~
mikeryan
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.

~~~
akerl_
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.

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

~~~
jerf
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.)

~~~
mellowfish
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.

~~~
dmdeller
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.

