1

Let's say I have an account on a blog. I'm using https on every single page of that blog through web server rules, so there's no way to visit the page in the clear text. I'm also using a laptop that utilizes full disk encryption, and I'm the one who uses the machine. More over, I have 128bit auto generated passwords for each site on the internet, and each of the password is different. I also store the passwords in an encrypted keyring, just in case that I need them, but usually I don't because of the cookies. And here's the problem. Most of the internet sites (especially WordPress ones) have strange policy regarding cookies. In the case of WordPress, the default cookie expiration time is set to 2 days. If you checked the "Remember" option, that would be 14 days. So once for a while you have to log in whether you like it or not.

Is this necessary? I mean, what would happen if the cookies have no expiration time set? Is there a way to steel them somehow? If you have the whole site encrypted, and no one can access your machine, should you still be worried about cookies that are sent through the internet? I've never been asked, for instance, by google for password while checking my emails.

  • 1
    Do some searches for "cookie stealing" and take a look at the old attack "firesheep". Just remember the difference between "session timeout" and "cookie expiry". – schroeder Jun 6 '15 at 16:31
  • Does the "cookie stealing" work with a full https website? – Mikhail Morfikov Jun 6 '15 at 17:09
  • I'm using 32-character passwords (128bit, randomly generated), and I've never had any issues with cracking the passwords. They stay the same for a really long time that can be measured in months, even years, and I've never had unauthorized access to my accounts. I think I'm different. :] – Mikhail Morfikov Jul 7 '15 at 11:46
2

First off, your connection to a website being encrypted does not necessarily mean that your connection is actually secure. It certainly helps, but encryption can differ massively in quality. You might have heard about POODLE, as well as FREAK. Bugs and side effects like these could mean that a sufficiently powerful attacker might be able to break the SSL. And that's not even including the possibility that a CA has been compromised, like happened with Diginotar. And of course, the website itself might be compromised, with a piece of Javascript stealing your cookies and even your credentials, like the Tunisian government did with Facebook.

So assume that the attacker has your cookie. The server actually uses that cookie to know who you are, because that's the only way it can know that. IP addresses can change and aren't unique enough. Browser sniffing is complicated and can break when you do something like patching Chrome (maybe to deal with a bug in TLS). hardware footprints are hard to acquire and aren't unique enough as well. So the only way is by having a small file on your computer that tells the server who you are. So if anyone knows what is in that file, they can use that to login as you.

You can test that yourself. Open your dev console, find your cookies list on this website, open an incognito tab to this website and edit the cookies using an extension. Once you refresh the page, you're logged in to the website without entering your credentials. A few years ago, there was a tool called Firesheep that could track non-TLS connections other people made on a public wifi (say, a starbucks) and impersonate them. Even now, you can buy a special tool called a Pineapple for 100 EUR, trick people into connecting to your wifi and steal their data.

  • 1
    This also has the same impact when it comes to, let's say, passwords in a login form, right? So if you have bugged ssl/tls, the password can be compromised. If the site isn't trusted, so passwords aren't secure either. When some webpage doesn't use full https, just log you in in that way, yes, you have cookie problem here, but I asked in the light of full implementation of ssl/tls protocol, so no matter what page you visit on a blog, it will always be encrypted, even if there's just a text. – Mikhail Morfikov Jun 6 '15 at 17:24
  • @MikhailMorfikov The difference is that a password is only sent 1 time, to authenticate. The cookie is sent every time you make a connection to a website, even for something like a resource. So if you connect to a website via a network that's capable of MitM'ing you through something like a fake certificate or a bug in SSL, it can still take that cookie, since it can decrypt it. – Nzall Jun 6 '15 at 17:30
  • Yes he can, but he can also take the password when a user would log in using the same network and the same bugged client/server software. I don't see any difference between the two, even when you send the password just once, and the cookies with every single request -- I think, they should set 2-day expiration period for passwords. :) – Mikhail Morfikov Jun 6 '15 at 17:41
  • @MikhailMorfikov Consider a user on a mobile device, say a laptop or a smartphone. now, this user doesn't enter his passwords on public wifi because he knows the danger, so he enters it at home. The cookie can still be stolen though, which is effectively just as good as the password. In addition, a number of websites have a HTTPS login page, but then don't use TLS once the user is logged in afterwards, which means the cookie is transmit in cleartext (although this isn't the case for websites that implement TLS across the board). – Nzall Jun 6 '15 at 18:38
  • 1
    So you can also get the password in that way. So I don't understand why they set 2 day expiration period only for cookies. :) – Mikhail Morfikov Jun 6 '15 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.