"troperhandle" and "mazeltov" are transferred and stored locally in plaintext, not even salted, and the authentication system apparently uses plain POST, Fighteer.
While I'm usually the first to jump on the "security is a process, users should learn" bandwagon (judtifiedly), the truth is even if users are in an enough position of knowpower to secure their computers proactively or reactively , that can very likely not secure their connections. Encryption at the backend does not transfer security to the frontend — companies that want to offer a safer frontend use SSL or an alternative.
Not saying that the current system is bad, considering that there's not much else to protect than the actual handle and that for most cases it's easy to recover (however, I foresee cases where someone will have their account compromised, used for trolling, leading to FE's favored strategy of Orwellian Retconning things, like posts, out of existence, which means content that can not be recovered), but pointing out that you shouldn't be claiming to offer security at a level that you're not and shifting blame on users for potential failures. That's Business CS 101.
Fanfic Recs orwellianretcon'd: cutlocked for committee or for Google?Who's claiming to offer security that they aren't? I don't recall Eddie ever making any such claims.
Surely we could SSL the login process, but someone's gotta spring for the certificate.
"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"Yes, but the wiki should ensure its users security and not make it a risk to make an account here
edited 12th Aug '11 8:11:50 AM by juancarlos
"My life is my own" | If you want to contact me privately, please ask first on the forum.What risk? You have no personally identifiable information at all on your profile, unless you voluntarily choose to put it there. Similarly, if you're concerned about password security, use a different password. Honestly, I'm quite a bit less concerned about the security of my TV Tropes account than I am about, say, my bank account.
That said, it's not me you have to convince but Eddie that SSL encryption on logins is worth the effort and expense.
edited 12th Aug '11 8:16:16 AM by Fighteer
"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"If anybody wanted, at this point in time, it would be fairly easy for them to hack into the database and grab people's passwords.
Screw what you do with them elsewhere. What can they do with my account here? They can blank pages, vandalize things, harass Eddie via PM's, start creepy threads on the forum, and I will take the blame for it.
Similarly... If there's only a pretence at security, why do we even bother with passwords :/
There are too many toasters in my chimney!Exactly. It's not a matter of our security outside this very site, but it's a matter of our secutirty inside this site, and what they can do with the things and the names in our accounts.
Not to mention that if the security holes are as big as they seemingly are, anyone can hack into an administrator account and start to really fuck things up in the wiki and in the forums.
"My life is my own" | If you want to contact me privately, please ask first on the forum.Look at this way, Eddie. The reason why you won't make a quote button on this site is because you believe that they exist primarily for the abuse of trolls and you want to make that harder for them.
Well, if the system stores the passwords in plain text, any troll with an inkling of hacker skills will be able to extract the passwords from the system and hack any account. And then they can troll, troll to their heart's content.
So you want to make the trolls' jobs harder? All you have to do is improve the security.
Banned entirely for telling FE that he was being rude and not contributing to the discussion. I shall watch down from the goon heavens.For what is worth, I'm pretty sure SSL is definitively not worth it from a technical / development cost standpoint. It could be a good idea to salt the password with some kind of information that migrates with the user's browser profile, so that even if someone gets the cookie, they can not instantly use it (they'd likely have a different machine), they'd have to fetch the password at the time of submission. Of course, that means salting the password at the user storage stage, too.
One extra note, self-signed certificates are almost zero cost, I have generated those in a matter of two minutes and have had no issue. Apparently having no subdomains helps with that though...
edited 12th Aug '11 11:36:47 AM by SilentReverence
Fanfic Recs orwellianretcon'd: cutlocked for committee or for Google?annebeeche, the passwords are not stored in plaintext. I have no idea where you got this notion. They are in plain text on the end user's side, of course, in the cookie, but not in the master database. Cracking the server would not yield any useful information. At most you can compromise individual users' accounts by having access to their cookies or to their data stream.
Self-signing is hardly better than no signing; if you try that then everyone who visits the site will get a huge CERTIFICATE ERROR splash. Bad, bad idea for a major public site. Either do it properly or not at all.
Edit: I am not disputing the value of encrypted password storage on the end-user's side. It seems like a no-brainer security decision, but we're talking about a wiki, not a bank site. It's a matter of priorities, not absolute necessity. If you're that concerned about it in the meantime, don't register here.
edited 12th Aug '11 12:09:22 PM by Fighteer
"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"« and the authentication system apparently uses plain POST, Fighteer.» Plain GET, actually, if I remember correctly.
the future we had hoped forAs an aside, the current authentication system seems to rely largely on security by obscurity, and would be vulnerable to bot-based attacks with minimal supervision. So even for its stated purpose, it seems to be unsuitably weak.
(Edit: SSL is a red herring here; encrypting credentials in transit does nothing to help when the site fails to check them in the first place. It's like putting a door key in a combination safe when there's no lock on the door to begin with.)
edited 12th Aug '11 7:59:11 PM by SR101
Fighteer: Really? That was second-hand information coming from a criticism made by multiple people. I stand corrected.
I guess the password being stored in plain text on the cookie isn't as bad, but that means that it's unsafe to log in on a shared system where anybody can open the cookie and get your password.
Another thing:
I know that on the image uploader your password is already in the password bar. Question is, where does that password come from, the cookie or the system?
If it comes from the system, that means the encryption is reversible and that's not good.
edited 12th Aug '11 9:04:51 PM by annebeeche
Banned entirely for telling FE that he was being rude and not contributing to the discussion. I shall watch down from the goon heavens.It is always unsafe to log in on a shared system, regardless of whether the connection is SSL-encrypted, uses hashed password cookies, or any other security measures. The simple fact of keyloggers makes these protections useless.
The safest way to use a public system is to bring your own secure USB device that has a self-contained browser that leaves no traces on the host system — and to use a password safe that uses a non-loggable authentication method, like a on-screen graphical keyboard. Oh, and don't forget two-factor authentication, such as a hardware key or a biometric. And even those could theoretically be subject to esoteric forms of attack.
And all of this so you can post your opinions about Sonic The Hedgehog. Really, it's a matter of proportion.
"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"A password store lets you generate unique high-entropy passwords that you don't need to worry about remembering because they're kept under a single master password. Hopefully you don't forget that one.
edited 13th Aug '11 4:21:06 PM by Fighteer
"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"

If passwords are encrypted DB-side, then the only vulnerability is on the end-user's side: that being the risk that their local machine is compromised or that their connection is being snooped on. As Eddie said, that's the user's problem, not the wiki's.
"It's Occam's Shuriken! If the answer is elusive, never rule out ninjas!"