One interesting thing about Gemini is that we are all participating in an experiment with TLS client cert authentication. It appears to be such an elegantly simple idea, until you start to think about what happens when:
- My cert expires
- My computer is stolen or dies
- I want to log in from multiple devices
When I first signed up for Station, I set my client cert to expire two weeks later鈥攋ust long enough for me to completely forget about it. And now I'm totally locked out of that account with no way back in. (Also @martin, I am not picking on you or Station specifically!)
I wonder what patterns we will collectively come up with to address those shortcomings of client certs above?
2 years ago 路 馃憤 figbert, aka_dude
@comatoast @defunct it's currently up to each app to decide how they want to handle cert updating and account recovery. At the moment, Station doesn't support any sort of account recovery. If your cert expires, or you want to add another cert, you're out of luck鈥攁nd in the case of an expiring cert, you're completely locked out of your account forever.
Scroll down through the earlier comments to this post, between myself and @skyjake, there are several workarounds for this problem. Astrobotany does it with usernames and passwords (which, the crypto-utopians said would disappear once cert auth was ubiquitous), other options include emailed recovery tokens, etc. 路 2 years ago
Wait, so, there's no way to update my certs credientials? lmao. 路 2 years ago
having stumbled upon the same issue, how do I recover my accounts? my solution to this, or how i'll implement it rather, is going to be like what wallets are doing. after you sign up you'll get a recovery phrase that you can use to connect more/different certificates to your account 路 2 years ago
client cert authentication is at the edge of what gemini should be used for. imo
although,..i think it's good for users to be in contact with other users.
gemin is very light but it can do some neat tricks. 路 2 years ago
One thing that could be cool with the cert stuff is it can be used to implement our own version of OAuth by just letting a capsule generate a cert to use on another capsule.
So, I can create my own dashboard capsule (like start.me, etc.) and it can connect to a person's Station by generating a cert, and somehow redirecting the user to the station capsule to add that cert to the station account. And then the dashboard capsule can use that cert to connect to that specific account on station whenever it needs information from that user's station account. This would also allow users to easily delete this cert on station to stop the "OAuth". 路 2 years ago
I completely agree with @skyjake about capsules needing to be able to store multiple certs to one account. And this should be fairly easy to do in a database by creating a special cert table that links a cert to a userid in the users table (using a foreign key).
Now, for the losing of all of your certificates, that one is definitely harder to solve. Perhaps we could reuse some ideas from something like 1Password. They will give users a pdf of the username, secret key, and password that users can print out or store somewhere.
There's also ideas from Two-Factor Authentication we could experiment with, like using text messages, etc. 路 2 years ago
@skyjake really good points.
Along with servers remembering all expired certs, links with one-time random tokens could work too, for both an expired certs and adding a second device.
Your current cert has expired, visit this link with a new cert: => gemini://some.server/cert-recovery/abc123def456
If you totally lost your cert, you'd still be hosed, although the above magic-link could be emailed to an address on file if you'd previously given the service one. 路 2 years ago
I think this requires both server and client side solutions.
On the server, you need a way to add multiple certs on an account. One way is what AstroBotany does. Another could be an expiring random PIN, so you have e.g. one minute to use it. A server also needs to keep track of revoked certs, for stolen/deleted ones.
On client side, the best I can think of is to just keep all your certs in a password manager. (I use Bitwarden for instance). This solves the most prominent sync and security concerns. A sophisticated client could integrate with a password manager to make it seamless for the user. 路 2 years ago
@martin Astrobotany solves the three "what if..." bullet points with usernames and passwords. That does solve all three problems, but now I've got to have a password manager in addition to my cert manager. It seems like we should be able to come up with something better (beats me what it is, though).
I was led to believe 馃 crypto would solve the password problem
Again, I am not trying to criticize or whine. I deal with this kind of thing at my day job and am not sure how to solve it either. 路 2 years ago
It's a good point you raise. It's not clear what patterns people should follow to avoid the common issues, and it also puts some pressure on every app to build mechanisms to help with these issues (which Station currently doens't have). 路 2 years ago
BTW @martin and @skyjake, I specifically mentioned both of your projects in this mini rant, but I want to clarify that I am not whining or complaining, and I think what each of you have done is really amazing. Thank you both! 路 2 years ago
The other thing about client certs is, a client cert is the ultimate trackable cookie. So you must generate new client certs for every domain you want to use, and then have a client that will turn them on and off based on some kind of rule. Even trickier if you want to have multiple accounts on the same service.
Lagrange does a great job of this, and its approach works for the small number of Gemini capsules I've got certs for. But imagine this at web-scale. Instead of a password manager you鈥檝e got a dedicated cert manager with a gazillion certs in it, but much more complex because it would need to handle expiration notifications and renewals.
Not an easy problem! 路 2 years ago