


People, please try this #serveronly alternative to #anubis to keep. #ai at bay
Thanks to @alcinnz for the efforts
A simple bot gatekeeper for nginx - Evil Genius Robot:
https://evilgeniusrobot.uk/posts/a-simple-bot-gatekeeper-for-nginx.html
People, please try this #serveronly alternative to #anubis to keep. #ai at bay
Thanks to @alcinnz for the efforts
Hello je suis en train de mettre en place Anubis, il fonctionne très bien sur #PeerTube mais par contre pour #Nextcloud la navigation fonctionne uniquement via le navigateur web, les apps mobile et clients lourd n'arrivent pas à se connecter à l'instance.
Quel serait le truc/config pour autoriser ces apps à se connecter ?
poke @sebsauvage
Thank you

I don’t know who needs to hear this but compiling www/anubis from ports-current on #OpenBSD -stable works ok. And indeed, sending the #Anubis package to a remote -stable server and use ˋpkg_add -D unsigned ./anubis(…)` to upgrade also works.
(currently live on the blog which has an unpronounceable name ;-)
I don’t know who needs to hear this but compiling www/anubis from ports-current on #OpenBSD -stable works ok. And indeed, sending the #Anubis package to a remote -stable server and use ˋpkg_add -D unsigned ./anubis(…)` to upgrade also works.
(currently live on the blog which has an unpronounceable name ;-)
#Anubis possède désormais un challenge qui ne nécessite pas Javascript, permettant aux clients sans Javascript (ou avec Javascript désactivé ou filtré) de passer avec succès le challenge.
L'auteur a testé pas mal de navigateur : même les navigateurs en ligne de commande et le navigateur intégré à emacs passent.
Cela devrait réduire la quantité de clients bloqués.
https://anubis.techaro.lol/blog/release/v1.20.0/#no-js-challenge
The Open-Source Software Saving the Internet From AI Bot Scrapers
🔗 https://www.404media.co/the-open-source-software-saving-the-internet-from-ai-bot-scrapers/

