mastodon.bida.im is part of the decentralized social network powered by Mastodon.
Un'istanza mastodon antifascista. autogestita, italofona con base a Bologna. Rispettosa di privacy e anonimato.

Server stats:

939
active users

Learn more

#authentication

1 post1 participant0 posts today

Released: #swad v0.1 🥳

Looking for a simple way to add #authentication to your #nginx reverse proxy? Then swad *could* be for you!

swad is the "Simple Web Authentication Daemon", written in pure #C (+ #POSIX) with almost no external dependencies. #TLS support requires #OpenSSL (or #LibreSSL). It's designed to work with nginx' "auth_request" module and offers authentication using a #cookie and a login form.

Well, this is a first release and you can tell by the version number it isn't "complete" yet. Most notably, only one single credentials checker is implemented: #PAM. But as pam already allows pretty flexible configuration, I already consider this pretty useful 🙈

If you want to know more, read here:
github.com/Zirias/swad

Simple Web Authentication Daemon. Contribute to Zirias/swad development by creating an account on GitHub.
GitHubGitHub - Zirias/swad: Simple Web Authentication DaemonSimple Web Authentication Daemon. Contribute to Zirias/swad development by creating an account on GitHub.

Trying to come up with my own little self-hosted #http #authentication #daemon to work with #nginx' "authentication request" facility ... first step done! 🥳

Now I have a subset of HTTP 1.x implemented in #C, together with a dummy handler showing nothing but a static hello-world root document.

I know it's kind of stubborn doing that in C, but hey, #coding it is great fun 🙈

github.com/Zirias/swad

Simple Web Authentication Daemon. Contribute to Zirias/swad development by creating an account on GitHub.
GitHubGitHub - Zirias/swad: Simple Web Authentication DaemonSimple Web Authentication Daemon. Contribute to Zirias/swad development by creating an account on GitHub.

@yacc143 FYI: #Passkeys and #FIDO2 (= "device-bound #passkey" which can be divided into "platform-" and "roaming-authenticators") are identical except the #cloud-sync mechanism (as of my current understanding).

So unfortunately, they get mixed up or are considered as totally different things. Both is wrong.

In reality, they are very similar except that FIDO2 hardware tokens ("device-bound passkeys" only in their "roaming-authenticator" variant) are designed that way, that Passkeys are not being able to extracted from the device (at least for the moment).

Therefore, users of HW tokens can't be tricked into transferring their passkey to a rogue third party, which is possible with all other Passkey variants. Therefore: passkeys are NOT #phishing-resistant in the general case.

@mensrea : if you visit a shop (or a bank) in the center of the city, chances are near zero that it's run by impostors.

However, if you go to some vague second hand market, chances are the you will be deceived.

Possibly worse, if there's an ATM on the outside wall of a shack where Hells Angels meet, would you insert your bank card and enter your PIN?

On the web, most people do not know WHERE they are.

Big Tech is DELIBERATELY withholding essential information from people, required to determine the amount of trust that a website deserves.

DELIBERATELY, because big tech can rent much more (cheap) hosting and (meaningless) domain names to whomever if website vistors cannot distinguish between authentic and fake websites.

You are right that some people will never understand why they need to know who owns a website.

However, most people (including @troyhunt ) would enormously benefit.

Like all the other deaf and blind trolls, you trash a proposal because it may be useless for SOME, you provide zero solutions and you keep bashing me.

What part of "get lost" do you not understand?

@aral @EUCommission @letsencrypt @nlnet

Screenshot from the top of https://www.virustotal.com/gui/ip-address/13.248.197.209/relations

The page had already redreshed when I copied the following domain names, so this is just to get an idea:

tiles-35312.bond
sleepwear-14660.bond
prostate-cancer-treatment-95682.bond
diet-98948.bond
electric-cars-94009.bond
packing-jobs-44721.bond
dental-implants-48408.bond
mattress-19892.bond
breast-reduction-mammoplasty-surgery-24489.bond
dental-implants-76071.bond
rv-camper-motorhomes-90728.bond
roofing-services-61345.bond
maid-service-26172.bond
Infosec ExchangeErik van Straten (@ErikvanStraten@infosec.exchange)Attached: 1 image @aral@mastodon.ar.al : most Let's Encrypt (and other Domain Validated) certificates are issued to junk- or plain criminal websites. They're the ultimate manifestation of evil big tech. They were introduced to encrypt the "last mile" because Internet Service Providers were replacing ads in webpages and, in the other direction, inserting fake clicks. DV has destroyed the internet. People loose their ebank savings and companies get ransomwared; phishing is dead simple. EDIW/EUDIW will become an identity fraud disaster (because of AitM phishing atracks). Even the name "Let's Encrypt" is wrong for a CSP: nobody needs a certificate to encrypt a connection. The primary purpose of a certificate is AUTHENTICATION (of the owner of the private key, in this case the website). However, for human beings, just a domain name simply does not provide reliable identification information. It renders impersonation a peace of cake. Decent online authentication is HARD. Get used to it instead of denying it. REASONS/EXAMPLES 🔹 Troy Hunt fell in the DV trap: https://infosec.exchange/@ErikvanStraten/114222237036021070 🔹 Google (and Troy Hunt!) killed non-DV certs (for profit) because of the stripe.com PoC. Now Chrome does not give you any more info than what Google argumented: https://infosec.exchange/@ErikvanStraten/114224682101772569 🔹 https:⧸⧸cancel-google.com/captcha was live yesterday: https://infosec.exchange/@ErikvanStraten/114224264440704546 🔹 Stop phishing proposal: https://infosec.exchange/@ErikvanStraten/113079966331873386 🔹 Lots of reasons why LE sucks: https://infosec.exchange/@ErikvanStraten/112914047006977222 (corrected link 09:20 UTC) 🔹 This website stopped registering junk .bond domain names, probably because there were too many every day (the last page I found): https://newly-registered-domains.abtdomain.com/2024-08-15-bond-newly-registered-domains-part-1/. However, this gang is still active, open the RELATIONS tab in https://www.virustotal.com/gui/ip-address/13.248.197.209/relations. You have to multiply the number of LE certs by approx. 5 because they also register subdomains and don't use wildcard certs. Source: https://www.bleepingcomputer.com/news/security/revolver-rabbit-gang-registers-500-000-domains-for-malware-campaigns/ @EUCommission@ec.social-network.europa.eu @letsencrypt @nlnet@nlnet.nl #Authentication #Impersonation #Spoofing #Phishing #DV #GoogleIsEvil #BigTechIsEvil #Certificates #httpsVShttp #AitM #MitM #FakeWebsites #CloudflareIsEvil #bond #dotBond #Spam #Infosec #Ransomware #Banks #CloudflareIsEvil #FakeWebsites

@aral : most Let's Encrypt (and other Domain Validated) certificates are issued to junk- or plain criminal websites.

They're the ultimate manifestation of evil big tech.

They were introduced to encrypt the "last mile" because Internet Service Providers were replacing ads in webpages and, in the other direction, inserting fake clicks.

DV has destroyed the internet. People loose their ebank savings and companies get ransomwared; phishing is dead simple. EDIW/EUDIW will become an identity fraud disaster (because of AitM phishing atracks).

Even the name "Let's Encrypt" is wrong for a CSP: nobody needs a certificate to encrypt a connection. The primary purpose of a certificate is AUTHENTICATION (of the owner of the private key, in this case the website).

However, for human beings, just a domain name simply does not provide reliable identification information. It renders impersonation a peace of cake.

Decent online authentication is HARD. Get used to it instead of denying it.

REASONS/EXAMPLES

🔹 Troy Hunt fell in the DV trap: infosec.exchange/@ErikvanStrat

🔹 Google (and Troy Hunt!) killed non-DV certs (for profit) because of the stripe.com PoC. Now Chrome does not give you any more info than what Google argumented: infosec.exchange/@ErikvanStrat

🔹 https:⧸⧸cancel-google.com/captcha was live yesterday: infosec.exchange/@ErikvanStrat

🔹 Stop phishing proposal: infosec.exchange/@ErikvanStrat

🔹 Lots of reasons why LE sucks:
infosec.exchange/@ErikvanStrat (corrected link 09:20 UTC)

🔹 This website stopped registering junk .bond domain names, probably because there were too many every day (the last page I found): newly-registered-domains.abtdo. However, this gang is still active, open the RELATIONS tab in virustotal.com/gui/ip-address/. You have to multiply the number of LE certs by approx. 5 because they also register subdomains and don't use wildcard certs. Source: bleepingcomputer.com/news/secu

@EUCommission @letsencrypt @nlnet

@troyhunt : if we open a website that we've never visited before, we need browsers to show us all available details about that website, and warn us if such details are not available.

We also need better (readable) certificates identifying the responsible / accountable party for a website.

We have been lied to that anonymous DV certificates are a good idea *also* for websites we need to trust. It's a hoax.

Important: certificates never directly warrant the trustworthyness of a website. They're about authenticity, which includes knowing who the owner is and in which country they are located. This helps ensuring that you can sue them (or not, if in e.g. Russia) which *indirectly* makes better identifiable websites more reliable.

More info in infosec.exchange/@ErikvanStrat (see also crt.sh/?Identity=mailchimp-sso).

Note: most people do not understand certificates, like @BjornW in mastodon.social/@BjornW/114064:

@letsencrypt offers certificates to encrypt the traffic between a website & your browser.

2x wrong.

A TLS v1.3 connection is encrypted before the website sends their certificate, which is used only for *authentication* of the website (using a digital signature over unguessable secret TLS connection parameters). A cert binds the domain name to a public key, and the website proves possession of the associated private key.

