SSL for Metafilter

March 9, 2003 3:47 PM

I've been spending lots of time on wireless networks lately, so I finally up and got an SSL certificate for MetaFilter. Enjoy. Eventually I'll try to get all the user/pass pages going through https:// to make the site more secure.
posted by mathowie (staff) to Feature Requests at 3:47 PM (44 comments total)

i'd not heard of comodo before. were they good to deal with (good prices?).
posted by andrew cooke at 4:18 PM on March 9, 2003

You call that secure? When I got through, I found all the usual vandals were still roaming about at will, destroying threads and raping logic to their hearts' content. ;)
posted by MiguelCardoso at 5:15 PM on March 9, 2003

Can we also have an "e-mail mathowie" form on the new secure site? That way password change requests can be locked down as well.

Oh, hey, is this GPG key good?

(Asinine request? You be the judge...)
posted by tss at 5:52 PM on March 9, 2003

For some of us lesser-techies out there such as me, what exactly does adding SSL do for MeFites?
posted by jmd82 at 6:33 PM on March 9, 2003

"exactly does adding SSL do for MeFites?"

If you login to Metafilter, and you are using some sort of wireless connection to the Internet, your password is (in theory) flying around in the air for anyone to grab. Sort of. In some cases.

This is also true of wired connections. Someone who can see the network traffic can see your password in clear text. Maybe.

SSL encrypts everything from your browser to the MeFi server.

This is normally not an issue. Getting the password in either case is not trivial for the vast majority of users. However, at a convention like SXSW, where a large percentage of the people around you are savvy users things get more dangerous. If you are at a hackers convention like DEFCON your password is toast.
posted by y6y6y6 at 7:22 PM on March 9, 2003

If you are at a hackers convention like DEFCON your password is toast

quickly changes password from 'toast'
posted by eddydamascene at 7:25 PM on March 9, 2003

But if the password is sent cleartext with each page (at least each page with a comment box on it, view the source!)-- why just put user/pass pages on ssl?
*cough*
yeah. i was disturbed about this fact when a mefi user pointed out that my password was in the source of a mefi thread i had mirrored, months after i put it online.
posted by quonsar at 7:36 PM on March 9, 2003

y6: Ah, much thanks! That clears things up a lot.
posted by jmd82 at 7:51 PM on March 9, 2003

"my password was in the source of a mefi thread"

SSL won't help you there.

And Matt, will all of the pages be servered through SSL? Since all pages contain the password while you're logged in? Maybe time to recode? Why is the password there in the submit form anyway? I forget......
posted by y6y6y6 at 7:57 PM on March 9, 2003

Errr....... What neustile said..... Right.....
posted by y6y6y6 at 7:59 PM on March 9, 2003

But if the password is sent cleartext with each page (

not true. It's only sent when you submit something to the server.

So comment pages pull it from your cookie, and don't transmit that to the network, unless you submit your comment.

Comodo was fine, the cert was only 49 bucks.
posted by mathowie (staff) at 1:01 AM on March 10, 2003

It's only sent when you submit something to the server.

I guess I'm confused: I see it in a hidden field on every detail page I visit. If my password is stored in a cookie, what's the need for the hidden field? Also, appending a seed to the password before running the MD5 makes things that much tougher to crack.
posted by yerfatma at 4:36 AM on March 10, 2003

neustile (i may be about to teach my granny to suck eggs here, so apologies in advance), were you sending the hash (without https) across the 'net? if so, that's no more secure, since someone else can grab the hash and send it too. (you do get an extra level of obscurity; the same argument applies to apache's digest authentification (see first para)).

if you're hashing on the server then that's ok (although better to use salt too).

matt - thanks. good price.
posted by andrew cooke at 4:42 AM on March 10, 2003

yerfatma's right (or we're both misunderstanding matt), the passwd is sent across the net. here's a screen dump from ngrep (which shows network traffic) when i view a thread (bold emphasis added by me). the cookie value is processed on the server, not on the client.

andrew@tonto:~$ sudo ngrep "pass"
interface: eth0 (200.83.196.0/255.255.252.0)
match: pass
############################################################################################################################################################################################################################################################################################################################
T 209.10.108.201:80 -> 200.83.196.165:42890 [A]
at 52......</span>.......</div><br>...........<form name="mefi" action="co
ntribute/post_comment_preview.cfm#comment" method="POST" target="_self">...
.<table width="90%" border="0">....<tr>...<td rowspan="4"><img src="images/
1space.gif" width=30 height=1 alt="" border="0"></td>...<td align="right" v
align="top" nowrap><span class="accentcopy">Posting as:</span></td>...<td v
align="top"><span class="accentcopy"><a href="/user.mefi/1083" target="_sel
f">andrew cooke</a> (<a href="/index.mefi?delcookie=yes" target="_self">log
out</a>)....<input type="hidden" name="user_name"...value="andrew cooke"></
span></td>..</tr>..<input type="hidden" name="user_pass" ..value="XXXX"..
>..<tr>...<td align="right" valign="top"><span class="accentcopy">comment:<
br></span></td>...<td valign="top"><textarea name="comment" cols="60" rows=
"8" wrap="VIRTUAL" style="width:400px;height:200px;" onfocus="this.style.ba
ckground='#ddd';" onblur="this.style.background='#ccc';" ></textarea></td>.
.</tr>..<tr>..<td align="right" valign="top"></td>..<td valign="top"><input
type="submit" value="Preview" name="post" class="button"> <input onClick="
doSpell('mefi','comment');" type="button" value="Spell Check" class="button
"></td>..</tr>..</table>........<input type="hidden" name="link_ID" value="
24157">..<input type="hidden" name="ip" value="200.83.196.165">....</form>.
...<a name="trackback"></a>..<div class="trackback">...<a href="/tb.mefi" t
arget="_self">Trackback
#######################################################################exit
387 received, 0 dropped
posted by andrew cooke at 4:52 AM on March 10, 2003

