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?
What I find interesting about the debate regarding password storage ethics is the question, "What is a website's ethical responsibility in regards to a user's password?"
On the face of it, one could argue that the extent of a site's ethical responsibility ends at their IP address -- i.e. a site is only responsible for protecting one's password to the extent that it reasonably protects the user from harm resulting from someone else using their credentials on the site. For example, under this scenario, HN's responsibility would be to take reasonable steps to protect my password in accordance with the level of harm I would experience should my account be compromised. HN's "reasonable steps" are different from those of Bank of America, and emailing my password in plaintext would not shock me (even if unlikely).
However, there is a tendency for people to argue that the extent of a site's ethical responsibility is to protect the user from harm elsewhere on the internet - the logic of course being that many people use the same password for HN and BOA. In some sense, this argument is premised on websites having some level responsibility for general welfare of their users (i.e. a website's responsibility towards users extends across the entire internet to some degree).
A weakness of that argument is that once general welfare of the user is the standard, plaintext storage of a password may promote the user's general welfare to a greater extent than more secure measures - security is just one criteria in regards to utility. A house with few windows is usually more secure but often less healthy for its occupants.
Although technical considerations are important, the issues surrounding password security methods for most sites are social: trivial passwords, password reuse, and "lost" passwords. Holding all sites to the standards which apply to sites with fiduciary responsibility such as banks or corporate IT centers is, in my opinion, somewhat asinine. Every web service does not need to be locked down, and good architecture will balance security with commodity and delight.
How do people try to justify storing passwords in recoverable form? So that they can remind users of the old password.
How do they actually send the reminder? By email.
But email is not secure, you should always assume that someone is eavesdropping on your email. Far too many users reuse a password from one service on others, so sending a password in email is a huge violation of trust.
Storing passwords in plain text (or using an encryption method) and sending password over email are two distinct issues.
I think storing passwords (and not only hashes of passwords) might be a good idea if it is harder for the attacker to recover the passwords than to gain root access to the http/database server, however, I would NEVER send passwords in emails (not even newly generated passwords). A simple solution is to send a one-time login link, and have the password displayed in the browser, over a https:// connection.
There is still a small possibility of stealing the password (someone intercepts the email and clicks on the link before the legitimate user does), but at least the user would become aware of it (his link wouldn't work any more).
One issue is that even if the password database is more secure than root access on the server, having the database at all means that it's possible to steal the entire thing in a small amount of time and in a way that may be difficult to detect. An attacker with root access on the server would have to keep the exploit open to continue gathering user credentials. And I still don't see what convenience having the password database offers.
One-time links are definitely the right way, though I think it's better to give the user a new password dialog than to tell them a randomly generated password.
> 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.)
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.
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.
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?
Not even that. You simply have to delete the JavaScript that hashes them on the client side, and have the browser send them unhashed (which is the default behaviour of HTML forms).
The point of hashing is from the difficulty of reversing it; generating a string that when hashed matches that value should be difficult. That way, even if someone has access to the hashes, he is unable to login - he needs the password.
If you accept the hash from the client, anyone having the hash is able to login, making hashing pointless.
It's not hard to fix that. You have the server send the client a random salt each time. The client then sends back a hash computed with that salt, and the server doesn't accept the same salt more than once. Done right, the server never sees your plaintext password and replay attacks still fail.
The difference between hmac(salt,hash(password)) and hash(password) is trivial when the salt is known. It doesn't matter that the server only accepts the salt once, if the server is willing to produce another salt for the next attempt. If the server limits the number of salts it will produce in a given timeframe, it might as well limit the number of attempts to begin with, and so there's no point in "double hashing."
The goal, I believe, is to prevent recovery of the plaintext password so that it can't be used to gain access to other accounts with the same password. The double hash prevents an attacker from ever obtaining that plaintext password.
The issue was, I believe, in preventing a remote attacker who knows the hash from using it to authenticate[1]. That is why passwords are transmitted in plaintext then hashed and validated on the server side. You should never trust the client to perform your cryptography for you, because you have no idea who--or what--the client is. No amount of obfuscation can alleviate that fact.
Your comment about not trusting the client confuses me. You don't have to "trust" the client to do cryptography for you. You simply define the cryptography it has to do, and if it doesn't do it, then it doesn't produce what you need to log in.
This is not an unusual practice, either. For example, any time you log into a remote computer using an ssh key, your ssh client is performing cryptography to authenticate you with the server. There is no problem in doing this, because the only way to perform the cryptography such that the authentication is successful is to have the right secret key. You could certainly write a custom ssh client that does some different cryptography, but that would be pointless, as the result would be an inability to connect.
There are, I think, two goals at play here. One is what you linked: preventing replay attacks. That is fairly easily solved by doing a double hash with a randomly generated salt. There is no problem in "trusting" the client to do this, because if they don't do it the way you specify, they don't produce the correct result. The only (feasible) way to generate a result that lets you log in is by combining the random salt with the correct password. This is important because otherwise an attacker could sniff your traffic and then impersonate you.
The second goal is in not having your password exposed if the site's database is compromised. Related, it would also be nice to not have your password exposed if the site is compromised and the attacker is watching incoming connections.
SSL solves the first goal, of preventing replay attacks. Not having your password exposed if the database is compromised is solved by hashing passwords. However, if you send the password in plaintext (or encrypted in such a way that the other end can retrieve plaintext, as with SSL) then the last, related goal fails: an attacker with total control can grab your password if you log in during the time he has control.
By doing hashing on the client, you can prevent that, and when implemented properly it can still avoid the rest.
The situation we were discussing is not analogous to the SSH situation you describe because the key, namely hash(password), is not secret (the attacker knowing it was the premise of the scenario). It doesn't matter what mumbo-jumbo (not an insult, just an illustrative phrasing) you require the client to do, an attacker can do it just as well. The system is still vulnerable to attacks (which are not exactly replay attacks by the strict definition, but are still trivially equivalent) because it depends upon the key being secret, which is not the case.
Hashing on the client does not satisfy the first goal and sending the password in plaintext does not satisfy the second goal. A different solution altogether would be necessary to satisfy both goals.
I'm still confused. With my proposed system, how do you perform a replay attack (or the trivial equivalent thereof) without access to the server's database?
There are two scenarios here, and I think we are each discussing a different one.
The first scenario is where the attacker obtained the hash from the wire which is what I think you're assuming to be the case. Then yes, double hashing would protect against replay attacks.
The second scenario is where the attacker obtained the hash from the database which is what I assumed to be the case. Double hashing would not protect against these attacks (which are not, strictly speaking, replay attacks).
I'm not interested in belaboring this point any further, because I think you came up with a better solution to both issues in another post[1].
When the attacker obtains the hash from the database, this does indeed let him carry out the rough equivalent of a reply attack, but it doesn't let him carry it out on any other site. The reason you don't want passwords stored (or transmitted) in plaintext is so that an attack doesn't compromise the user's accounts everywhere. This double hashing scheme avoids that, but yes, leaves your account on this one site compromised if the database is copied.
Glad you liked the other scheme. It's more complex, but seems better. I really have to try it out at some point.
IMO, what would be really ideal is the following goal
- An attacker who has access to the server database and also is watching the network traffic should not be able to impersonate the client(user) later.
The double hashing scheme doesn't achieve this. Since hash(password) is stored in the server DB, the attacker can just copy that and use it to login later. He just needs the hash, not the plain-text password to compute what the server asks for during authentication.
The above goal can be achieved by public-key cryptography. Its just like SSL working in reverse - server authenticating
the client/user based on user's private key. The practicality of assigning a private key to every user is a different matter though :)
Normally, private-key authentication doesn't work for most of these things because users expect to be able to log in with something they can remember, and any private key of decent strength is too long.
How about this for a login solution? For each user, you generate a private key and keep it on the server. But, you encrypt that private key with their password, and you don't keep that password or anything derived from it anywhere.
To log in, the server sends the encrypted private key and an authentication challenge to the client. The client then uses the password to decrypt the private key and respond to the challenge. Replay doesn't work, since the response is only good for that challenge. Watching the traffic on the server doesn't work, since you can only get the encrypted private key and the response. Snarfing the contents of the database doesn't even help, since you only get the encrypted private key.
For bonus points, I don't know if this is actually possible, make it so that it's impossible to tell whether a particular decryption of the private key is valid without using it to respond to an authentication challenge and sending that response to the server. This way it's impossible to brute-force the encrypted key, substantially mitigating problems with weak passwords.
Of course, I may have missed something obvious here....
Also, for your bonus question you can do something like this.
Enc-Priv-Key = Priv-Key XOR Trun(Hash(password))
where Trunc = Function to truncate to the length of the priv-key.
So, every (Enc-Priv-Key,password) pair combination is valid - it gives you a valid Priv-Key. Also, if you break into the server, you have Enc-Priv-Key and Pub-Key. Enc-Priv-Key is a random number assuming your hash(password) is random (which isn't true if your password is short but let's say it is). So, having Enc-Priv-Key shouldn't give you any information about Priv-Key.
Is every arbitrary sequence of bits a valid private key, though? Something tells me that it may not be, but I can't remember my RSA quite well enough to say for sure.
I suppose that even if not every sequence is valid, enough incorrect sequences will still be valid private keys to make a brute force attack impractical without server cooperation.
I was actually thinking that the client would store the private key somewhere (e.g. in an HTML5 browser:)) but what you described is brilliant and definitely works.
Something like that is not used probably because the bigger problem is clients getting hijacked, not servers.
Right, and when servers do get hijacked it tends to be a quick in and out, so compromises based on transient connections aren't much of a concern. Sending passwords over SSL with a good password hash on the other end solves everything if you assume that the attackers won't stick around listening on incoming connections.
Now I really want to implement my scheme using JavaScript crypto. If only I had a web site that needed secure logins.
what you're describing is basically cram-md5. Which is nice if you're using plain http and don't want the password to travel over the wire. But both sides need the plaintext password. Otherwise the hash of the password replaces the password and is just as good as an authentication token as the password itself, i.e I just need the hash to authenticate, not the pw itself.
But at least you can't recover the password to log into other sites. I thought that the main goal here was to avoid the scenario where an attacker recovers your password on one site and can therefore log in as you all over the place if you made the mistake of reusing it (as most people do).
The server needs the plaintext password once, to generate a salted hash. From then on, it can send the salt and a challenge to the client. The client hashes the password, salt and then hashes that with the challenge and sends it back to the server. The server hashes the challenge with its salted hash and they should match.
This still has to be done over SSL because otherwise the JS doing this on the client side is subject to MITM.
well. but if you're using ssl then you could as well send the password over the wire and have it properly stored with bcrypt on the serverside. And if I control the application I can make the client emit a plaintext password by sending an empty salt. The result is a simple hash of the password which can be reverted with a regular rainbow table. If the client uses bcrypt, I send a work factor of 1 and construct a proper rainbow table (that's rather simple). Or I could just have the javascript send the password in plain. So there's no gain here.
For the vast majority of sites storing passwords in the clear is a bad idea.
However sometimes you need to store sensitive data. Generally this is done with hardware security modules which rotate encryption keys in a periodic basis. Access to the sensitive data is also audited.
Risk can be minimized. It just comes down to if it is worth if for your business. PCI DSS is just one example of minimizing risk.
Uh... the code in question is retrieving those passwords and emailing them over unencrypted SMTP. How is that design improved by the use of key rotation or "hardware security modules"?
By using a HSM you store the encryption key on a separate hardware device. I am already assuming that if you want to implement something like this you will encrypt the passwords. Thus the problem is knowing where to put the keys.
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.
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.
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).
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.
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.
That plaintext of the shared secret doesn't have to be the password, it can be some other authorisation token which acts as a first level of auth before a password hash scheme is used. As I said, there is _almost_ never a good reason for storing the passwords digested or encrypted.
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.
'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.
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.
What do you mean by secure encryption algorithms which are reversible? Encryption implies an operation in reverse order to exist, otherwise it is in essence, digesting.
It's always (almost) completely unnecessary to store encrypted passwords.
> What do you mean by secure encryption algorithms which are reversible?
AES-256 symmetric encryption (as one example) is designed to be reversible while a SHA-512 hash is not. What does reversible mean you ask? It means that plaintext can be made into ciphertext and then back to plaintext again. It's designed to be undone/reversed by the party that holds the key/password.
Reversible does not mean the same thing that symmetric does. Encryption, by definition, is reversible. If your algorithm is not symmetric, you will not be able to decrypt it with the same key as you used to encrypt it, but it would still be reversible. If it wasn't reversible, it would be data destruction (ie, Unix shred) or hashing (ie, SHA). "Reversible encryption" is a pleonasm.
While it's possible that this is true, it's still exceptionally bad practice. Reversible encryption, particularly when stored server-side, which is almost always going to be the case, and even if using a HSM, isn't entirely different from plaintext when the attacker holds the keys.
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.
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).
Exactly, as the admin you see a potential vulnerability, as the end user, you just don't want to remember a password and as an attacker, you see an opportunity.
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.
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.
I know, still it makes quite a difference to simply storing the passwords in plain text outright. Dont know why i get downvoted for this, i know that its not best practice but we simply cant assume they save the passwords in plain-text based on this info, which is what the articles main point is.
For all I care (and I guess the down-voters in your case think similar) that's just the same thing, really.
If you can reproduce the plaintext in any way you're guilty of storing plaintext passwords. Arguing about the terms doesn't change the problem nor the perception in this humble author's opinion. The article is ~correct~, good enough, works for me.
> If you can reproduce the plaintext in any way you're guilty of storing plaintext passwords.
Although I get your point, this statement is a bit too broad. What about brute force? Get enough parallel hardware running fast enough and you can eventually reproduce the plaintext for any ciphertext or hashtext.
Besides brute force, there's also dictionary and rainbow table attacks to consider. Are you guilty if the plaintext can be reproduced by a table lookup? Are you guilty if you properly salted, but the salt storage was compromised too? Are you guilty if you enforced password-complexity requirements to foil a rainbow table, which led to the user writing down KuteK1tty!123 on her Post-it and a co-worker stole it?
These aren't easy questions, and there's no magic solutions, just a cloud of less-bad options.
Since we're on the subject of nitpicking, it's worth noting that under such circumstances you can produce a plaintext, and you can produce every plaintext of a certain length, but you cannot with certainty produce the plaintext unless there is only one possible plaintext meeting the constraints of the system.
Its not that black & white either. Many people still use MD5 which isnt reversible but still easily crackable, so where to draw the line ? Nobody would know if they were using MD5 but the risks would potentially be the same.
The point is, we do NOT know if FON is saving passwords in plain-text based on the provided info.
1. plain-text or plain-text equivalent: you can access the original passwords in microseconds
2. lousy hashing: you can't tell what the password is immediately but it's computationally feasible to figure it out
3. good hashing: you can't figure out the password
The only time you ever need to distinguish plaintext from plaintext-equivalent is when you have a partial data breach. Good hashing is safe even under a full data breach.
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.
That isn't the point he is making though, there is a non zero probability of an application attack resulting in the decryption of the passwords. The attack vector is now on at least 2 fronts if it stores encrypted/plaintext passwords; the login system and the password reminder system.
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.
Everyone here implies that passwords are stored in just another table of the database. There are other more sensible scenarios. For exmaple: authentication servers which talk to the front end using CHAP, well behind internal firewalls and with dedicated hardware which holds the private keys and encrypts/decrypts the data.
This has been discussed before. The ability to recover passwords has bussiness value, so at the end its a tradeoff between risk and money.
if your application can access the password, there is a very high chance so can somebody that has application level access to your machine can just do whatever your application does, you cannot hand wave that away with "smart cards", "encryption" and "firewalls".
Having a stored password in any format except for one way hashing is a massive and _unnecessary_ liability.
Before you take the time to reply with another convoluted shell game of keep the password away from the hacker, consider the actual necessity and value of a recoverable password. Does it really outweigh the massive security problems?
Anyone that has application level access to your servers can still get your password very easily, for example every time you log in. Why is having a means to decrypt the password so much worse?
You misunderstand the point of password hashing, it is not about preventing people from breaking into the machine containing the hashes, it is about limiting the damage they can do with millions of passwords as a result of doing so. Most people do not bother to change their password from service to service, login to login. So instead of a breech on one system, you potentially have a breech on thousands.
Not if you are doing your login correctly. You shouldn't need to send passwords to a server to login, just hashes of passwords. That's the point. If your server ever needs to see a real password after the account is created or the password is updated, you have introduced a new vector of attack.
Done correctly, login is an exchange of hashes, not encrypted passwords.
A simple way to do this would be to send a unique, random salt S for every login, and the user would reply with e.g. sha1(password + S). However, to be able to check that the answer is correct, you would need to know the user's password, in plain text, which brings you back to square one.
To securely do this, you would need commutative hashing functions, i.e. hashing functions f(x) and g(x) such that f(g(x)) = g(f(x)). Actually, to be completely safe, you would need to be able to generate a whole (preferably infinite) family of commutative hash functions g(x), a random one for each login. I have no idea if such functions exist, more importantly, if they are known, it's an interesting idea actually.
In most cases, anyone that has application level access can already do the things an ordinary user needs authentication for. The password is irrelevant, unless you want to find it out to access another system you don't already have permissions for.
You say it's _unnecessary_ and "there's high chance of someone accessing the password". Under that premises, obviously, it's foolish not to use one-way hashing. Mine is that may provide value and there are sensible ways of mitigating the risk, miles away from accessing the data directly from your application, by using software and hardware designed and implemented by security professionals. That's all.
The problem is, the application fundamentally HAS to be able to access the password, either through direct comparison to authenticate, or some mechanism to mail out the password. This fundamentally cannot be separated, that's why hashing is always better, and why the risks are nearly impossible to meaningfully mitigate.
How does that statement hold true? I can easily think of an application that just uses a simple service on a separate box behind a firewall that only accepts an email and then sends the password. Authentication works via CHAP or any other auth protocol. The application itself never has access to the plaintext password.
Granted, an attacker may gain access to the app-server and then proceed to crack the authentication server, but he could also just rig the application to pass on any password it receives. Just about as good as cracking the auth server and far easier to do. (Added bonus: works for hashed passwords just as well).
Granted, this may seem tons of work for a simple solution, but from there on, it's a business decision.
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.
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.
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.
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 ;)
This is not a good analogy -- a more apt comparison to a network admin not taking correct precautions with user data is a storage facility not activating it's security system every day. These organizations are dealing with other people's security, not just their own.
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).
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.
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.
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.
If someone can execute a "SELECT * FROM user" query, it's highly likely that they can also intercept login form responses to retrieve plain text passwords.
Not true in practice. The select statement is often tacked on to some other database query. To intercept login form responses would require the ability to run "real code" rather than just ask the database things.
The reality is that most programmers do not call eval("code from the user") but they often call sql_query("code from the user").
The worst thing that can happen here is that somebody connects to your wifi.
Unless a negligible amount of the 4 million users accidentally reused the password for other services as well. Which probably makes 3.9 million victims.
Also, as pointed out by others, this doesn't mean it's stored in plain text.
That does not matter much. If FON can extract it, an attacker can extract it as well, thus rendering it insecure.
That would be accurate if the article did not state that he used the "Forgotten password" feature to recover his password. Also, sending a password unencrypted over email even before database storage is just as concerning. What if I fat-fingered my email address?
That's right. In this case they have it in a recoverable format somewhere (symmetric encryption is not as useless as many seem to think). Thanks for pointing it out, I thing I skimmed that part this morning.
However, it is still just your wifi connection which has to be locally accessed still and not ultra-secret password. IMO the policy is not problematic and it can save you the need to write it down somewhere, which for a local-only resource might be a worse alternative.
> The worst thing that can happen here is that somebody connects to your wifi.
No, the worst thing that can happen is that someone you trust uses the same password for this service and their google account, then the attacker who hates you uses their latitude access to find where your kids are and kidnaps them for money.
Sorry... went to far. A more sane version is: someone uses the same password for their {online retailer} account. Attacker uses that to login and buy themselves a $X000 present using your saved CC details.
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?