This post assumes that people understand on what exactly is public key cryptography’s digital signature and how a cryptographic random number generator (CRNG) works. If people don’t understand what’s digital signature or CRNG. Here’s 2 of the links available (https://www.youtube.com/watch?v=nybVFJVXbww&pp=ygUlY29tcHV0ZXJwaGlsZSBlbGxpcHRpYyBjdXJ2ZSBiYWNrZG9vcg%3D%3D), (How to Explain Public-Key Cryptography and Digital Signatures to Non-Techies).
When I am making this post, I don’t think I could convince people as I couldn’t convince myself either. For nerdy folks, they know more than what I know. For general folks, it might not seem like a big deal as security is normally not one’s primary concern.
I don’t know exactly what PassKey was, I just happened to know in FIDO, it uses a mechanism that was called as digital signature with challenge and respond. It works like the following.
- Client generates a digital signature keypair (Stores both public and private key on their device)
- Client sends the signature keypair’s public key to the server during registration
- When client wants to login, he/she requests for challenge from server (a randomly generated and publicly disclosable data that was based on CRNG which is at least 16 bytes long)
- Client fetches the challenge from server and signs it with their private key.
- Client sends the signed challenge to the server and awaits for signature verification response (success or fail).
These steps are similar to how technological decentralization works in the Linux (Many distros and some distros were remade from scratch based on the concept of Linux) world or possibly the future of open source hardware.
There’re no particular steps or procedures as how one should implement them. If done correctly, it means that the server side only stores public key and the authentication between client and server somehow was immune to common keylogger attacks exclude the attack such as clipboard data based attacks (clipboard data refers to a memory space where you copy something and paste it, while pasting it’s using the memory that stores the clipboard data). People can say farewell to problematic passwords be it user side or developer side. As stated by thehatedone or mental outlaw, passwords are a problem.
However, there’re some potential issues that arises with the steps listed above. Some issues include requiring the skill of language interoperability or some sorts of “wrapping” capability, not many languages support state-of-the-art techniques by default. These kinds of best practices commonly can be seen only in security audited library such as libsodium which it’s coded entirely in C.
What FIDO was doing is both good and bad in its way on one hand it is making the security of the developer side more secure but the bad side is with the involvement of biometrics like fingerprint or some sorts, these sort of data are big privacy and security risks. If there’s involvement with additional hardware like perhaps a USB key that stores the private key, it also means that there’re more e-wastes.
Another potential drawback is that perhaps it needs to involve with some forms of PKI (Public Key Infrastructure).
User familiarity and developer familiarity is also an issue or a drawback because people i mean the majority are fond with “something you know” and the most common example is password or passphrase. Stuffs that work with passwords may not work with this approach as they belong to different category and the most common example is account recovery of password authentication via email.
Memory safety with passwords couldn’t be done. Passwords or most cryptographical keys (can assume like the certificate or private key paired with the certificate is in immutable data type or typically store in string format) due to certain considerations… can’t be removed in memory securely after use. In C#, one would say there’s some existence of securestring but still it’s not really that recommended. Other common example will be that perhaps in all CLI or terminal based applications, the invisible password keyed in is also using securestring of some sort. Cryptographical sensitive data such as private key and secret key need to use mutable data as what we have seen in C such as unsigned_char* or uint_8* or void address* or in C# it’s byte/IntPtr or in Java it’s byte/pointer.
Even if all things were done correctly, challenge and respond with digital signature based passwordless authentication could only sustain until 2030. At that point of time such an authentication mechanism is unknown whether they are considered to be secure against era that’s slowly entering into quantum computer.
I have created a framework (GitHub - Chewhern/PKDSA: This repository will be storing the code required in allowing public key authentication.) that is essentially a full stack application but the foundation of the framework is in Web API format. The server application code (ASP.Net Core 6 or .Net 6) is best if developers could use an unmanaged VPS or similar to that of cloud IAAS to host or deploy it. Both the remaining 2 applications is desktop application or GUI application that is coded by .Net 6 (Winforms)
This is the management application which primarily have a communication with the server.
This is the signing application which primarily responsible to sign the challenge received from server.
There’re 2 ways that one can implement it within their application. One is by essentially having full stack deployed on their end. The other one is just developer need to figure out the flow of logic behind number 5 in the management application picture along with the logic behind signing application because ultimately for this to work it needs to be implemented in the form of form be it in web pages or some other OS or platforms (mobile or tablet).
Common shared problems with my version of approach and passwords, they both have storage issues. In the short run, the above approach is more privacy friendly and sovereignty friendly compare to passwords but in the long run, the above approach when compared with passwords perhaps people will think that it’s not really that privacy friendly or sovereignty friendly. They also have an unsolvable and unaddressable (partially solve, addressable) issue which is the trust towards the provider.
My version of approach has the technicality issue, CRNG issue and mutable data issue. Currently, my version requires the use of libsodium to verify the signed challenge received from server by using server’s public key and I don’t know whether this extra step is required. I couldn’t really consult anyone. CRNG issue is an issue that all the cryptographical keys generated is essentially can’t be recover if they were lost unlike password or seed based approach. All cryptographical keys are stored in files using mutable data type and these data type are quite hard to distinguish whether their insides have been altered as it currently only relies on the correct file name to know this is storing cryptographic public or private data.
Another thing that’s worth mentioning is the AGPL V3.0 license in my application. I was highly confused… some says it covers only on modifications of the said licensed software and has to be open source under same license. some says it covers not only on modifications but also on usage.
The purpose I request for Session Messenger’s user ID during sign up is because in case the master public key was indeed changed at least there’s some out-of-band communication that I can use that’s not made by me with the potential and supposedly rightful owner of the public key and make changes accordingly.
This might seemed to be overkill perhaps to F-Droid developers or F-Droid forum users. If that’s the case, it’s alright. I just hope I don’t miss anything and tried my best in achieving well-informed consent.