If you're offering a secure login via https, make sure that the old, non-secure login remains as an option; at my last place of work, a firewall bunged up https connections under certain circumstances, and sites that used https for authentication were essentially unusable unless I logged in first thing in the morning.
posted by mcwetboy at 4:59 AM on March 10, 2003

"So comment pages pull it from your cookie, and don't transmit that to the network, unless you submit your comment."

I'm confused also. Even if the password comes from the cookie isn't the server getting the cookie over the network? And then returning the page with the password in place? Unless the page somehow grabs the cookie *after* it gets back to the client browser, and I have no idea how that might happen here, the password is in the clear between the server and the client on every page view.

Not that I really mind. Just wanting to make sure I understand. I don't think the risk of having someone pretend to be me justifies over engineering things here.
posted by y6y6y6 at 5:27 AM on March 10, 2003

ditto the over-engineering thing. was posting info+comemnts only out of interest, not to push anything
posted by andrew cooke at 5:40 AM on March 10, 2003

Oh right. I forgot that CF was pulling client cookie values from the server, I thought it was a client-side only grab.
posted by mathowie (staff) at 7:20 AM on March 10, 2003

"I thought it was a client- side only grab."

You might be able to do that with Javascript. Have mefi.user_pass.value set after the page gets back to the client. I've forgotten how Javascript reads cookies, but I know it can be done.
posted by y6y6y6 at 7:30 AM on March 10, 2003

This won't save you on a wireless link Matt. Setting up an encrypted tunnel/VPN between you and a trusted endpoint is the only way to go..
posted by fvw at 9:07 AM on March 10, 2003

if the whole session is over https then it *is* an encrypted tunnel with a trusted endpoint (the server).
posted by andrew cooke at 9:58 AM on March 10, 2003

Well yes, but I trust Matt to have enough of a life to actually want to do other stuff apart from check metafilter too. You're better off encrypting the entire bunch at once than making all connections encrypted seperately, if nothing else than to reveal less in traffic analysis and to keep your workstations behind your firewall. (Not saying that end-to-end encryption isn't also a good idea, but when you're dealing with an entire link over the airwaves you'll want to bundle it all up and encrypt at once).
posted by fvw at 10:21 AM on March 10, 2003

Are there any good services that currently provide a target for a VPN session? Or, do the people who want to do this mostly just tunnel back to a home machine and then go out via their ISP from there?

