You are dangerously bad at cryptography • Hacker News Board

Re: You are dangerously bad at cryptography

#171

Post by jarrett » Tue, May 28, 2013, 4:56 PM UTC

Nelson69 wrote: post #169

tptacek wrote: post #164

Earlier quoted context omitted.

Absolutely. Strong agree!

How would this 'warning' look? I think labeling 'expert' is almost like an attractant for many of the folks that shouldn't bother. Likewise, there are some good users of OpenSSL, the rumors of it being "bad" or "insecure" would be damaging. I'm not saying it's a bad idea exactly, just if you discover the way to word the warning to prevent people who don't understand that they're newbies from doing newbie stuff with i…

Good point. I'd word it something like this:

A Word of Warning

This library exposes a very complex API. It is intended for expert users only. If you have any doubts about your knowledge of the underlying cryptographic primitives, we strongly recommend against using this library. Doing so without advanced knowledge of cryptography could compromise your security. Instead, we recommend you use a high-level crypto library, such as Keyczar or NaCl, both of which are designed to "just work" in the hands of developers who lack specialize expertise in crypto.

Re: You are dangerously bad at cryptography

#172

Post by jarrett » Tue, May 28, 2013, 5:27 PM UTC

sirclueless wrote: post #167

StavrosK wrote: post #55

Earlier quoted context omitted.

There aren't any, learn how the libraries work and use them. I agree with your point, in that respect. Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed.

> Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed. Not necessarily good enough. If you just sign a cookie that says userid=42, anyone who ever manages to read it can now authenticate as your user whenever they like. You just turned any session hijacking attack into an account hijacking attack. Do what tptacek says, "just use random tokens to key a serversid…

Wouldn't the random tokens also be vulnerable to a replay? If I copy a session cookie from one client to another, regardless of how that cookie authenticates itself, won't most servers accept it? Seems to me that once the client has been compromised, session hijacking is going to happen.

The server can be set to check that the client IP address and HTTP fingerprint match. That makes the replay attack harder but not impossible. It also introduces some usability concerns--valid sessions may expire sooner than intended.

Re: You are dangerously bad at cryptography

#173

Post by sirclueless » Tue, May 28, 2013, 5:54 PM UTC

jarrett wrote: post #172

sirclueless wrote: post #167

Earlier quoted context omitted.

> Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed. Not necessarily good enough. If you just sign a cookie that says userid=42, anyone who ever manages to read it can now authenticate as your user whenever they like. You just turned any session hijacking attack into an account hijacking attack. Do what tptacek says, "just use random tokens to key a serversid…

Wouldn't the random tokens also be vulnerable to a replay? If I copy a session cookie from one client to another, regardless of how that cookie authenticates itself, won't most servers accept it? Seems to me that once the client has been compromised, session hijacking is going to happen. The server can be set to check that the client IP address and HTTP fingerprint match. That makes the replay attack harder but not i…

The token is just a key to a server-side session that will be deleted eventually, for example when the client logs out. If someone can hijack a session, that's obviously already a problem, but unfortunately XSS attacks are fairly common as they are something that can happen in any number of places on a website, and even vigilant developers will probably miss some. (See, for example, the recent XSS attacks reported on Paypal).

If you use a random token to a session that will be invalidated, then the attacker is at least time-limited. If you just naively sign an auth cookie and trust it later, he has a replay attack that will work permanently until you change your code.

As for you other suggestion, restricting sessions by IP address can be done no matter where the session data is stored. It will help to mitigate session hijacking in general, but it also degrades the experience, especially for mobile users, who will have to re-login every time they change IP addresses. It's particularly a problem if a form submission fails for this reason, because they'll probably get redirected away to a login page and lose any information they entered.

Re: You are dangerously bad at cryptography

#174

Post by wtbob » Tue, May 28, 2013, 8:16 PM UTC

jarrett wrote: post #53

This argument keeps coming up, and while its premises are valid, its conclusion never sits right with me, namely: "Don't use cryptography." That advice isn't practical for developers. There are plenty of systems we have to design where crypto is not optional. Examples: * Storing passwords. You can't store them in plaintext. * Signing requests (like in the OP's example). What are the alternatives? You can store some k…

> Encrypting cookies. You should store as little as possible in cookies--ideally just a single identifier. But even so, it's very important to make cookies tamper-resistant. You can't, e.g. just have a plaintext cookie that says "userid=42."

Note that you possibly don't want to _encrypt_ the cookie (particularly if it's transmitted over SSL); you certainly want to _authenticate_ it.

I may not care if the user knows that he is user ID 42; I very much care if he's able to tell me that he is user ID 43 instead.