> Isn’t session token theft as much of an issue as JWT token theft? Why is there a difference in security just because in one case it’s a JSON blob that says user_id:4,is_admin:false and in the other it’s an opaque string? Surely session tokens are equally vulnerable to XSS as JWT tokens?
The difference is that if your session cookie uses HttpOnly (which should _always_ be the case) then it can’t be read by JS, which makes it less vulnerable to XSS than a JWT (or worse, a refresh token) stored in a cookie by the client or localstorage and therefore accessible to JS. Basically, you have to be more careful with how you handle JWTs, which makes it more likely for an inexperienced or careless dev to do something insecure like store a JWT in localstorage.
> How does it affect things? Does it affect request latency, or server time decoding the JSON?… Where is the latency introduced?
I think their point is that it’s faster not to hit the DB, assuming you aren’t hitting the DB for any other reason. Any performance optimisation should be justified and profiled. There aren’t many applications operating at a scale where the difference in performance between JWTs and session tokens is going to make a significant difference, and even fewer who can genuinely use JWTs without hitting the DB (eg, to ensure the JWT hasn’t been revoked)
> Part of me wonders whether the move to electric vehicles from ICE will resemble the move from CRT to LCD televisions. Less robust…
EVs are far more robust than ICEs from a mechanical level, as the number of moving parts is reduced by orders of magnitude. The problem is electronics, but this has been plaguing ICEs for over 30 years. There’s no reason for the electronics in an EV to any less robust than an ICE, but we are going to see far fewer mechanical failures.
EV or ICE, it seems unlikely any of these cars will be running in 30 years let alone 50. Eventually the electronics fail to a point that is too difficult to diagnose or fix.
Case in point - had a friend with a mid 2000s Astra. Everything worked except for the left indicator. Eventually the car was written off as no one could fix it. The car was just over 10 years old at the time.
The other thing that worries me is how integrated modern headunits are. It used to be that when your headunit broke or became obsolete, you could just whack a new one in for a few hundred dollars, prolonging the life of your vehicle. Now even basic cars have fully integrated headunits making upgrades impossible. Even if the headunit continues to function, the technology is going to become so obsolete that they’ll be virtually useless in 20 years. I doubt the iPhone 35 will connect to a 2023 car. I guess people who buy new cars couldn’t care less about what happens to them in 20 years, which is an easy win for car manufacturers looking for ways to reduce the effective lifespan of their vehicles.
One of my favourite things they’ve done recently is remove support for TOTP. Now, if you want 2FA, you have to download their proprietary Adobe Account Security app. This in turn requires you to provide a phone number, because unlike TOTP there’s no alternative method of backup.
I really do wonder why they removed an easy-to-use, known, secure, and trusted standard in favour of a clunky app that’s ultimately only as secure as a phone number (in reality less so as DIY security always results in holes). More vendor lock-in? Another avenue to harvest data?
Not that it really affects me as I no longer use any Adobe products.
These can be hidden using uBlock origin. I’ve got a list you can import (just use the raw link). The selector isn’t perfect in Google (sometimes leaves some unattached content) but the link is always removed. Feel free to submit a PR if you find any other SO clones - there seems to be no end to them.
I wouldn’t say I’m part of the community, but I’m certainly a fan of ZZT. A text-based game engine developed in 1991 by Tim Sweeney which still has a community going and new games being released to this day. I was able to make my way around it a 14 year old kid, which says a lot about its accessibility.
However, holders can’t opt themselves in; inexplicably this needs to be supported at the broker level. I’ve spoken to one of the large brokers who advised me they have no plans to support this feature.
These don’t go into the ear as far so aren’t painful. I feel the reduction in noise isn’t as good, but the frequency response is much more even. I wear these under noise cancelling headphones to watch TV and listen to music in total isolation. You do lose a bit of fidelity but it’s still very liveable.
Also, I get about 6 months to a year out of each pair which is less wasteful than foam earplugs.
And now we’ve come full-circle as 1Password 8 requires you to save your password prior to submitting the form instead of offering to save it after submission. Which is a huge regression as it results in this exact issue all over again.
It's not about 2FA though. The problem is that PayPal allows users to log in via a one-time code sent via SMS, without the need to enter their password or TOTP (I assume this extends to hardware keys as well). They're doing 1FA over SMS and there's no way to opt out.
OP here - yeah that's my bad - I never intended it to be interpreted as fully revealed but a sentence taken out of context can read that way, so I tweaked the article (as well as fixing a few spelling mistakes). Apologies for the confusion.
OP here - thanks for pointing that out, for some reason when I try to type TOTP my fingers keep defaulting to TOPT - some kind of muscle memory I guess. In any case, this has been corrected, although I'm unsure how a simple spelling mistake discredits the basis for the complaint.
> I have an account with MFA and... I don't think that's true
Try log in using Incognito/private browser. I am either defaulted into the one-time SMS flow, or given the option to log in with a one-time SMS code. In either case, if I enter the SMS code I am not prompted for my password nor TOTP.
The difference is that if your session cookie uses HttpOnly (which should _always_ be the case) then it can’t be read by JS, which makes it less vulnerable to XSS than a JWT (or worse, a refresh token) stored in a cookie by the client or localstorage and therefore accessible to JS. Basically, you have to be more careful with how you handle JWTs, which makes it more likely for an inexperienced or careless dev to do something insecure like store a JWT in localstorage.
> How does it affect things? Does it affect request latency, or server time decoding the JSON?… Where is the latency introduced?
I think their point is that it’s faster not to hit the DB, assuming you aren’t hitting the DB for any other reason. Any performance optimisation should be justified and profiled. There aren’t many applications operating at a scale where the difference in performance between JWTs and session tokens is going to make a significant difference, and even fewer who can genuinely use JWTs without hitting the DB (eg, to ensure the JWT hasn’t been revoked)