the comment submit box has my user password stored as clear text

November 4, 2001 1:44 PM

I was looking at the source in the Auto-close Open Tags thread, and I noticed that the comment submit box has my user password stored as clear text. It's not like MeTa/MeFi need to be highly secure, but I'm wondering if there is a better way to handle that.
posted by willnot to Bugs at 1:44 PM (9 comments total)

It is stored encrypted in your cookie, so people can't copy cookies or get it that way. When the cookie is read while you make a comment, it is decoded and used to make sure your username and password align in the database. As long as no one is sniffing network traffic at your end or the server end, you'll be fine. I was considering moving that data across an https connection for people subscribing to some sort of pro version.

Tell me a better way to do authentication and I'll code it.
posted by mathowie (staff) at 2:06 PM on November 4, 2001

I'm curious, is the cookie sent to the server when the page is requested or when a comment is submitted?

If it's passed when a comment is posted is not possible to take the hashed password from the cookie and use that to authenticate instead of a hidden field on the form?
posted by gi_wrighty at 2:25 PM on November 4, 2001

Yeah I suppose so.
posted by mathowie (staff) at 2:52 PM on November 4, 2001

I'm probably stating the obvious here, but if you wanted to make the whole thing secure you'd need SSL continuously (there may be other ways, but that's simplest). Hashing passwords doesn't stop someone else using the cookie (it stops them getting the password to log in directly, but they can go directly to posting and submit the cookie).

(I don't think this is necessary for MetaFilter, though!)
posted by andrew cooke at 3:31 PM on November 4, 2001

I don't think the problem is preventing people from posting as you. I think it's that a lot of users will tend to use the same password for multiple accounts, so if I know Ken in the next cube over has a MeFi account, all I have to do is read a thread on his computer, view source and now I have access to his e-mail account, bank or whatever.
posted by willnot at 3:47 PM on November 4, 2001

not having the password in the cookie at all would be more secure. Usually i'll put the user id in the cookie as a value and then use that to get the profile. but all of the things i've done have 3 states, anon, recognized, and authenticated. I wouldn't worry about it too much.
posted by jbelshaw at 3:48 PM on November 4, 2001

actually after looking at the code, it appears that you are in a 'recognized' state before submitting a comment. And you are passing the password in a hidden field to be compared to the password in the db. A more secure way would be to a) require that the user actually type their pw in a password field when they submit a comment, or just pass the encrypted version to compare with the encrypted version in the db. (i'm assuming that it is encrypted in the db, right?)
posted by jbelshaw at 3:55 PM on November 4, 2001

Once upon a time someone was having a mefi layout problem so they saved the page and hosted it for all to see. I emailed them about the plain-text password but it was up for a day or two and linked to from metatalk.

I was going to mention it here, but I didn't want to affect the user, and then my pea brain forgot about it.

In PHP I don't ever send the user a page with their password in it. I'm not sure about coldfusion but a users cookies are available all the time and they don't have to be form variables.

In my metafilter ripoff I have a session password which is generated upon each login. They use that cookie to post comments, post stories, etc. That high-traffic cookie is going back and forth between Mefi and the client but if it's compromised it will only be compromised for one session. It's a random number with no relation to their login password.
posted by holloway at 4:23 PM on November 4, 2001

holloway's doing basically the right thing. I'm not sure why the hidden form fields are there at all — you should just cookie the username and a session ticket. The ticket doesn't have to be stored in the database if the session isn't going to carry a lot of persistent data; it can just be cryptographically verifiable. E.g. a random 4-digit hexadecimal number followed by the last 4 digits of the MD5 hexhash of (that number + some secret number).
posted by nicwolff at 8:46 PM on November 4, 2001