116916 - [SECURITY] Cookies should be stored encrypted

Status: VERIFIED DUPLICATE of bug 56788

(Core :: Networking: Cookies, enhancement)

Description

[TGOS]

Some pages store a username and password as cookie on the user PC to avoid that
the user must always login when visiting the page. If I allow these pages to
store cookies, everyone can look up my cookie file and see my login data. If I
disable cookies for the page, I first have to go to a login page, which is time
comsuming, even if Mozilla's password manager knows my password.

Cookies should be encrypted on HD and protected via the master password of each
user. E.g. if I want to browse my cookie list (cookie manager), I first have to
enter my master password (unless I have already entered it and once per session
is enough). And if I enter a site that expects a cookie, I first have to enter
my master password and if it's correct, it will be sent. Otherwise the browser
may still display the page, but no cookie is sent.

Otherwise people could browser pages from my PC and even though they don't know
my master password, they would immediately be logged in to my account on these
pages. Disallowing these pages to store cookies (or using the cookie permission
based on privacy to avoid that this kind of data is stored permanently) is a
nice work-around, but it means no quick loggin anymore once I closed my browser.

Comment 1

[Sebastian Biallas]

See discussion on bug 56788

Comment 2

[Stephen P. Morse]

Although similar, this is different from bug 56788 in that there the concern was 
on the user being able to attack the website by forging cookies.  IMO, that was 
a very strange perspective of privacy, and I closed it out as wont-fix based on 
that.

Here the concern is to protect the user's privacy by doing encryption.  This is 
a more bona-fide concern, but again I'm going to close it out as wont-fix for 
the following reasons.

1. If the site is going to include sensitive information in the cookie, it must 
encrypt that information.  Nearly every site that I know of does.  And if a site 
doesn't, that's the site's mistake.

2. If we did encrypt the cookies, it would change the format of the cookies 
file.  That would break backwards compatibility with old cookie files.

3. If you have to give a master password to access the cookie file, that means 
you will be prompted for the master password as soon as you start browsing since 
just about every site uses cookies.  So you may as well ask for it when the 
browser starts up.  And that would be very objectionable to the majority of 
users.

4. As for sites that do an automatic login based on info (encrypted or 
otherwise) found in cookies, these sites almost always ask if you want to be 
logged in automatically on future visits.  Any user who is concerned about 
somebody else walking up to his machine would of course tell the site that he 
doesn't want such automatic login.  And if the site doesn't give the user such a 
choice, then again that's the site's mistake.

Comment 3

[TGOS]

1) Even if it encrypts the information, what stops a user to write it down (no
matter what the information may be, the user doesn't has to understand it), open
his cookie file on his PC and manually write down this encrypted cookie data,
then visiting the site and get loged in under my name? So this doesn't solve the
problem at all. At the moment where the cookie file would be encrypted, it
wouldn't happen anymore, because the user couldn't read it anymore.

2) Users usually upgrade, they don't downgrade. You could detect an unencrypted
cookie file and encrypt it on the first run of a version that supports
encryption. For developers you could add a tool that decrypts the cookie file
after the master password was entered (simple command line tool will do). It's
nothing new that sometimes if you install a newer version of an application some
files are converted to a new format on the first run and can't easily be
converted back.

3) No, you won't get prompted before you entered any page (my Mozilla opens
blank for example) and the majority of pages I visit regularly does not use any
cookies. They keep track of visitors by adding hidden input fields to form pages
or manipulating the links through dynamic pages (JSP, ASP, CGI) and thus will
work if you disable cookies completely. I accept all cookies, but most are
cookies of banner services, only very few decent sides are there.

4) E.g. Audiogalaxy does not ask you and it stores username and password in
plain text. But my point was not to protect against pages like Audiogalaxy, the
quick login via cookie is a nice feature, it saves you a lot of time if you jump
between different protected pages. It's one of the features I really like to
have enabled, but it's also a big security hole if there's ever someone who has
access to your PC, either through a trojan or directly. And when I use Mozilla
on a UNIX system, I don't want that the root can spy out my cookies, like
described in 1) and then get logged in to all kind of pages.

If Mozilla wouldn't encrypt any information, I hadn't said a word. Then I had
moved all profile data onto a PGPDisk at my PC, so people first have to mount
this disk with password, otherwise Mozilla will open up, but won't find any
profile... not sure if there's anything like that for UNIX systems. But it
encrypts form data and it encrypts HTTP passwords via a master password and I
wonder why cookies were not included as well? What sense does it make to encrypt
only parts of the user data?

Comment 4

[Stephen P. Morse]

1. The site's encryption of the cookie is to prevent a casual observer from 
seeing sensitive values that are stored in the cookie.  But you are correct, it 
does not stop a person from using that cookie and getting logged on.

2. Although in the minority (hopefully), there are users that downgrade.  
Perhaps they updgraded from 4.x to try version 6, didn't like it, and decided to 
go back.  

3. Whether or not you need cookies on the first page you visit is not the point.    
Very early in the session, a typical user will encounter a site that uses 
cookies.  And that would trigger a request for master password if the cookie 
file was encrypted.

Comment 5

[Stephen P. Morse]

This is acutally of dup of bug 56788.  Reopening so I can mark it as a dup.

Comment 6

[Stephen P. Morse]

*** This bug has been marked as a duplicate of 56788 ***

Comment 7

[Tom Everingham]

verified dup