8 ms·
World's Largest Wi-Fi Network Keeps Passwords in Plain Text
- kayoone 15y agoThey 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 15y agoAs 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 15y agoThere is a difference between a simple SQL injection and full filesystem access.
- dekz 15y agoThat 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.
- darklajid 15y agoSure. 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.
- kayoone 15y agoI 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.
- darklajid 15y agoThat's correct, but nitpicking. 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.
- kayoone 15y agoIts 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.
- Dylan16807 15y agoIt's pretty simple. There are three categories. 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.
- T-hawk 15y ago> 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.
- pr0filer_ 15y agoWhile 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 15y agoNo,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 15y agoRelated : http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html http://www.codinghorror.com/blog/2007/09/youre-probably-stor... + comments.
- throwaway64 15y agobcrypt has been ported to almost every language/framework in existence, USE IT.
- gokhan 15y agoHow do you secure the decryption key then? With another key?
- samuel 15y agoWith a hardware device as a smart card. 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.
- throwaway64 15y ago
- Nicolas___ 15y agoBeing 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.
- madflo 15y agoIf your software is able to decipher something, someone else could do the same.
- canop_fr 15y agoYes, because if somebody could make a select from the databases, chances are that he could also get the software used for deciphering.
- dekz 15y agoWhat 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.
- 16s 15y ago> 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.
- ordinary 15y agoReversible 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.
- ch0wn 15y agoI 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 15y agoIt'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.
- zobzu 15y agobuzziness, i like that :) way too much buzziness in all IT fields nowadays
- Xylakant 15y agoHow 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 15y agoShared-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.
- muyuu 15y agoUnwarranted 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 15y agoGarbage. 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.
- johnnygoods 15y agoHad 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.
- deleted 15y ago[deleted]
- agilebyte 15y agoExactly, 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.
- simonbrown 15y agoI 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).
- alvarosm 15y agoPassword issues aside, Fon is a scam by a con artist. Just stop using it...
- tsycho 15y agoCould you please elaborate why? I hadn't heard of Fon before, but it sounds useful unless you have compelling reasons.
- alvarosm 15y agoDepending 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.
- petenixey 15y agoMost 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 15y ago> 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.)
- lt 15y agoThe 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.
- mikeash 15y agoIt'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.
- va_coder 15y agoHow 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 15y agoThe 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 15y agoI 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 ;)
- jiaaro 15y agoThis 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.
- JTxt 15y agoYes. 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-feedback/suggestions/1154383-do-not-send-root-password-by-email- http://feedback.rackspacecloud.com/forums/71021-product-feed... 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/ http://plaintextoffenders.com/