Let's support kids.
By "kids", I of course mean support for Key IDs (kids) in JWT assertions (IETF rfc7515 JSON Web Signature - JWS compliant)
Of course, I also mean #FreePalestine, and #SayNoToGenocide
For a full writeup:
https://dev.to/galtzo/ann-oauth2-v2012-w-support-for-kids-57be
The Curious Case of the Tampered Token
https://myfear.substack.com/p/jwt-quarkus-murder-mystery
#Java #Quarkus #JWT #Security #Microprofile
Ten Years of JSON Web Token (JWT) and Preparing for the Future
Several years ago, I was working on our local #OIDC identity provider at work ... part of which was looking at a #JWT (JSON Web Token) quite frequently.
Now I implemented JWT myself (from the ground up in pure #C) for #swad to make it independent of sessions.
Well, dejavu here ... even back then, I always chuckled a bit how every JWT basically says "ey ... EY!" to me
(see it? *scnr*)
Cloudflare is hiring Principal Billing Systems Engineer
#golang #api #docker #jwt #kafka #kubernetes #mysql #postgresql #redis #sql #principalengineer
Remote
Full-time
Cloudflare
Job details https://jobsfordevelopers.com/jobs/principal-billing-systems-engineer-at-cloudflare-com-may-6-2025-50fd8b?utm_source=mastodon.world&utm_medium=social&utm_campaign=posting
#jobalert #jobsearch #hiring
What's worse?
Good morning!
Now that I can't find any other bugs in #swad any more, I'm thinking again about how I could improve it.
Would anyone consider deploying it on a busy site right now? Either as a replacement for #Anubis (proof-of-work against bots), or for simple non-federated #authentication, or maybe even both?
I'm currently not sure how well it would scale. The reason is the design with server-side sessions, which is simple and very light-weight "on the wire", but needs server-side RAM for each and every client. It's hard to guess how this would turn out on very busy sites.
So, I'm thinking about moving to a stateless design. The obvious technical choice for that would be to issue a signed #JWT (Json Web Token), just like Anubis does it as well. This would have a few consequences though:
* OpenSSL/LibreSSL would be a hard build dependency. Right now, it's only needed if the proof-of-work checker and/or TLS support is enabled.
* You'd need an X509 certificate in any case to operate swad, even without TLS, just for signing the JWTs.
* My current CSRF-protection would stop working (it's based on random tokens stored in the session). Probably not THAT bad, the login itself doesn't need it at all, and once logged in, the only action swad supports is logout, which then COULD be spoofed, but that's more an annoyance than a security threat...
* I would *still* need some server-side RAM for each and every client to implement the rate-limits for failed logins. At least, that's not as much RAM as currently.
Any thoughts? Should I work on going (almost) "stateless"?
Kritisk sårbarhet i Cisco IOS XE Wireless Controller – godtycklig filuppladdning möjlig. CVSS-score på 10 av 10 möjliga!
Studying the code of a newly scaffolded #rust #loco app. #loco raised my attention because there is a line in README.md
This is the **SaaS starter** which includes a `User` model and authentication based on JWT.
However, based on what I found for now, the received #JWT is never properly validated on the server side, so the #loco lesson on #JWT handling in #rust is rather incomplete. For truth's sake, authentication is there, but authorization is not. Now the rest is up to me.
@fleaz : it's not MultiMultiFactorAuthentication but 1FA max.
Assuming that you don't use those hardware keys to generate TOTP codes (which are pointless when confronted with the likes of #Evilginx2), but use WebAuthn instead (FIDO2 passkeys in hardware keys), everything depends on one factor: the domain name of the website.
DV-CERTS SUCK
It is not very common that certificates are issued to malicious parties, but it *does* happen now and then (https://infosec.exchange/@ErikvanStraten/112914050216821746).
SUBDOMAINS
Furthermore, sometimes organizations have "dangling" subdomain names. For example,
test.example.com
may point to the IP-adress of some cloud server no longer used by example.com. Anyone with write access to that server may install a fake "test.example.com" website and phish you to it. It *may* be used to phish your WebAuthm credentials *if* "example.com" does not explicitly *DENY* WebAuthn from "test.example.com".
See https://github.com/w3ctag/design-reviews/issues/97#issuecomment-175766580 for how Google prevents "sites.google.com" from authenticating to "google.com".
DNS HACKED
It may not be neccessary to execute BGP-hijacks to redirect network traffic to an impostor: it also all depends on how reliable DNS records are protected against unauthorized access. If the dude in charge for DNS uses a stupid password only, or the DNS provider is easily fooled into believing "I forgot my creds", it's game over. The crooks will obtain a DV-cert in no time, no questions asked, for free.
All the bells and whistless are moot if there's an alternative way to log in (such as by using a 1FA rescue code) and the user is fooled into providing it (after they've been lied to that their WebAithn public key on the server became corrupted or was lost otherwise).
Cloudflare MitM's https connections (it's not a secret: https://blog.cloudflare.com/password-reuse-rampant-half-user-logins-compromised/). The same applies to any server you log in to, which is accessible by untrustworthy personnel. They can steal your session cookie.
In the end MFA/2FA is a hoax anyway, because the session cookie (or JWT or whatever) is 1FA anyway.
Did I mention the risks of account lockout with hardware keys that cannot be backupped? And the mess it is to keep at least one other hardware key synchronized if it's in a vault? And the limitation of, for example, 25 WebAuthn accounts max? And (unpatcheable) vulnerabilities found in hardware keys? And their price? And how easy it is to forget or loose them?
How to implement JWT authenticat https://chat-to.dev/post?id=bEZjNnFScDVteFpVS3NHMXRHZENrQT09 #jwt #javascript #programming #coding