Username/password authentication strategy

Peter Vernigorov pitr.vern at gmail.com
Sun Jul 19 20:26:03 BST 2020


I am trying to implement a simple authentication for my Gemini site,
and was planning to use a client certificate CN field to pass
username:password pair to server. However, upon reading closely about
the TLS handshake -
https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -
it seems that the client (just like the server) certificate is sent
before the ChangeCipherSpec record, i.e. insecure. That means to me
that the CN field would be passed before the TLS session is started
and therefore not suitable as an authentication medium. Is that
correct?

Another alternative to implement username/password type authentication
in Gemini would be the sensitive input status code, but then I would
have to store a list of certificate fingerprint and username pairs,
greatly complicating the system.

Given that Gemini protocol strives to be minimal/low-cost for both
users and client/server devs, has anyone found a simple way to
implement username/password type authentication systems? To be fair, I
have attempted to use client short-/long-lived client certificates as
per recommendation in Gemini protocol specification; however, if
access to the same "account" from multiple devices and being able to
survive certificate loss without permanently losing access is my
account are requirements, this authentication method quickly becomes a
mess. For example, think about how one would go about getting access
to their astrobotany plant on a new device. This is why I ended up
going back to username/password authentication, but having
difficulties making sure that everything is secure. In need of
help/suggestions/ideas, thanks.


More information about the Gemini mailing list