

World's Largest Wi-Fi Network Keeps Passwords in Plain Text - legierski
http://blog.self.li/post/15236490991/worlds-largest-wifi-network-passwords-plain-text-fon

======
petenixey
Most people are arguing that a password shouldn't ever be recoverable and that
"even root level access should not grant you passwords".

This feels like shaky logic though. Hashing is a good defence against DB
harvesting but it doesn't stop a root level admin from listening to inbound
unencrypted logins. Prolonged root access is therefore still a viable attack
vector. The question is only how quickly you can harvest those passwords.

Other people are arguing that with sufficient decoupling and safeguards
between the encryption key and the database there is an acceptable risk
associated with storing a password.

Since services like Yodlee clearly do store passwords this is something that
companies do address. Could someone who really knows this area well please
describe how this is done in a way to minimise risk and how the risk compares
to a traditional 1-way hashing?

~~~
pingswept
> Hashing is a good defence against DB harvesting but it doesn't stop a root
> level admin from listening to inbound unencrypted logins.

Forgive my ignorance of web authentication, but aren't passwords hashed in the
browser before being sent to the server for authentication?

If not, why? It seems to me that it would be just as easy to hash on the
browser side as on the server side, but passwords are less exposed if you do
it on the browser side.

(Apologies for hijacking your thread, but I'm interested in the technical
details here.)

~~~
mrkurt
Passwords are rarely hashed client side. It doesn't matter, though, if you
have enough control over a server to listen to POSTs for unhashed passwords,
you probably have enough to inject some script and capture them on the client
side.

~~~
pingswept
True, but then you have to mimic the form submission without alerting the
user. It's certainly possible, but much less feasible compared to just passive
logging of all POSTs that have a field called [password|pw|pass|passwd].

I guess if you're targeting a single site the difference is small.

~~~
simonbrown
It would be just slightly more complicated to inject a script that POSTs back
anything typed into a password field.

Hashing passwords client-side would just provide a false sense of security.
Surely if it's worth doing it, it would be worth the cost of an SSL
certificate and the overhead of protecting (a minimum of) all pages and
requests handling passwords?

~~~
soumyadeb
I guess, client side hashing is not used because some users disable
javascript. Can't leave them out :)

------
ch0wn
I can't believe that this is still common practice in some large-scale
businesses. In my imagination of a perfect world I would never get in touch
with a user's plain text password at all.

~~~
dekz
It's never (almost) acceptable to be storing a users password in plaintext or
encrypted. Time and time again we see this and I'm glad most of the time there
is public outcry and the developers mostly respond with some variant of "We're
using <buzzword> now!".

The day we move away from simple username password authentication as a whole
is the day I can start feeling safe about my online accounts. Until that day
there will always be the one crypto 'expert' attempting to dissuade the angry
masses with his custom XES scheme which is super secure due to high amount of
buzziness.

~~~
Xylakant
How about any case where you're doing cram-md5 or hmac authentication? Because
one of the basic requirements of those authentication schemes is that both
sides have access to the _plaintext_ of the shared secret (a.k.a. password).

~~~
jrockway
Shared-key cryptography is the wrong choice for one-to-many communication.
Public key cryptography solves this problem correctly. (You use public key
cryptography to share a secret, which you then use as the key for whatever
secret-key crypto you want to do.)

Consider the case of VPNs. When you have two trusted routers to connect, you
use a shared secret. That's because both routers are in the same secured
datacenter environment; both are equally trusted. When you have users
connecting to your VPN, though, you issue each user a unique certificate
(which is a crypto-based identifier). This is because you can't trust
individual users the way you can trust a server in your datacenter.

~~~
Xylakant
I'm not talking about vpns and such but more about (rest-)api authentication.
About what amazon uses to generate signed urls to S3-Stored files. It's an
hmac used to create a signature using a pre-shared secret and some properties
of the request (mainly the url) as input. The PSK must be available to both
parties.

------
JTxt
Yes. It's way too common and sickening.

