hyprwm
Add password hash authentication
As an alternative to PAM authentication, password hash authentication only relies on the availability of libgcrypt (and some program like OpenSSL or sha256sum to create the hash).
Supports salted hashes and all hash algorithms that are available in the actual libgcrypt installation.
This is practical in more restricted environments. As an example: I work on a Ubuntu machine w/o root privileges and use Hyprland via Nix Home Manager. Ubuntu uses a patched PAM library to support their own @include primitive which is incompatible with standard PAM. Additionally dlopen across PAM library version does not work well from 1.6 to 1.5.
I am aware that the documentation likely has to move from the README to the Wiki, but I put it there for easy initial review.
- what does libgcrypt offer over libcrypto?
Hyprlock currently uses neither and I have just picked one of the two. Libgcrypt is much smaller and simpler than libcrypto as a whole. Although, mere one-off digest creation and checking looks quite similar in both. I knrew how to do it in libgcrypt. So I used it.
- is there not a C++ library?
I don't know of any famous and battle-proven library. Do you? So I stayed on the safe side. As the task is a purely functional "take this data, compute the digest and compare it to this other digest", there is no inherent value in a library with an object model. There is no state-transfer into libgcrypt which could collide with the C++ object model.
I just am not a fan of #define GCRYPT_NO_DEPRECATED and C-style code in general, but fair, if there is no better alternative
I think pam is fundamentally broken, so I am not entirely opposed to a custom Auth method.
Two security relevant things.
- hashing is too fast. we need an artificial delay (could be configurable). Otherwise brute forcing trivial passwords is too easy.
- I think we should store password hash + salt in a separate hyprlang config (like "secret.conf") and make sure it's permissions are -rw-r---- .
I think pam is fundamentally broken, so I am not entirely opposed to a custom Auth method.
Two security relevant things.
* hashing is too fast. we need an artificial delay (could be configurable). Otherwise brute forcing trivial passwords is too easy.
Is that not true for PAM as well? So, it should be some general artificial delay between login tries, not just for this method.
* I think we should store password hash + salt in a separate hyprlang config (like "secret.conf") and make sure it's permissions are -rw-r---- .
Well, I don't believe in security by obscurity. The strength of the hash is usually as good as any public key. If you entrust public keys to the public, you can as well with the hash. I know, though, that other people think different about this and leave this for you to decide.
What I just wrote is, of course, not equally true, for hashes that are used without salt.
Is that not true for PAM as well? So, it should be some general artificial delay between login tries, not just for this method.
All PAM login configurations i came across have such a delay. Edit: it is just the crypto inducing this delay i think
Well, I don't believe in security by obscurity. The strength of the hash is usually as good as any public key. If you entrust public keys to the public, you can as well with the hash. I know, though, that other people think different about this and leave this for you to decide.
No!! Password hashes need to be treated with care. Especially if the salt is also stored in the same file. You are right that having the password hash leaked to another user does not straight up mean they can login. But with enough time you might be able to find the password (for example, if the password is in rockyou.txt and you know the salt, it is game over).
Finding a private key for a corresponding public key is MUCH harder than finding the plaintext for a certain hash. For that your security is only the plaintext length. Edit: if you consider the whole input range, then yes it can be considered very hard to find the plaintext of a certain hash. but by making certain assumptions about a password (charset and length), weak passwords are trivial to guess, because sha256 is fast. This is why you normally use PBKDF for password hashes.
Is that not true for PAM as well? So, it should be some general artificial delay between login tries, not just for this method.
All PAM login configurations i came across have such a delay. Edit: it is just the crypto inducing this delay i think
Yeah, so I would just implement that near hyprlock.cpp: onPasswordCheckTimer() for all authentication interfaces.
Finding a private key for a corresponding public key is MUCH harder than finding the plaintext for a certain hash. For that your security is only the plaintext length. Edit: if you consider the whole input range, then yes it can be considered very hard to find the plaintext of a certain hash. but by making certain assumptions about a password (charset and length), weak passwords are trivial to guess, because sha256 is fast. This is why you normally use PBKDF for password hashes.
You are right! So, it must be a read-restricted file.
Since my last comment I
- Created a PR for an authentication interface, that makes it easier to integrate a new authentication method into hyprlock. (#578)
- Implemeneted a POC for hash based authentication using libsodium. See https://github.com/PaideiaDilemma/hyprlock/pull/2 I think this provides a better starting point. We just need to think about how users are supposed to generate the hash, or if hyprlock even does it for you.