Public key cryptography has a lot of highly interesting features. By utilising its asymmetric parts, you can even implement authentication based upon asking the server for a “cryptography challenge”. Basically the way it works is as follows.
- The client asks the server for a challenge
- The server returns the challenge to the client
- The client cryptographically signs the challenge and submits it back to the server
- The server returns a valid JWT token the user can use for consecutive requests, but only if the challenge is accepted and the signature is verified
Simply thinking about the potential use cases is actually quite breath taking, since it completely eliminates the two by far largest uncertainties related to authentication – Being of course the user’s username and his password. Hence, if you can secure a private cryptography key somehow on your users’ clients, you end up with an authentication scheme that is probably a million times more secure for these simple reasons.
- No username?
- No password?
- No PROBLEM 🙂
I’ve been thinking about this idea for quite some time to be honest with you, and just for kicks I implemented it today in Magic – Of course in such a way that you can also easily implement it yourself in your own clients. Watch the following video for a walkthrough of how I did it.
The basic idea is that you associate a public key with a user record, and if a challenge is requested, cryptographically signed, and pushed back to the server – The server has a cryptographic guarantee of that it was created by the user behind the user record. No password, no username, zilch problems!
In fact, the client doesn’t even need to KNOW ITS USERNAME
Still, probably several orders of magnitudes more secure than a traditional username/password approach. Of course, I’ve still kept the traditional authentication scheme in Magic since I want to be able to provide both solutions to people wanting to consume Magic. But completely turning off username/password authentication is as simple as deleting a simple file – Of course the Hyperlambda file encapsulating the username/password HTTP authentication scheme endpoint that is.
If you want to build this into clients of your own design, you might benefit from using the C# only parts of the magic.crypto project, that already wraps most of the functions required to both create cryptography key pairs on your client, in addition to cryptographically signing payloads. If you’re not in .Net land, you still need to carefully read the specifications for how the cryptography packages are assumed to look like, since Magic internally uses that project, and expects packages of the same structure.
If you’d like to play around with this, you can download Magic below.