I first reported a similar issue to Rackspace Cloud 2/2/2010:

[http://feedback.rackspacecloud.com/forums/71021-product-
feed...](http://feedback.rackspacecloud.com/forums/71021-product-
feedback/suggestions/1154383-do-not-send-root-password-by-email-)

They still email new vps ROOT passwords with IP addresses. (At least they said
they would fix it about 2 months ago.)

Perhaps there's not enough people that are bothered by this? There is this
site: <http://plaintextoffenders.com/>

------
Nicolas___
Being able to provide you with your password in plain text doesn't mean it's
stored in plain text. There are very efficient and secure encryption
algorithms that are reversible, out there.

Of course, sending passwords in an unencrypted email is bad practice, but
that's another story.

~~~
rmc
'plain text' here includes encrypted non-hashed formats. Passwords should
always be stored hashed so the original site (or any attacker who gets them)
can get access to the password.

And if it's possible to automatically reverse the encryption, then it's not
far off plain text.

~~~
seabee
More specifically, it raises the bar from requiring a database dump (SQLi) to
also requiring the encryption key (filesystem access or discover it yourself
by cracking weak passwords).

When each line of code you write is a point of failure, I would rather trust
an algorithm (e.g. bcrypt) which is immune to all of them rather than
reversible encryption which needs only two.

------
johnnygoods
Had a similar experience with Dreamhost about 2 years ago. I sent them an
email pointing out the insecurity of sending passwords in an unencrypted
email, but they seemed to feel that their customers "appreciated" the ease of
password recovery over security.

~~~
simonbrown
I remember reading an idea of a "login via email" link. This would be probably
be even more convenient than a password reminder and just as secure as a reset
link (assuming it only works once and has a time limit).

------
kayoone
They can still have some kind of encryption algorithm in place to
encrypt/decrypt passwords in their database. That said, sending the passwords
out in plain-text via Email isnt particularly secure either.

~~~
darklajid
As was discussed here over and over: That basically results in the same thing.

There should be no feasible way to read the passwords of your users, ever. If
you store them 'secure' in a reversible way it doesn't matter much if you use
rot13 or state of the art crypto. Anyone getting access to the database can
probably get the key as well.

~~~
yuhong
There is a difference between a simple SQL injection and full filesystem
access.

~~~
darklajid
Sure. That doesn't change the fact that storing passwords in a reversible way
is a no-no. Advantages? Zero (I'm sure I'll get references to okcupid now..).
Disadvantages: You are responsible for sensitive data and have lots of ways to
mess it up.

And I didn't even touch problems that aren't related to outside attacks at all
(You know, I don't even _want_ you or your customer support guy to be able to
look at my password if you browse your customer database).

You do yourself a major disservice if you implicitly take responsibility for
knowledge you shouldn't ever need in the first place.

------
pr0filer_
While sending passwords in plain text via e-mail is something that should be
frowned upon, the e-mail itself is not evidence that they store your password
in plain text.

~~~
Kesty
No,the pasword could be crypted in the DB and decrypted for the recovering
password mail.

Still not the best solution, hashed password (with a salt) are way more secure
if your password happens to be 12345.

~~~
madflo
Related : [http://www.codinghorror.com/blog/2007/09/youre-probably-
stor...](http://www.codinghorror.com/blog/2007/09/youre-probably-storing-
passwords-incorrectly.html) \+ comments.

------
alvarosm
Password issues aside, Fon is a scam by a con artist. Just stop using it...

~~~
tsycho
Could you please elaborate why? I hadn't heard of Fon before, but it sounds
useful unless you have compelling reasons.

~~~
alvarosm
Depending on the option you choose, you're giving away your internet for free
or for too little. Meanwhile, fon is profiting fully. If it's for free, well,
sure you have free access too but you're still giving much more than you're
taking in most cases.

------
va_coder
How about playing the devils advocate. How many people here own homes without
a security system or don't use that system every day? It can be a pain turning
the system off and on every time you leave the house.

