On 2021-08-23 20:56, cho8jeiv4aus at paperboats.net wrote:
Hi there. I had an idea recently for an onion service to improve the UX of sites that require a login. The site would have two onions: one for those who want to use onion auth and another for those who don't or are still setting it up. A user would first sign in with a username+password on the unauthenticated onion and click a button to generate a certificate associated with their account. Then they would add the public key to their browser and visit the authenticated onion. The application server would then match the pubkey used to authenticate with an account in the database, and log them in automatically.
As for your case, you could maybe try client-side TLS certificates.
I've had a similar idea for DoS protection. You have two onions, call them "open" and "closed".
In the good times, you go to the "open" onion and register. It gives you a client authentication password for "closed" and redirects you there. On subsequent logins, you just go straight to the "closed" onion. (In theory, it's enough to have the key get you to the login screen - it doesn't actually have to replace authentication)
Then, when the attack comes, it will take down the "open" onion. However, the "closed" onion is protected by client auth, and can be rate-limited by key.
The only thing that would be needed for this is a special version of client authorization that allows the server to see *which* key is connecting, as opposed to "some key but you don't know which for privacy reasons".
As an operator, an alternative would be to generate one (authenticated) onion service per user and route them all to the same place with different Host headers, but that seems rather inefficient, and I don't know how well the tor daemon scales up to hundreds of onion services anyway.
That's not great for the network.