Hi all. I'm wondering: why does the Gemini specification object so strongly to using "userinfo" credentials in the URL? I can see the advantages of client certificates for technically-minded users, and for server-side developers. But user/password is a pretty common paradigm in the ordinary web.
Does anybody know why the "userinfo" approach was so roundly rejected?
Posted in: s/Gemini
🚀 lars_the_bear
May 11 · 11 days ago
😎 flipperzero · May 11 at 16:52:
When you say "userinfo credentials in the URL" do you mean as in a login interaction between client to server for a platform outside of assigning a cert to a capsule, closer to what happens on the web, but instead of the username and pass being represented as hashes or tokens in the URL to -completely- present verbatim plaintext -in- the URL? Even as I describe that, you might appreciate just how dicey that can be lol. Unless I'm misunderstanding, and you mean representing that info but doing so via generated token or hash sum?
Where in the specification is this stated?
🌆 skyjake [mod...] · May 11 at 17:26:
Have you checked out the Gemini FAQ section 4?
In lieu of cookies, Gemini allows using TLS client certificates as a way for the user to authenticate themselves to apps. Compared to passwords and cookies, this is far less vulnerable to brute force attacks and session hi-jacking, and users always have the right to instantly, irrevocably and unilaterally delete their private key, permanently ending a session.
In short, client certificates are preferred because they are more secure and easier to implement as well.
Those are sufficient reasons to drop username/password authentication entirely as redundant and suboptimal.
🚀 SavaRocks · May 11 at 18:28:
+ all the "parameters" are present in the URL. so a request &user=sava?password=123456 is not secure at all
🐑 zipsegv · May 12 at 01:46:
I can see the advantages of client certificates for technically-minded users
honestly, I don't think certificates are too complicated even for non-technically-minded users. instead of a username/password pair, you login with an "identity" that your browser stores (the user doesn't even have to know it's a certificate). it takes a bit of getting used to but I don't think it's super hard or anything (although I /am/ technically minded so I'd like to hear from someone who isn't if my guess is right).
🚀 SavaRocks · May 12 at 05:03:
@zipsegv LaGrange makes it easy for users to create and delete identities/certs. You don't have to fiddle around with the terminal and enter commands that are a mile long to create a cert.
🚀 lars_the_bear [OP] · May 12 at 07:43:
@skyjake : "In short, client certificates are preferred because they are more secure... "
I hear this all the time, but I've never been convinced. I have to store my certificates, but my passwords live only in my head. If I store my certificates, they are vulnerable to being stolen, which requires additional security, plus "master" passwords and what-not.
And even if client certificates are "preferred", that doesn't explain why the alternatives are disallowed so completely.
@flipperzero : For the record, in the "overview" it says:
2. the userinfo portion of a URI MUST NOT be used;
and then in the "Requests" section it says:
> A server MUST reject a request with a userinfo portion.
It must be a big deal, to ban it twice.
And, yes, having the client display the userinfo section on screen would be dodgy. But having the client display the user's data entry in the URL is also dodgy, and I think all clients tend to do that. Avoiding these issues is a matter of client design.
🚀 lars_the_bear [OP] · May 12 at 07:51:
@zipsegv : "I don't think certificates are too complicated even for non-technically-minded users."
I think you're overestimating the average IT user. It's not that the _steps_ in creating a certificate are difficult: all modern clients make this a click-click-click operation. It's the _concept_ that's difficult. Everybody knows user/password -- we've all be using it for years.
Client cert authentication has been available in the regular web for at least twenty years, but it never caught on. There's a reason for that.
🌆 skyjake [mod...] · May 12 at 09:24:
@lars_the_bear:
doesn't explain why the alternatives are disallowed so completely
This is about Gemini's general principles: not providing overlapping alternatives and options if there is one good way to solve something. FAQ 1.1.2:
... a strong philosophy of "keep it simple" and "less is enough". This allows Gemini to simply sidestep, rather than try and probably fail to solve, many of the problems plaguing the modern web
@lars_the_bear:
my passwords live only in my head
Good for you, but probably not a good solution for most people. Making passwords actually secure requires password managers and multifactor authentication methods. Even the web is awkwardly moving to passkeys (a.k.a. certificates).
Certainly there are ways to implement client certificates poorly, too, but if you follow best practices (like store them in the operating system's secure keychain), you are pretty tight securitywise, since you are relying on TLS to do the cryptographic heavy lifting.
🚀 lars_the_bear [OP] · May 12 at 13:49:
@skyjake : "Even the web is awkwardly moving to passkeys..."
Very slowly, and it will only happen if it's forced on people, and only then against their resistance. Passkeys have the same problems that multiple strong passwords have: you have to have tools to generate them, and you need some place to back them up (that you trust).
I do take the point, though, of not wanting to provide multiple ways to do the same thing. Still to have the spec _ban_ alternative authentication techniques, that some clients and servers might want to support, seems a bit paternalistic to me.
🚀 jsreed5 · May 12 at 17:52:
I can't say for sure why userinfo is explicitly disallowed in the Gemini spec, though I agree it's probably meant to enforce use of certificates as the only mechanism for user authentication. It's worth noting, though, that Gemini is best thought of as an extension to Gopher rather than a reduction of HTTP, and Gopher also does not support userinfo in URIs.
Also, I agree that sending user-supplied data as part of the URI isn't secure. That's another aspect of Gemini taking design cues from Gopher and not HTTP, since neither protocol has an equivalent to HTTP's POST method. The closest analogue available to Gemini is the Titan protocol--which is partly why Titan support is growing in Geminispace.
😎 flipperzero · May 12 at 17:57:
@jsreed5 Gemini is not an "extension" of Gopher because it uses none of the Gopher codebase nor any of the standards or most principles. Gemini is an elaboration of a concept which hybridizes the two -between- what Gopher and the Web provide in a bare-minimum presentation and execution.
btw on that note of titan, isn't spartan similar in that it's not encryptedd? I thought they still require certificate-authentication in order to interface between host to client for server-end operations anyhow, unless I'm mistaken and please feel free to correct me if so.
on further note to that, I observe that titan and spartan also employ the very approach we all seem to be mutually frowning down on the userinfo being appended to the URL - again, unless i'm mistaken, and instead is a hash of the cert assigned represented in URI scheme.
🦂 zzo38 · May 12 at 19:55:
Spartan allows the URL to include a username and password but they are not used (I don't know why it is allowed at all then; it does not seems to make sense). X.509 certificates are better authentication for many reasons, though. Scorpion does allow a password (implementation is optional) but recommends that you use X.509 instead if possible. Regardless of the protocol, if the userinfo in the URL is present, an implementation can be made to not display the password.
👽 spc476 · May 12 at 20:35:
For those curious as to what this is about, it's about including a username/password in the URL, like:
gemini://john:god@example.net/foo/bar
I'm partially responsible for this. Solderpunk was looking to add a reponse that asks for a username/password (like the above) when I suggested the use of client certificates as an alternative. My thinking at the time was the the server side could generate a certificate for the client to use to be granted authorization for parts of the site. Solderpunk took it in a completely different way, and then mandated that the user creditials in the URL was NOT the way to go.
😎 flipperzero · May 12 at 20:38:
@spc476 omfg wow hi! thanks for joining us here part of the discussion on Bubble BBS and I hope you find your time nice. :D Ok sorry aside from fanboying RE OG mailing list matters ehehe
I think this was a very good, important contribution! Your thinking was correct - look at misfin. Try out gemini://woodpeckersnest.space:1958 as an example of such implementation. This is also possible client-side as evidenced by skyjake's lagrange. I don't see anything wrong with, and very much prefer, this approach of user interaction and data integration between client to server far more than sharing plaintext details YUCK!
@skyjake excuse my tardiness being late back to the party like this, but thank you very much for your cited reference as it's what I thought was the matter (which is also why I cringed as much in description as I was making detail haha)
So far, this method seems to work just fine, if not just doing so by either web frontend or remote shell interface (like what I do with my spot) and screening things that way.
🚀 mk270 · May 21 at 16:02:
The use of userinfo is also a vector for extending the protocol via a side-channel. I could be mistaken, but this was cited on that accursed mailing list as one of the reasons for banning it.
🚀 lars_the_bear [OP] · May 21 at 16:47:
@mk270 : "userinfo is also a vector for extending the protocol via a side-channel"
I suppose it could be, if you used it for something _other than_ authentication. I guess that's why URL fragments are banned, also.
I agree that it makes sense to ban userinfo if it _isn't_ used for authentication, but that doesn't explain why it's banned for authentication. I guess some of the forgoing disucssion explains that, but I still think it was the wrong decision, on balance.