If you were in the physical security business and knew of all the violence
that occurs in society you would think it's crazy to not own a security system
and not use it every day.

Now put yourself in the shoes of a non technical person and you can see how
convenience sometimes trumps security.

Sidenote: I love asking people in the computer security business about what
kind of physical security system they use at home. Most don't use one.

~~~
pkteison
The reasons these are not the least bit comparable are

a) Economies of scale - breaking into houses happens one at a time. Breaking
into unsecured computer systems often lets you affect millions of people at
once.

b) Jurisdiction - if a thief breaks into your house, he's local, and your cops
can find and prosecute him. With computers, this is almost never true.

c) Personal Choice - You can choose whether or not to use an alarm in your
home. When you use somebody's service, you have no choice over whether they
use a level of security you agree with.

d) Personal Impact - When you choose to use an alarm in your home or not, that
is a decision that affects -you-. When a service chooses to be insecure or
not, that is a decision that affects -their customers-.

In short, they are nowhere near equivalent. If you want to make decisions for
yourself on convenience vs security, that's cool, but don't equate that to a
company making decisions on behalf of their customers.

~~~
va_coder
I agree they are different. Not having a physical security system may lead to
violence against your family. Far more serious than almost any plain text
password.

You got a lot of time at work to right 4 points as to why you think my point
is wrong ;)

------
muyuu
Unwarranted paranoia.

The worst thing that can happen here is that somebody connects to your wifi.
If someone can read your email and is in the vicinity to connect to your wifi,
the least of your problems is that he or she does connect to your wifi.

Also, as pointed out by others, this doesn't mean it's stored in plain text.
Any time you set a password it travels in plain text (typically - and
hopefully - via a secure connection) and it arrives to their server in plain
text. You are never sure they are immediately storing it properly encrypted in
a DB. They can also be doing things like sending it in emails or storing it
elsewhere. If you cannot trust your password to whoever is storing it you are
basically f __*ed. BTW, what do you think they might do whenever you enter the
wrong password in the wrong site? (for instance, your email password).

~~~
jrockway
Garbage. The problem is not the transport-layer security. Transport-layer
attacks are very difficult to implement. What is risky is what happens when
someone gets access to the database and does "SELECT * FROM user". This is a
very realistic threat, and with properly hashed passwords, gives an attacker
no useful information. With plain-text passwords, though, they now have carte
blanche to try the credentials at other sites, and steal someone's entire
identities.

Yes, it's bad if you use the same password everywhere. Yes, it's bad if
someone man-in-the-middles you. Yes, it's bad that arbitrary web users can run
arbitrary database queries. But the point of robust engineering is to protect
a system from many failures. If your passwords are stored in cleartext, your
system is less safe overall than one that stores the passwords hashed. And
because it's so easy to hash passwords, and because it's so damaging to your
users to leak their password, it's generally considered Pretty Fucking
Incompetent to keep passwords around in cleartext.

~~~
muyuu
I haven't defended anywhere in my post stored passwords in plain text. Maybe
you replied to the wrong post?

~~~
jrockway
You mitigated its importance by saying:

 _Unwarranted paranoia... Any time you set a password it travels in plain text
(typically - and hopefully - via a secure connection) and it arrives to their
server in plain text._

This is true, but data in motion is less vulnerable to compromise than data at
rest (due to how the Internet works and how web applications are programmed),
and so the conclusion "unwarranted paranoia" is wrong. The paranoia is
warranted.

~~~
muyuu
The main points from my point of view, and the reasons I think this is
unwarranted paranoia:

\- not a critical resource : if your email is compromised, the importance of
that makes this insignificant. It's also a local resource, cannot be exploited
from afar.

\- just because they email it to you doesn't mean it's in plain text. It can
be symmetrically encrypted, or (not in this case) it can be sent prior to
storage.

Not all accounts require draconian password policies. In fact, the abuse of
these requirements _encourage_ users to make really bad decisions regarding
passwords, like reusing them or having them stored in a central repository.