I just updated #Anubis for the @FreeCAD infrastructure. There's now support for challenges without requiring client-side #JavaScript, and a "success... failure!"-type bug affecting #Chromium should now be fixed. Please let me know if you run into any issues! #FreeCAD
I just updated #Anubis for the @FreeCAD infrastructure. There's now support for challenges without requiring client-side #JavaScript, and a "success... failure!"-type bug affecting #Chromium should now be fixed. Please let me know if you run into any issues! #FreeCAD
Just released: #swad 0.11 -- the session-less swad is done!
Swad is the "Simple Web Authentication Daemon", it adds cookie/form #authentication to your reverse #proxy, designed to work with #nginx' "auth_request". Several modules for checking credentials are included, one of which requires solving a crypto challenge like #Anubis does, to allow "bot-safe" guest logins. Swad is written in pure #C, compiles to a small (200-300kiB) binary, has minimal dependencies (zlib, OpenSSL/LibreSSL and optionally libpam) and should work on many #POSIX-alike systems (#FreeBSD tested a lot, #Linux and #illumos also tested)
This release is the first one not to require a server-side session (which consumes a significant amount of RAM on really busy sites), instead signed Json Web Tokens are now implemented. For now, they are signed using HMAC-SHA256 with a random key generated at startup. A future direction could be support for asymmetric keys (RSA, ED25519), which could open up new possibilities like having your reverse proxy pass the signed token to a backend application, which could then verify it, but still not forge it.
Read more, grab the latest .tar.xz, build and install it ... here: 😎
Just released: #swad 0.10
https://github.com/Zirias/swad/releases/tag/v0.10
Swad is the "Simple Web Authentication Daemon". If you're looking for a way to add #authentication (and/or proof-of-work access as known from #anubis) to your #nginx reverse proxy -- without adding yet another reverse proxy -- swad could be for you! It's written in pure #C, has few external dependencies (just zlib, and optionally OpenSSL/Libressl and/or libpam) and compiles to a pretty small binary. It's designed for usage with nginx' 'auth_request'.
Swad is tested on #FreeBSD, some basic functionality tests were also done on #Linux and #illumos (descendant from #solaris). It should build and work on most #POSIX-alike systems.
This release mainly brings performance improvements and a few bugfixes. It's now stress-tested with Apache jmeter, verifying it can deal with at least 1000 requests per second on my personal (somewhat limited) FreeBSD host machine.
Hopefully, there will be another release of #swad soon!
Looking at my test results again, performance should be okay at least for moderately busy sites ... the 1000 requests per second I observed included actual logins, and I didn't even test whether it would also handle more (it probably would), the only issue was with resolving remote names (with that, around 30% of these requests failed because the thread pool was clogged with jobs all waiting for some DNS response), and the recommendation would be: just disable that feature if your site is a busy one.
But I'm really unhappy with RAM usage going up so much. Almost 100MiB resident set after seeing 1000 unique clients all attempting a login is a lot after all.
So, I'll try to move swad to a session-less design. It can't be fully stateless, a rate limiter will be needed, but maybe I can optimize a bit on that.
But the sessions could be replaced. They're currently used for two things:
* Store actual auth information. This could be stored in signed JWTs (json web tokens) on the client instead. I'm already starting to add JSON support to my poser lib 😉
* Store the random challenge for the #anubis-like proof-of-work checker. Could do the same as anubis here: Derive the challenge from request metadata instead, including a timestamp.
Will be quite some work, but could be doable.
Just released: #swad 0.10
https://github.com/Zirias/swad/releases/tag/v0.10
Swad is the "Simple Web Authentication Daemon". If you're looking for a way to add #authentication (and/or proof-of-work access as known from #anubis) to your #nginx reverse proxy -- without adding yet another reverse proxy -- swad could be for you! It's written in pure #C, has few external dependencies (just zlib, and optionally OpenSSL/Libressl and/or libpam) and compiles to a pretty small binary. It's designed for usage with nginx' 'auth_request'.
Swad is tested on #FreeBSD, some basic functionality tests were also done on #Linux and #illumos (descendant from #solaris). It should build and work on most #POSIX-alike systems.
This release mainly brings performance improvements and a few bugfixes. It's now stress-tested with Apache jmeter, verifying it can deal with at least 1000 requests per second on my personal (somewhat limited) FreeBSD host machine.
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"?
Just released: #swad 0.7! 😎
Swad is the "Simple Web Authentication Daemon". If you're looking for a solution to add cookie/form #authentication to your #nginx reverse proxy, or maybe even a #lightweight alternative to #Anubis which leaves the actual proxying to nginx, this might be for you! It is designed for use with nginx' auth_request, written in pure C, with minimal dependencies (zlib and, depending on build options, openssl/libressl and/or libpam), and compiles to a small binary (currently between 150kiB and less than 300kiB depending on compiler and target platform).
Swad should work on many #posix (and almost) systems. It's actually tested on #FreeBSD (in "production" use, but on a very low-traffic private site), and quick functionality tests also done on #Debian (#Linux) and #OpenIndiana (#Illumos, open-source #Solaris descendant).
As announced, this release doesn't bring any new features (in terms of WHAT it can do), but great improvements "under the hood", that should help performance at least on some platforms, see release notes for swad 0.7.
Read more, and download the .tar.xz (to build and install it 😆) here:
https://github.com/Zirias/swad
Just released: #swad 0.5
swad is the "Simple Web Authentication Daemon", meant to add authentication using a #cookie and a #login form to your reverse proxy. It's designed for #nginx' "auth_request" module. It's written in pure #C with very few external dependencies (zlib, and depending on build options OpenSSL/LibreSSL and #PAM).
And with this release, it also allows guest logins using the crypto puzzle you may already know from #Anubis!
Read more in the release notes, grab the .tar.xz and build/install it 😎