However, for people a domain name simply does not suffice for reliable identification. People need more info in the certificate and it should be shown to them when it changes.

Will you please help me get this topic seriously on the public agenda?

Edited 09:15 UTC to add: tap "Alt" in the images for details.

Ok HOW HARD CAN IT BE? 🤬

Currently trying to allow the #Windows machine I got from work (domain member, very much locked up, no local admin for me) in my private #wifi network (using 802.11x #authentication for #WPA with #freeradius and #PEAP using my own #samba based AD).

I don't strictly *need* it, the machine connects to my open guest wifi (mapped to a VLAN with access *only* to the internet), but it would be really nice being able to also access my local services while working at home.

What I tried:

- Just login (PEAP/MSCHAPv2), obviously. After lots of fiddling and reading logs (freeradius as well as windows events), I found some docs suggesting Windows doesn't support that any more unless you fiddle with something in HKLM, so, no dice, need something else...
- Allow EAP-TLS as well and issue a client certificate for my user, install that on windows. Doesn't work, the machine insists on using the machine cert from the machine store.
- Create a client cert with the UPN of my user in my home network in SAN ... same issue
- Create a client cert with the UPN of my *work* user in SAN ...
- Ok screw that, get freeradius to accept that stupid machine certificate: Allow the internal CA of my workplace and *only* the CN of exactly the machine certificate.

Now, it still won't work and I really don't get it, seeing stuff like:

(13) eap_tls: (TLS) TLS - recv TLS 1.3 Handshake, ClientHello
(13) eap_tls: (TLS) TLS - send TLS 1.1 Alert, fatal protocol_version
(13) eap_tls: ERROR: (TLS) TLS - Alert write:fatal:protocol version
(13) eap_tls: ERROR: (TLS) TLS - Server : Error in SSLv3 read client hello B

It makes little sense and all fiddling with TLS options so far didn't make it work. For other clients using PEAP, it just works with both TLS1.2 and TLS1.3. WTF is going on here?

The @w3c Federated Identity #WorkingGroup aims to create specs for secure, #privacy friendly, and user-controlled #authentication and credential presentation
▶️ w3.org/groups/wg/fedid/

Their updated charter introduces the Digital Credentials #API, which facilitates user agents in managing access to and presenting digital #credentials, such as a driver's license, government-issued ID, or other forms of digital credentials.

🎬 Find out more about this work by @sphcow: youtu.be/GI3UTZJ0Ue4

First, they shut down the Basic HTML site, forcing many of us to switch to clients such as Thunderbird. Now, they're using qr codes which are not only inaccessible to the blind but also to those who don't use smartphones! This is ridiculous! Yes, they do still have the option to click whether it's you trying to sign in or not (which still requires a smartphone and a carrier, which they claim to be concerned about), but how long before they remove that, too?

pcmag.com/news/google-is-repla…

Biggest phishing-test in history

So some weirdo, possibly Elon Musk, instructs you to reply by mail informing him what you did last week.

😱 You will be fired if you do - for failing the phishing test. You should have known that it's a hoax because Elon Musk just fired all the people who could read all of those mails.

And you should have known that you should not share confidential information via email because you don't know for sure who the recipient is. Neither do you know who reads the mail "on its way" and neither does the recipient know that you are who you say that you are.

Finaly, some mail ends up in spam boxes or gets dropped for frivolous reasons (Postel@RFC5321.whatever.tld)
(edited 17:23 UTC - corrected the RFC nr. 825 is not SMTP - sorry!)

😱 You will be fired if you don't.

It's a witch hunt. The Trump govt throws you in the water. You are not a witch if you drown.

blogs.loc.gov/law/2022/02/swim

New Kitten release

• Fixes redirection from sign-in page when person is already authenticated.

kitten.small-web.org

To learn more about how Kitten automatically implements authentication for your Small Web sites and apps using public-key cryptography (so even your own server doesn’t know your secret)¹, please see the Authentication tutorial:

kitten.small-web.org/tutorials

Enjoy!

:kitten:💕

¹ The security (and privacy) of Domain/Kitten are based on a 32-byte cryptographically random secret string that only the person who owns/controls a domain knows.

This is basically a Base256-encoded ed25519 secret key where the Base256 alphabet is a set of curated emoji surrogate pairs without any special modifiers chosen mainly from the animals, plants, and food groups with some exceptions (to avoid common phobias or triggers, etc.) that we call KittenMoji.

When setting up a Small Web app via Domain, this key is generated in the person’s browser, on their own computer, and is never communicated to either the Domain instance or the Kitten app being installed. Instead the ed25519 public key is sent to both and signed token authentication is used when the server needs to verify the owner’s identity (e.g., before allowing access to the administration area).

The expected/encouraged behaviour is for the person to store this secret in their password manager of choice.

More: kitten.small-web.org/reference