If somebody is currently using a service on a regular basis, what does the pricing look like? Of particular interest would be those that support Mac OS 9 or X in addition to Windows/*nix.
posted by willnot at 10:58 AM on March 10, 2003

Don't know about anyone else, but I've been getting browser errors today when loading MeFi homepage, which may be related to this - the "some items on this page may not be secure" dialog box pops up prompting me to continue or stop (IE6 on Win2k). Nothing earth-shatteringly bad, just annoying.
posted by kokogiak at 11:08 AM on March 10, 2003

the "some items on this page may not be secure" dialog box

Eew. That's my least-favorite part of SSL. You have to make sure every link leading out of the secured area is absolutely-pathed with "http://" to get rid of the "https://" protocol. Otherwise you get that warning box on every damn page. If you're seeing that warning, you're probably travelling through https. Just take the "s" out and refresh.

I still don't get why passwords, cookies, whatever need to be seen on the client side.
posted by yerfatma at 12:15 PM on March 10, 2003

"I still don't get why passwords, cookies, whatever need to be seen on the client side."

Well, the cookie has to be on the client side (though not necessarily displayed in the source) because that's part of what a cookie is. And you need one to stay logged in as you travel from page to page (I'm sure you know that, just saying....).

And the password doesn't need to be there, but even if you used something else, say a unique, hard to guess "key", you still have the same issue. If someone can grab that key they can pretend to be you. The fact that it's your password doesn't make it any less secure. It's the cookie that is identifying you, so your account is only as secure as that cookie, no matter what the cookie might contain.

Matt could eliminate that form element and still get the password from the cookie. This would look better, but wouldn't be more secure.

The solution I like is to store and send a unique string for each user after each page load. Then when the form gets submitted the server compares strings - "Is this string from the form the same one I gave this user on their last page?" This still allows a "man in the middle" attack, but that is so unlikely as to be not worth bothering about.

And is way more security than I think we need here.
posted by y6y6y6 at 12:46 PM on March 10, 2003

You could also store the client's IP on each page load, and force a new logon if the current IP != the stored IP. This would inconvenience people who use Mefi from two different computers (home and office, for instance) but it could be an opt-in feature.
posted by PrinceValium at 12:58 PM on March 10, 2003

And is way more security than I think we need here.

Has anyone ever had a password stolen here?
posted by timeistight at 1:01 PM on March 10, 2003

timeistight - Even if there haven't been any break-ins, there's a first time for everything, and why not be safe rather than sorry, even if the security lapse is relatively minor?

y6y6y6 - Just curious, why is storing a unique ID per request any more secure than storing one unique ID per session - even if you are storing a unique ID in a hidden form field or in a cookie, both of these things can be copied from one machine to the another, so why would it matter that the ID change after every request? It can still be copied. Also, how would you validate the initial credentials - by logging into every session? or from a cookie?

If you want to be a bit more secure (and again, not saying this is necessary, but since it's being discussed...) why not ask users to login every time they visit the site (via https), store a unique 'logged in' ID in a cookie (an in-memory cookie, even), and use that to persist the session?
posted by drobot at 1:21 PM on March 10, 2003

Ok, poorly phrased. What I should have said is, "Why passwords need to be seen on the client side." If the user has a cookie set, they get logged in. If they do not, they enter their user name and password in the form. The password is salted and hashed, compared on the server-side to the password in the database and then you set the logged in cookie. I understand that's not impenetrable, but this isn't the NSA either.
posted by yerfatma at 1:42 PM on March 10, 2003

Not meant to be snarky, but it sure came out that way. Forget I said anything.
posted by yerfatma at 1:42 PM on March 10, 2003

"and force a new logon if the current IP != the stored IP"

AOL makes this untenable. They change your IP within a dial-up session many times.

"and why not be safe rather than sorry"

The tricky part is security vs convenience. Given some effort and resources a hacker could get your password here no matter what Matt does. He could insist that every user set up VPN sessions. Or use some sort of browser plugin which implemented public key encryption. But why bother? Why make it a pain to use MetaFilter?

As is the site is just as secure as 99% of the other sites out there. Grabbing your password or cookies isn't trivial. Someone would have to have a good reason to need this info.

"why is storing a unique ID per request any more secure than storing one unique ID per session"

Because (and due to the DMCA I'm now about to break federal law) an attacker would have to exploit that unique ID before you loaded your next page. Since the value changes with every page load. So if they get the ID you were given on one day and try to use it the next (assuming you view more than one MeFi page a day) they would fail. And any time they wanted to impersonate you they'd need to steal another ID.

You reduce the time a hacker could use the exploit from a whole session to a few minutes.

The main reason it's more secure than one ID per session is that currently (I'm guessing here) last forever until you log out.

And even if they did use the exploit successfully you'd know about it the next time you loaded a page and got the message "handshake key mismatch - possible impersonation attack".

I've never actually built something like this. So I'm sure it's more complicated in real world practice.

"Also, how would you validate the initial credentials - by logging into every session? or from a cookie?"

You spotted one main problem here. The solution is only effective if the time between page loads is fairly small. So you wouldn't be able to let people stay logged in forever as MeFi does now. you want to expire the session/cookie after a certain period of inactivity.
posted by y6y6y6 at 1:58 PM on March 10, 2003

y6y6y6 - Thanks! I didn't realize that what you were suggesting would enforce a short time-to-live - that the unique key would only be valid for a few minutes, which seems obvious now. Thanks for the info.

I agree, there's a point where this is too much trouble, but it does make sense to do a few things to make things a bit more secure.
posted by drobot at 2:14 PM on March 10, 2003

y6y6y6 your random doodah might cause problems when using more than one browser (or tabbed pane). it looks like it would also stop people using the "back" button (assuming browser caches).

a nice compromise might be to not store user info in cookies, replacing it with a (random) session id. force sessions to expire in 24 hours and strongly suggest logins via https. that way the user can (via https) keep password hidden and you get the limited time part of your own scheme. it also means no passwds in embarassing places like urls (not a problem anyway) or html (see quonsar's comment).

this would solve most (all?) "delete your cookies" problems too, but i would guess the code that's currently behind mefi has user id stuff all over instead of in one nice place (no criticism of matt - this was written a long time ago and practical success is much more important the design purity). also, it would force logins every 24 hours, which would be unpopular.
posted by andrew cooke at 2:16 PM on March 10, 2003

"If the user has a cookie set, they get logged in."

This is the part where I may not know what the hell I'm talking about:

That's the weak part. If I get the cookie (which is just as easy to grab as the password) I don't need the password. Your cookies get sent to the server with every page request. It's part of the standard headers.
posted by y6y6y6 at 2:19 PM on March 10, 2003

andrew cooke - Agreed on all points.
posted by y6y6y6 at 2:24 PM on March 10, 2003

y6y6y6 - Yeah, you are right - cookies, form post or get, URL are all pretty much the same from that standpoint. When sent over HTTPS, though, they are encrypted. I think the cookie is the best way to go, IMO, storing a session ID with a relatively short expiration in a cookie instead of the password in a hidden form field. If somebody gets your sessionID, there's less risk then if they had your password.

Further, forcing people to always login when doing stuff like changing email address or changing passwords can further protect accounts from being hi-jacked. If the main concern, though, is protecting somebody from logging on and posting as somebody else, why not add password as a required field to post a comment? Code-wise, it'd probably just be a matter of turning the hidden form field into a password box, and making sure the form post is done over HTTPS.
posted by drobot at 2:28 PM on March 10, 2003

Good stuff y6y6y6.
posted by holloway at 3:34 PM on March 10, 2003

y6y6y6's suggestion, combined with SSL for all requests, is as good as at least two internet banking systems that I know of. In the end, a secure transport from end to end + random tokens per request + password required for all significant activities is the only answer - if the question was "How can Matt make MF very secure?". (Additional levels of paranoia can be mollified with SecureID tokens, biometric id, and progressively infeasible and inconvenient arrangements).

If we accept that MeFi is in the end just another personalised web app without any great impact on people's lives, then what we have right now is probably ok. (Think about the large and vitriolic Slashdot, which is wide open - is account hi-jacking a big problem there?)

People who use the same password over multiple systems should think twice under the current set up, though.
posted by i_am_joe's_spleen at 8:44 PM on March 10, 2003

drobot: what's an "in-memory" cookie?
posted by danOstuporStar at 9:58 AM on March 11, 2003

danOstuporSTar -

A cookie that lives in memory for the duration of a user's session - a session cookie, it's sometimes called. When you create a cookie from an application, if you don't give the cookie an expiration date, it dies when the user closes the browser. These cookies are never written to a file, but held in memory while the browser is open.

More here.
posted by drobot at 1:13 PM on March 11, 2003

thanks. i kinda thought you were referring to a transient cookie ... but had no idea that they were stored differently than cookies with expiration dates.

that must just be an implementation decision eh? There's no spec that says that they can't be saved on the user's hard drive is there?
posted by danOstuporStar at 1:23 PM on March 11, 2003

Yeah, I think it is an implementation decision - I think it's made at the browser level, though, not in the web application.
posted by drobot at 1:30 PM on March 11, 2003

People who use the same password over multiple systems should think twice under the current set up, though.

Considering we are unable to change our password here, it is a bit late for that :-)
posted by dg at 2:53 PM on March 11, 2003