4 ms·

> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a

> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.

mbesto 5y ago
Ya, I hate to be pedantic too, but security it almost entirely NOT binary. It should be, but it's not.
- haimez 5y ago
  I respectfully disagree with both of you. Security should be binary, within a given set of requirements / implementation parameters and the intended threat model. Security must be binary within the space of “are you authenticated or not” (within the massive context specific web of trust and private keys) is binary and if it weren’t that would be a problem.
  - crazypython 5y ago
    No implementation is perfect.
  - andrewmunsell 5y ago
    I don't think you're disagreeing with GP. Maybe it should be binary, but in reality it almost certainly is not treated that way. Trade offs are often made for UX or other business reasons.
  - andrewingram 5y ago
    But security through obscurity is a valid part of a security methodology, and it’s a part that inherently a continuum rather than binary. For sure some aspects of security are binary. But even with JWT (I agree with the main points of the article), a token with an expiry of 5 minutes but no revocation capabilities is still objectively preferable to no expiry at all. The binary aspect of security is primarily about whether you fall within your risk appetite or you don’t.
  - DaiPlusPlus 5y ago
    Right. The problem then is that people - Us - all of us here on HN - frequently fail to understand their project requirements or at least fail to anticipate the future requirements of a project - and we’re arguing about what those requirements should be :) And it’s not just people under-estimating things: it’s too easy to us ambitious-types to think “what if this simple PHP project goes viral and we need to scale to millions of users overnight?” (Answer for the curious: it won’t) - which in turn makes people think using stateless tokens is fine (well, it is fine, actually - provided you have a revocation system; TFA’s title is just clickbait, and the problems are hardly unique to JWT: almost every web platform’s built-in authX system will support stateless user-info and authorisation and use it by default… if not always and by-design (ASP.NET’s ClaimsPrincipal, Kerberos, etc). (Note I’m not referring to server-side session-state (like PHP’s $_SESSION) which is not intended for authX nor does it scale, for reasons mentioned in the article) The article is a contrarian-sounding ad for Redis, written by a Redis employee, on Redis’ own website. Why are we treating it like news? And why am I even writing this retort? Argh! HN’s content team know how to drive my engagement! I’m doomed…
  - deleted 5y ago
    [deleted]
  - dumpsterdiver 5y ago
    Security is binary, as in zeroes and ones that you will never lay eyes on. You seem to be claiming that security should be easy, when in fact the hacks that come will likely be much closer to the metal than you ever get.
- vsareto 5y ago
  It shouldn’t be, either. Things evolve around it, definitions change, but also things need to be less secure because of convenience or necessity. An emergency stop button that halts machinery, causes damage to the machines, stops production, but saves lives, can be the target of any number of imaginative scenarios of malicious actors hitting the button to cause damage or be a part of some grand hacker scheme. But we definitely don’t want to secure that until it takes badging in and a 2FA prompt just to use it.
esjeon 5y ago
Geez, even RSA is not secure if you push this thing hard enough. Cryptography is all about making it difficult to decrypt, not impossible to decrypt. One can easily setup a conspiracy theory that the government can record all the traffic, and decrypt the dump in the future when computers are fast enough.
jfhufl 5y ago
Nothing is "secure or not" - technologies/mitigations are secure against particular attacks. HTTPS is generally secure against passive network eavesdropping, but does nothing to stop local file inclusion in a web app. Just because there are attacks or ways around a particular defense doesn't mean it's worthless, that's why we have defense in depth.
- talove 5y ago
  This. That's why they call them 'attack vectors'. I disagree with the main thesis for why JWT is a problem. JWT isn't necessarily encouraging you not to hit the DB for user lookup. This is the claim the article makes as a problem with revocation. It reads like a really long thoughtful article based entirely on false assumptions for how to best use it. It's ok to carry around some encrypted state in your tokens for some uses cases.
emodendroket 5y ago
It seems like quite a silly position. By the author's own admission, it is possible to mitigate all the risks warned about. I certainly don't agree that something is never OK to use because if implemented improperly it wouldn't be secure. If I took that seriously, random password generation is insecure, because someone could just use an cryptographically insecure PRNG.
amerine 5y ago
Agreed so much.
_acco 5y ago
Exactly. We don’t even know for sure that there isn’t a faster way to factor numbers with classical computers. If you’re handling sensitive data, you have to understand the tools you’re using and what their relative weaknesses are. Best practices are nice. But it’s far too easy to make a mistake following them if you don’t understand the principles behind them. “X is always secure” is a great way to ensure X is not implemented correctly.

> Security should be binary. Either technology is secure or it’s not. From my experience, that's not the case for almost anything. In fact, I'd consider it a dangerous position.

mbesto 5y ago

Ya, I hate to be pedantic too, but security it almost entirely NOT binary. It should be, but it's not.

haimez 5y ago
I respectfully disagree with both of you. Security should be binary, within a given set of requirements / implementation parameters and the intended threat model. Security must be binary within the space of “are you authenticated or not” (within the massive context specific web of trust and private keys) is binary and if it weren’t that would be a problem.
- crazypython 5y ago
  No implementation is perfect.
- andrewmunsell 5y ago
  I don't think you're disagreeing with GP. Maybe it should be binary, but in reality it almost certainly is not treated that way. Trade offs are often made for UX or other business reasons.
- andrewingram 5y ago
  But security through obscurity is a valid part of a security methodology, and it’s a part that inherently a continuum rather than binary. For sure some aspects of security are binary. But even with JWT (I agree with the main points of the article), a token with an expiry of 5 minutes but no revocation capabilities is still objectively preferable to no expiry at all. The binary aspect of security is primarily about whether you fall within your risk appetite or you don’t.
- DaiPlusPlus 5y ago
  Right. The problem then is that people - Us - all of us here on HN - frequently fail to understand their project requirements or at least fail to anticipate the future requirements of a project - and we’re arguing about what those requirements should be :) And it’s not just people under-estimating things: it’s too easy to us ambitious-types to think “what if this simple PHP project goes viral and we need to scale to millions of users overnight?” (Answer for the curious: it won’t) - which in turn makes people think using stateless tokens is fine (well, it is fine, actually - provided you have a revocation system; TFA’s title is just clickbait, and the problems are hardly unique to JWT: almost every web platform’s built-in authX system will support stateless user-info and authorisation and use it by default… if not always and by-design (ASP.NET’s ClaimsPrincipal, Kerberos, etc). (Note I’m not referring to server-side session-state (like PHP’s $_SESSION) which is not intended for authX nor does it scale, for reasons mentioned in the article) The article is a contrarian-sounding ad for Redis, written by a Redis employee, on Redis’ own website. Why are we treating it like news? And why am I even writing this retort? Argh! HN’s content team know how to drive my engagement! I’m doomed…
- deleted 5y ago
  [deleted]
- dumpsterdiver 5y ago
  Security is binary, as in zeroes and ones that you will never lay eyes on. You seem to be claiming that security should be easy, when in fact the hacks that come will likely be much closer to the metal than you ever get.
vsareto 5y ago
It shouldn’t be, either. Things evolve around it, definitions change, but also things need to be less secure because of convenience or necessity. An emergency stop button that halts machinery, causes damage to the machines, stops production, but saves lives, can be the target of any number of imaginative scenarios of malicious actors hitting the button to cause damage or be a part of some grand hacker scheme. But we definitely don’t want to secure that until it takes badging in and a 2FA prompt just to use it.

esjeon 5y ago

Geez, even RSA is not secure if you push this thing hard enough. Cryptography is all about making it difficult to decrypt, not impossible to decrypt. One can easily setup a conspiracy theory that the government can record all the traffic, and decrypt the dump in the future when computers are fast enough.

jfhufl 5y ago

Nothing is "secure or not" - technologies/mitigations are secure against particular attacks. HTTPS is generally secure against passive network eavesdropping, but does nothing to stop local file inclusion in a web app. Just because there are attacks or ways around a particular defense doesn't mean it's worthless, that's why we have defense in depth.

talove 5y ago
This. That's why they call them 'attack vectors'. I disagree with the main thesis for why JWT is a problem. JWT isn't necessarily encouraging you not to hit the DB for user lookup. This is the claim the article makes as a problem with revocation. It reads like a really long thoughtful article based entirely on false assumptions for how to best use it. It's ok to carry around some encrypted state in your tokens for some uses cases.

emodendroket 5y ago

It seems like quite a silly position. By the author's own admission, it is possible to mitigate all the risks warned about. I certainly don't agree that something is never OK to use because if implemented improperly it wouldn't be secure. If I took that seriously, random password generation is insecure, because someone could just use an cryptographically insecure PRNG.

amerine 5y ago

Agreed so much.

_acco 5y ago

Exactly. We don’t even know for sure that there isn’t a faster way to factor numbers with classical computers. If you’re handling sensitive data, you have to understand the tools you’re using and what their relative weaknesses are. Best practices are nice. But it’s far too easy to make a mistake following them if you don’t understand the principles behind them. “X is always secure” is a great way to ensure X is not implemented correctly.