3 ms·

Ok, grant it I'm new here, and could be missing the point. I didn't actually go through the full article because I'm not really that much into crypto, and reall

Ok, grant it I'm new here, and could be missing the point. I didn't actually go through the full article because I'm not really that much into crypto, and really, didn't the guy fail the interview at the point where he suggest that encryption was the answer for a cookie used for individual identification? I mean, encrypt it all you want, if I can be behind the same NAT as you, and spoof your user agent, all I need to do is get that cookie and put it in my browser, and I've stolen that session. The real answer is you need to either encrypt the transport, or at the very least minimize the amount of time that cookie is valid for.

mrcharles 17y ago
The real answer is that you sound like you'd benefit from reading the whole damn article.
- jrussbowman 17y ago
  Well, I read the entire article, and it's quite interesting that there are things like Keyczar and cryptlib out there, I still think it's a poor example. Other than a brief note on encryption does not equal authentication, they never touched on the fact that encrypting the cookie data itself isn't a real solution, as the encrypted cookie can be sniffed, and replayed to the server. So, while standard user can't hack their own cookie for escalation, they can sniff admin cookies to get that escalation. If the cookie is used for authentication or authorization, encrypting it's content is providing a false sense of security, no matter what nifty library you choose or not choose to do it with.
  - zmimon 17y ago
    > as the encrypted cookie can be sniffed, and replayed to the server I think the whole article is premised on requiring a level of security that would presume TLS is being used.
    - NateLawson 17y ago
      Yes, the focus is on preventing cookie forgery for pre-auth account compromise or privilege escalation.
  - tptacek 17y ago
    The attack you just described applies to all online commerce. Your bank and brokerage (and the clearing firm your brokerage uses) all fall to HTTP cookie sniffing. The point isn't the relationship between you, Bank of America, and a hacker; it's the relationship between you (a hacker) and Bank of America.

mrcharles 17y ago

The real answer is that you sound like you'd benefit from reading the whole damn article.

jrussbowman 17y ago
Well, I read the entire article, and it's quite interesting that there are things like Keyczar and cryptlib out there, I still think it's a poor example. Other than a brief note on encryption does not equal authentication, they never touched on the fact that encrypting the cookie data itself isn't a real solution, as the encrypted cookie can be sniffed, and replayed to the server. So, while standard user can't hack their own cookie for escalation, they can sniff admin cookies to get that escalation. If the cookie is used for authentication or authorization, encrypting it's content is providing a false sense of security, no matter what nifty library you choose or not choose to do it with.
- zmimon 17y ago
  > as the encrypted cookie can be sniffed, and replayed to the server I think the whole article is premised on requiring a level of security that would presume TLS is being used.
  - NateLawson 17y ago
    Yes, the focus is on preventing cookie forgery for pre-auth account compromise or privilege escalation.
- tptacek 17y ago
  The attack you just described applies to all online commerce. Your bank and brokerage (and the clearing firm your brokerage uses) all fall to HTTP cookie sniffing. The point isn't the relationship between you, Bank of America, and a hacker; it's the relationship between you (a hacker) and Bank of America.