This is stupid/dangerous advice and I will die on this hill.
> The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions need to have longer lifespans than that.
Your auth token should be 5 or 10 minutes long, yes. Your session should be encoded in a refresh token, which can be another JWT or completely opaque, whichever you prefer.
> "stateless" authentication simply is not feasible in a secure way. You must have some state to handle tokens securely, and if you must have a data store, it's better to just store all the data. Most of this article and the followup it links to describes the specific issues:
No. Stateless auth is completely feasible in a secure fashion. You need short lived tokens as stated above, and to perform instant logout you need to be able to identify JWTs that were invalidated at the level of your API gateway. You don't need to store every JWT that is valid, only a way to identify the ones you want to invalidate early. If you make bulk invalidations not go onto this store (and just accept that with bulk logout, users will remain logged in for up to 5 minutes, which if you're doing logouts in bulk, this does not matter to begin with), then this typically fits in memory. "if you must have a data store, it's better to just store all the data" is just wrong.
And of course for refreshing the token, you go to your data store and recompute things. But the point is to do this every 5-10 minutes like the author (correctly) identified, not on every API request.
> JWTs which just store a simple session token are inefficient and less flexible than a regular session cookie, and don't gain you any advantage.
But no one does this. People use JWTs as auth tokens which are short lived but contain a bunch of information about the users that you'd get in huge trouble if it could be forged (user ids, resolved geolocation, entitlements, cohorts, etc etc), but that you also don't want to make every service of yours look up against a data store or compute for every single API request. It should be data that normally doesn't change during the duration of the auth token. When it does change, you should have a mechanism to immediately invalidate the previous one (see above) and issue a new one on the API call that made the change. Simple.
> The JWT specification itself is not trusted by security experts. This should preclude all usage of them for anything related to security and authentication. The original spec specifically made it possible to create fake tokens, and is likely to contain other mistakes. This article delves deeper into the problems with the JWT (family) specification.
Yes, all standards are horrible if you look at them long enough. XML is terrible, YAML is terrible, ASN.1 is horrific. I'll take a flawed standard that has been studied and criticized publicly so I have libraries and know where the footguns are vs rolling everything myself and having to find out the footguns on my own.
Killed for Skype, which was already declining by that time. Microsoft was keen on unifying their IM platforms, but failed to realise that unless the migration path is incredibly smooth, people just won't do it. And the value of any chat service is that the people you want to talk to are on there. Many people didn't bother migrating from MSN to Skype and that was the end of it.
The Skype team at the time was also run with the mindset of "developer happiness comes first, users come second", a relatively popular mindset in the 2010s, and shipped large app rewrites with missing features and usability regressions.
Of course, they eventually killed Skype too. The MSN users never went to Skype and the Skype users just progressively jumped ship to FaceTime/WhatsApp video/Google Voice to replace video calling and VoIP, respectively. By then you had a former shell of what Skype was and Microsoft figured they should just shove the remainder of their users into Teams.
Similar to the Google Talk > Hangouts > Google Chat tragedy.
Can't we just normalise publishing whatever you put into the LLM instead? I'm sure the author typed things into their favourite AI assistant that regurgitated that long form, LLM-speak style version. I'm sure the original prompt has all the relevant content and was a lot more pleasant to read.
Can't wait for this style of prose to become an incredibly embarrassing faux-pas.
You're thinking of this like a game where the only point is to "win". That's not how this would actually work in practice.
Blue is the only moral and logical choice. If red gets over 50% and you picked it, therefore contributing to the "red" outcome, you are now effectively a murderer. Plus you now get to live in a world where everyone else alive are sociopaths that picked red, where everyone with a conscience is now dead.
You also can't count on everyone picking red, or "if you picked blue, then you voted for suicide".
It's reasonable to assume that, leading to the button press event, the usual low-trust, "every man by himself" types will rally for red, with the usual excuses, where high-trust societies will make it clear that it's your moral duty to pick blue, to get the votes to the 50% threshold and ensure no one dies. Around the world there would be debates nonstop that would permeate every social circle and families. You'd have huge arguments where the typical selfish types would scream at their family members "how dare you say you're going to press blue, do you want to leave your poor mother alone without their only child?", only pushing red-leaning voters more into red and blue-leaning voters more into blue.
Plus, if you look at the possible outcomes:
- Red wins, you picked red: Depending on where you live, a reasonable portion to the large majority of the population is now dead. The ones alive have, by definition, a strong bias towards individualism and noncooperation. It's extremely likely civilisation will collapse. Pick your favourite fictional dystopia and you might have a reasonable chance of it actually coming somewhat real.
- Red wins, you picked blue: You are now dead, but at least you don't have to live in the world above.
- Blue wins, you picked blue: Things carry on as normal and your conscience is safe in knowing that you didn't vote to kill and that over 50% of your fellow humans also didn't vote to kill.
- Blue wins, you picked red: Things carry on as normal, but you now have a guilty conscience, or, if your vote was made public, people around you know you would have killed them to save your skin.
Correct. If you can always either fix it forwards or roll back, which you should be able to unless you're building software that needs to go out in releases with versions tracked separately that need to keep getting fixes, trunk-based development simplifies everyone's lives greatly.
I've never seen an organisation that insists on release branches and complicated git merge flows to release their web-based software gain any actual benefit from it that isn't dwarfed by the amount of tooling you need to put around it to make it workable to the dev team, and even then, people will routinely screw it up and need to reach out to the 5% of the team that actually understands the system so they can go back to doing work.
Baseline requirements are not an imaginary problem. All of them have a legitimate reason for existing. You could argue that some "are not that big of a deal", but that's exactly the point, the overbearing and overly specific requirements serve both their own purpose and double as Van Halen's "no brown M&Ms" clause: if the CA screws them up, either by malice or incompetence and doesn't immediately catch them and self-report, then you know they have no way of telling what other things they are screwing up. And if you're in the business of selling trust, that instantly makes you untrustworthy.
There are countless Bugzilla reports of clearly unprofessional CAs trying to get away with doing whatever they want, get caught, say "it's no big deal", fail to learn the lesson and eventually get kicked out, much to the chagrin and bewilderment of their management, irate that some nerds on the Internet could ruin their business, failing to understand that following the scripture of the Internet nerds is the #1 requirement of the business they chose to run.
If you purposely go into your phone settings and turn off auto-capitalization (which is what the kids do, since they're all typing on their phones), isn't it the very definition of pretentiousness? You're going into extra trouble to signify you're part of a clique, while feigning "laid-backness" and "i dont even care bro".
But you do care. You care so much to project your appearance of being cool and that you don't even care that you go through extra trouble to keep it up, even though paradoxically it would be LESS effort to not do it.
Cat's out of the bag there already. We all have general purpose computing devices in our pockets, locked down on purpose. Android used to allow you to gain admin rights but it's been getting more and more impossible to do so while still keeping most of your programs working. It's not only a cat-and-mouse game against "rooting detection" SDKs companies licence and plug into their apps out of a misguided duty of care, but it's especially bad with anything that uses Google's remote attestation lately.
Android is also about to lock down "sideloading", another "great" dysphemism for "installing software".
Moving the Overton window on this has been so successful, that even people in our industry happily accepted the much maligned dysphemisms of "jailbreaking" and "rooting" for what used to be called "local admin rights" and look upon such access as if it's only something pirates, criminals or malware spreaders would want to do.
I say this as someone who is running an Android phone with a kernel with some backported patches applied and compiled by myself. The fact that I can do it is great. The fact that the entire industry is trying to make it as frustrating as possible for me to do this under the guise of false premises such as "security" is disheartening.
Correct. Age verification and privacy consents belong on the browser. The issue is that on the browser, things work a bit too well (remember https://en.wikipedia.org/wiki/P3P ?), so the big players are incentivized to ignore completely the browser-based mechanisms and say/do nothing whenever they see lawmakers going on a dumb direction (risking fines is a reasonable price to pay in order to kill adoption of an actual browser/OS based control that would cause a dent to their tracking operations) that puts the onus on individual website operators.
The insane question here is, why would the EU mandate hardware attestation controlled by two private American companies in order to access services?
That seems completely contrary to the spirit of EU laws and regulations, which tend to be about protecting the consumer, preventing monopolies, ensuring people can generally live their lives where all things that are mandatory are owned and ran by the state and foster a certain degree of EU independence, with a recent focus on "digital sovereignty".
This one is a five for one against all of those goals? Harms the customer (you could see this as the polar opposite of GDPR), strengthens entrenched monopolies, force citizens to be serfs of one of two private corporations in order to access information, and on top of that, like it wasn't enough, willingly capitulates to the US as the arbitrates of who is a valid person or not.
This is so against the spirit of the EU itself that it would almost be funny if people weren't serious.
Agreed. I refuse to use the terms "rooting" and "jailbreaking" in professional environments, I always use terms like "admin access to the mobile device".
Because that's what it is, despite the extremely successful campaign to paint people who want admin access on their mobile computers to be painted in the same light as pirates.
We have a near perfect system for finding the location of phone thieves, yet the police will not go and knock on the doors of criminals even when explicitly shown proof of "this is where the thief is currently".
I'm not victim blaming here, but does anyone have this nagging feeling that in this case, we, the "techies" caused this by refusing to engage with lawmakers?
In the case of E2E encryption, it's definitely a hill to die on, there is no way to make a backdoor "only the good guys" can access. But in this case, the long standing refusal for the tech industry to engage in even the lightest of lobbying towards having legal regulation for standards seems to bite us in the ass every now and then. We've seen it time and time even for things that are non controversial and would clearly benefit everyone: why is BCP 38 not mandated by law in any country? Why is IPv6 at the ISP consumer edge not mandated by law?
All of this could have had the same effect if instead of putting the onus of age verification on millions of websites, you instead put it onto the "customer end device", with some definition as to have it only apply to anyone who sells devices used to access online content with more than X% market share (meaning effectively Microsoft, Google on behalf of all Android OEMs and Apple, plus TVs and console makers).
You'd also put into law what content providers need to do to become compliant. It drops from "having a robust system of age verification" into "if you're serving content over HTTP and your content is for over 18, you need to send a specific over 18 header". If you're publishing an app on a walled garden app store, you need to specify the age rating (as one does already). If you state your page is good for under 18s when it's actually over 18, you then incur a fine.
Then it's really just up to OS makers to build support for the above into the parental controls functions that mostly already exist. Implement the header checking on the browser. Then restrict over 18 apps and outside app store that aren't explicitly authorised: this ensures no alternate browsers could be installed or ran by a child, while leaving them freedom to roam the web and install under 18 apps. The issue with existing parental controls is twofold: the web is a wild place and manually vetting every single app your kid wants to install is overbearing so everyone gives up on parental controls.
Then it's a matter of, when you buy a phone for your kid, you click a button "the user is a child, enable parental controls, set the grown up password". If parents fail to even do this, then clearly it's their own fault?
You'd specifically leave out non-HTTP protocols and leave a bunch of technical loopholes that could be exploited by technically minded people. It would both limit the amount of wreckage to things the common people doesn't even know it exists and make sure this wouldn't creep into places it doesn't belong. Sure, teenager who downloads Arch into a USB pen drive and boots off it can then access whatever they want, or someone who finds they can get into IRC and XDCC a bot for hot JPEGs, but at that point they clearly earned it.
I get the feeling that we've fucked it, left very important regulations up to people who have no clue and now we get the most onerous and worst implementation possible of things every single time put into law. We could have done the same with cookies, there's like, three browsers. Remember P3P? https://en.wikipedia.org/wiki/P3P
Usually I would agree with you, but this is an incredibly common initialism, used by not just people in the industry, but also by consumers. Sure, it may not be as widespread as VHS (global) or API (tech-adjacent), but anyone who is in the market for this software already knows what NVR means.
Most people would know the term from either being quoted or looking up CCTV solutions, all of which, unless they're fully "cloud-based", come with a component that is called the NVR. You wouldn't even consider this if you weren't aware of the concept. If NVR means nothing to you, Network Video Recorder doesn't mean anything to you either. This is meant to be a replacement for closed and inflexible hardware boxes that are sold together with security cameras, and the name of those boxes are "NVRs".
I really don't, what is the answer? I assume higher ups at law enforcement, who are detached from the day-to-day operations, make up excuses about "end to end encryption being a challenge" because it's a meme, much like execs in our fields parrot "challenges" to boards and VC investors that are often fully removed from actual execution issues.
And then because it comes up in slides so much at that higher level, politicians actually start thinking that's why we haven't solved all crime, our guys are competent and clearly they're not understaffed, it's that pesky "not being able to break end to end encryption" that is preventing law enforcement from doing their work!
I don't understand why they keep trying this over and over. It can't possibly be a moral crusade as it keeps happening with different players, but I don't understand the purpose.
We now live in a world where the opposite routinely happens: a crime happens, you give the police access to Apple or Google's Find Device / Find My data, they throw it in the trash. Law enforcement has more data to find and procecute criminals than they have time. People get scammed out of money by the thousands every day, over the phone, an insanely easy system to tap and trace. No one gets arrested.
Who is actually repeatedly pushing for things like these within the EU? For what purpose? What crimes went unprocecuted because of the unability to perform mass surveillance like this? It seems that all the time, when law enforcement actually cares about, it's trivial for them to get evidence? So why does this keep popping up every year?
It was Bill fucking Atkinson. Not a disposable random contractor you hire by the dozen when you need to build more CRUD APIs.
At that time at Apple, even as an IC, Bill had lines of communication to Steve and was extremely valued. There's absolutely no doubt he could get "middle manager shenanigans" gone simply by not complying or "maliciously complying". Hell, I've seen ICs far less valuable, or even close to negative value get away with stunts far worse than these, succeed and keep their jobs. Out of all the stories in Folklore.org, this is the one you have an issue with?!
Wait, but didn't TLS 1.0 have significant improvements over SSL 3.0? The article makes it seems that just a couple of things were tweaked just to make it different for the sake of being different.
> The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions need to have longer lifespans than that.
Your auth token should be 5 or 10 minutes long, yes. Your session should be encoded in a refresh token, which can be another JWT or completely opaque, whichever you prefer.
> "stateless" authentication simply is not feasible in a secure way. You must have some state to handle tokens securely, and if you must have a data store, it's better to just store all the data. Most of this article and the followup it links to describes the specific issues:
No. Stateless auth is completely feasible in a secure fashion. You need short lived tokens as stated above, and to perform instant logout you need to be able to identify JWTs that were invalidated at the level of your API gateway. You don't need to store every JWT that is valid, only a way to identify the ones you want to invalidate early. If you make bulk invalidations not go onto this store (and just accept that with bulk logout, users will remain logged in for up to 5 minutes, which if you're doing logouts in bulk, this does not matter to begin with), then this typically fits in memory. "if you must have a data store, it's better to just store all the data" is just wrong.
And of course for refreshing the token, you go to your data store and recompute things. But the point is to do this every 5-10 minutes like the author (correctly) identified, not on every API request.
> JWTs which just store a simple session token are inefficient and less flexible than a regular session cookie, and don't gain you any advantage.
But no one does this. People use JWTs as auth tokens which are short lived but contain a bunch of information about the users that you'd get in huge trouble if it could be forged (user ids, resolved geolocation, entitlements, cohorts, etc etc), but that you also don't want to make every service of yours look up against a data store or compute for every single API request. It should be data that normally doesn't change during the duration of the auth token. When it does change, you should have a mechanism to immediately invalidate the previous one (see above) and issue a new one on the API call that made the change. Simple.
> The JWT specification itself is not trusted by security experts. This should preclude all usage of them for anything related to security and authentication. The original spec specifically made it possible to create fake tokens, and is likely to contain other mistakes. This article delves deeper into the problems with the JWT (family) specification.
Yes, all standards are horrible if you look at them long enough. XML is terrible, YAML is terrible, ASN.1 is horrific. I'll take a flawed standard that has been studied and criticized publicly so I have libraries and know where the footguns are vs rolling everything myself and having to find out the footguns on my own.