๐Ÿ’พ Archived View for bbs.geminispace.org โ€บ u โ€บ mbays โ€บ 5259 captured on 2023-09-28 at 19:24:38. Gemini links have been rewritten to link to archived content

View Raw

More Information

โžก๏ธ Next capture (2023-11-04)

-=-=-=-=-=-=-

Re: "Gemini: Update User Certificate"

Comment in: s/Gemini

In principle, a general solution would be to sign a new certificate with the old one, then the server could automatically consider the new certificate to identify the same user the old one did. That seems much neater to me than the password-mediated approach. However, to my knowledge no existing server passes enough certificate information to (s)CGI scripts to implement this.

๐Ÿš€ mbays

2023-09-12 ยท 2 weeks ago

6 Later Comments โ†“

๐Ÿš€ clseibold

@tawkgsiw Firstly, a server cannot know if two certificates are from the same user without some type of system. If you just switch out your certificate without notifying the server of this switch, then there's no way to tell that this new cert should be associated with a particular account on the server.

Gemini does let you "upload" if it is within 1024 bytes (or whatever the URL limit is), but I think this isn't enough. However, certificates don't need to be "uploaded" via this, because they are sent to the server when you connect to it anyways.

This leads me to how existing services implement this currently. They will have some user db with another table for associated certs. When a person first makes their account, the cert they connected with is auto-associated as their first cert to their user. Then, they have a mechanism to add a password to the account. This allows you to switch the cert you are connecting with and then notify the server that this new cert you're connecting with should be added to a user's account, and the authentication for this is the password.

One could possibly implement a different system using Titan that doesn't require the use of a password system, but I haven't seen anyone try yet, I think.

@mbays has another interesting approach, but I haven't seen any server use this method. It would be cool to see this approach though, and clients would have to make this easily accessible, of course.

The password-mediated approach isn't the best unless there's some time limit on it, or it's a one-time use password. I don't like the permanent passwords that some services use because now the user is hackable via the password. If you can hack the password, then you can associate your own cert to the user you're hacking.

I think a one-time password is much better. Connect to the server using a cert already associated with the account, click to create a one-time password, then connect to a url with your new cert and input the one-time password, and the new cert is associated with the user. Then this one-time password gets deleted and cannot be used again.

๐Ÿš€ skyjake

I really should add something about this to the Help page...

Briefly, on BBS:

Now both certificates are linked to your account. You can then remove the old one(s) if you want on the same Certificate Settings page.

When it comes to signing with the old certificate, as @clseibold says, clients would need to automate this for it to be a feasible method. Otherwise it's too difficult to do for the average user.

๐Ÿš€ clseibold

@skyjake Oh! I didn't realize Bubble had time limit on the password! I think other services don't have this. I'm glad you did it like this, because it feels way more secure.

๐Ÿš€ mbays

Thinking about it, here's an even simpler approach: while a user is logged in (identified by one cert), show a link of the form "/addcert?$UID+$TOKEN" where UID is the key in the server's user database and TOKEN is e.g. sha256(UID+SECRET) where SECRET is a server secret. Then if that link is followed with a new certificate, the server can consider the new cert to belong to UID. Problem: copy+paste or having a shoulder-surfer could leak the token. Partial solution: make the token time-limited.

๐Ÿฆ‹ karel

Thank you so much, this was an interesting discussion. I would personally prefer the solution with the signature chain (sign the new certificate with the old one). Also thanks for telling me how the certificate update works on BBS. For some reason, I failed on the first attempt (yes, it works).

๐Ÿฆ‹ karel

@skyjake: Yes, please, add that text snippet to the Help page.

2023-09-15 ยท 2 weeks ago

Original Post

๐ŸŒ’ s/Gemini

Gemini: Update User Certificate โ€” Gemini uses certificates for login authentication. There are many valid reasons to change/update certificates. Certificates expire. Algorithms become outdated, keys too short. One might move from a global certificate to one per service (or the other way around). Change the user name and more. Yet, the protocol provides no way to update a certificate. I tested a certificate update both with Astrobotany and with the BBS and failed. Does anyone know of an...

๐Ÿ’ฌ karel ยท 10 comments ยท 2023-09-12 ยท 2 weeks ago