4 ms·

IIRC tptacek has been beating this drum for a while, but it seems that he got tired of it, so I should pick the drum sticks in his stead: Use less crypto. The

by DenisM 10y ago

IIRC tptacek has been beating this drum for a while, but it seems that he got tired of it, so I should pick the drum sticks in his stead: Use less crypto. The less crypto is being used, the fewer mistakes are being made. When it comes to sessions, generated a secure random 256 bit token and use that as a session id. Store it in a database or in-memory store. Sticky sessions + local session token storage will fix your network latency problems when you start scaling out. Federation becomes moderately difficult. Perhaps you could store a copy of session id on each node, and when a session id is compromised, proactively reach to all nodes and ask them to purge the session. This allows immediate mitigation for a session id leak, and since it doesn't rely on timeouts there is no vulnerability window for data exfiltratiin upon a breach. And no crypto.

nbarbettini 10y ago
> The less crypto is being used, the fewer mistakes are being made. I don't understand this position. What do you mean by "fewer mistakes are being made"?
- joepie91_ 10y ago
  Cryptography-related code is incredibly easy to fuck up, and the tiniest mistake can completely break your security model. A mistake that could be insignificant in other kinds of code, could easily be critical in crypto-related code. Thus, you reduce both the amount of mistakes and the impact of mistakes by avoiding crypto where possible. EDIT: Yes, this includes using existing libraries. It's not just the implementation of the primitives themselves where issues occur.
  - girvo 10y ago
    In fact, a heap of JWT libraries had massive vulnerabilities in them not that long ago, that mean you could easily forge JWTs.
atombender 10y ago
This misses one huge benefit of JWTs: Other parties can trust your token if they were not the ones to sign it. For example, say client A calls service B, using a token signed by service C. Previously, we were using randomly generated session keys, which meant B had to ask C every time. But with JWTs, B can directly verify that the token is genuine without asking C, because it has C's public key. We still check with C now and then, but that's because the token auto-expires. We use a long-lived master token stored in a cookie to generate new short-lived ones.
- joepie91_ 10y ago
  The problem is that you're trying to treat sessions and authorizations as one and the same thing. They're not. What kind of services are you envisioning? Direct-to-database services like Firebase are a horrible idea for a plethora of security-related reasons, and if you control both service B and C yourself, then you either a) use one-time authorization tokens for stateless services or b) exchange a one-time authorization token for a session on a stateful service. In none of those three cases do you use the token as the session. Tokens are handed out on a single-use, as-needed basis.
  - lobster_johnson 10y ago
    The user does have a session. Tokens are temporary, short-lived authorizations. Sessions require a central session store; every request has to go to the central session store to check the session's validity. Incurring one session check per API call is bad enough, but when each API call then invokes half a dozen other APIs, you have a problem. Central session stores don't scale with distributed architectures. I've not heard the term "direct-to-database" before, but we've been doing it for about 6 years, albeit not using Firebase, and it's huge win over the classic "custom, ad-hoc API per use case" methodology. Exposing a shared data layer abstraction between microservices is no different than exposing a more targeted API (i.e. there's conceptually zero difference between "POST /objects/42" and "POST /users/42"), including as far as security is concerned.
    - spriggan3 10y ago
blazespin 10y ago
You think mistakes can't be made with session ids? Anyways, there are well trusted libraries out there for JWT.
- marcus_holmes 10y ago
  I don't understand. A session key is just a lookup key for a database table. What mistakes are made?
  - DenisM 10y ago
    There are tricks there too. If you just lookup in the database, I could find out how much time it took to retrieve the strings, this will leak the session id over time. Databases don't do constant-time data retrieval. You would have to come up with a way to retrieve the session token from the database at constant time, or at least time that does not betray the session id.
    - marcus_holmes 10y ago
      But the session id isn't sensitive, is it? I mean most session verification middleware checks the ip address of the request against the address of the session login. If the address's don't match you kill the session and force another login. I usually just put the session id in a cookie and use https to encrypt the whole stream shrug

by DenisM 10y ago

nbarbettini 10y ago

> The less crypto is being used, the fewer mistakes are being made. I don't understand this position. What do you mean by "fewer mistakes are being made"?

joepie91_ 10y ago
Cryptography-related code is incredibly easy to fuck up, and the tiniest mistake can completely break your security model. A mistake that could be insignificant in other kinds of code, could easily be critical in crypto-related code. Thus, you reduce both the amount of mistakes and the impact of mistakes by avoiding crypto where possible. EDIT: Yes, this includes using existing libraries. It's not just the implementation of the primitives themselves where issues occur.
- girvo 10y ago
  In fact, a heap of JWT libraries had massive vulnerabilities in them not that long ago, that mean you could easily forge JWTs.

atombender 10y ago

This misses one huge benefit of JWTs: Other parties can trust your token if they were not the ones to sign it. For example, say client A calls service B, using a token signed by service C. Previously, we were using randomly generated session keys, which meant B had to ask C every time. But with JWTs, B can directly verify that the token is genuine without asking C, because it has C's public key. We still check with C now and then, but that's because the token auto-expires. We use a long-lived master token stored in a cookie to generate new short-lived ones.

joepie91_ 10y ago
The problem is that you're trying to treat sessions and authorizations as one and the same thing. They're not. What kind of services are you envisioning? Direct-to-database services like Firebase are a horrible idea for a plethora of security-related reasons, and if you control both service B and C yourself, then you either a) use one-time authorization tokens for stateless services or b) exchange a one-time authorization token for a session on a stateful service. In none of those three cases do you use the token as the session. Tokens are handed out on a single-use, as-needed basis.
- lobster_johnson 10y ago
  The user does have a session. Tokens are temporary, short-lived authorizations. Sessions require a central session store; every request has to go to the central session store to check the session's validity. Incurring one session check per API call is bad enough, but when each API call then invokes half a dozen other APIs, you have a problem. Central session stores don't scale with distributed architectures. I've not heard the term "direct-to-database" before, but we've been doing it for about 6 years, albeit not using Firebase, and it's huge win over the classic "custom, ad-hoc API per use case" methodology. Exposing a shared data layer abstraction between microservices is no different than exposing a more targeted API (i.e. there's conceptually zero difference between "POST /objects/42" and "POST /users/42"), including as far as security is concerned.
  - spriggan3 10y ago

blazespin 10y ago

You think mistakes can't be made with session ids? Anyways, there are well trusted libraries out there for JWT.

marcus_holmes 10y ago
I don't understand. A session key is just a lookup key for a database table. What mistakes are made?
- DenisM 10y ago
  There are tricks there too. If you just lookup in the database, I could find out how much time it took to retrieve the strings, this will leak the session id over time. Databases don't do constant-time data retrieval. You would have to come up with a way to retrieve the session token from the database at constant time, or at least time that does not betray the session id.
  - marcus_holmes 10y ago
    But the session id isn't sensitive, is it? I mean most session verification middleware checks the ip address of the request against the address of the session login. If the address's don't match you kill the session and force another login. I usually just put the session id in a cookie and use https to encrypt the whole stream shrug