More cryptographically secure hash

[joeskeen]

Is your feature request related to a problem? Please describe.

The built-in backdoor for libki-client to exit without authenticating with the server uses md5 hashing with no salt. Any user of the system that can get to the Libki Client config file can see the hash and the explanation. As md5 has been around a long time, it has become trivial to defeat any security using this hashing algorithm. For example:

Here is the official OWASP report on this subject: https://owasp.org/www-project-mobile-top-10/2016-risks/m5-insufficient-cryptography.

Describe the solution you'd like

Methods for securely storing hashed passwords are described in the OWASP cheat sheets: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#methods-for-enhancing-password-storage. In summary:

• Use salt and/or pepper in addition to hashing
• Use a secure password hashing algorithm, such as Argon2id, scrypt, bcrypt, or PBKDF2.

When implementing a hash change, you also need to consider upgrading the existing hashes. OWASP has some guidance on this as well: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#upgrading-legacy-hashes.

Describe alternatives you've considered

In the short amount of time I've evaluated Libki for use in my computer lab, I have searched for ways to make it impossible for the user to discover the contents of the Libki configuration file; however, it seems that the user ends up with at least as much privilege as the Libki client executable, which means that there wouldn't be a way to make it readable from the Libki client, but restrict access from the user. But perhaps I'm wrong about that. I'd be thrilled to have that better explained to me.

Additional context

I'm excited to use Libki, but I want to make sure that my users (which so far will end up being my children and their friends) are unable to circumvent the restrictions I intend to put into place. If my kids turn out anything like me, these security measures will be insufficient to prevent abuse of the system. I can only assume that other use cases in libraries, internet cafes, etc. would suffer the same vulnerabilities, and the system could be compromised to for example run key loggers without anyone knowing.

[kylemhall]

Just a reminder that Libki is not security software, and should not be used in place of security software.

That said, it looks like both Inno and Qt have support for SHA-256:

https://jrsoftware.org/ishelp/index.php?topic=isxfunc_getsha256ofunicodestring

https://doc.qt.io/Qt-5/qcryptographichash.html

Adding a salt would be complicated. If we put it in the Libki config, the salt would be pointless, as would any other place on the client side. If we have it on the server side, the client installer would need to know about and connect to the Libki server to generate the salted password. This is nontrivial at the least!

[joeskeen]

Imho the salt can be stored with the hash in the same file. Generally salts are not considered secret; their purpose is to make it almost impossible for there to exist a rainbow table including that hash, as the rainbow table would have had to contain an entry using both the plaintext password as well as the same salt. With a huge amount of possible salts, it's nontrivial to try all the combinations ahead of time so websites like the one referenced above wouldn't be useful.