Forgive me if I'm missing something obvious, but if I brute force one hashed version of a password (and recovered the plaintext version), then what difference would it make that other servers have it hashed differently? I already know the actual password...
Actually waiting for the TTL to run out and requesting a new password reveals more information than one hash would. Shouldn't matter in case of perfect hash algorithm, but in practice...
Interesting idea, but the justification is completely wrong:
> There is no way of configuring local root (like, available only through IPMI) on the frontend load-balancing servers through remote authorisation agent.
You can have users which are not allowed via sshd. You can also configure local auth that takes precedence over ldap attempts.
It's also very confusing in what it does:
> found collision to that single hash attacker actually got access to all servers with that hash.
yet with shadowd:
> One shadowd instance can be used for securely instanciate thousands of servers with same root password for each one.
I'm not sure how that's any different. You're still using one password.
Better use ssh-keys only auth.
Simply periodically pull public keys from server and write them to ~/.ssh/authorized_keys. Secure and simple, and pretty hard to crack - its RSA.
If you use same password to login to multiple servers and if one server is compromised via SHA collision (which the author assumes to be much faster than password brute force), then basically all the servers are compromised (since they have same hash).
The author proposes to have different hashes in each different servers but user only have to know one password. This is achieved by this shadowd.
So, if one server is compromised, the others are still safe.
(Consider this as a beginning to understand the rest of the README)
There is more to managing servers than just logging in. Using a central store for users and groups can provide consistency across systems. I'll grant you that LDAP is pretty complicated and there are vendors, at least, that are looking at REST API's instead of LDAP on the wire.
After a quick glance at the code, I noticed the salt is limited to letters only ("qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM"), which limits the possibilities to 52 per byte instead of allowing 256 values. One can fathom this was done because of a misunderstanding of the need for the hash to be ASCII printable without using hex to encode it. Even so, it could have included numbers and all other printable characters.
It uses 16 bytes of salt, but each byte is crippled to roughly 1/5th of the amount of psudo-random bits it can carry. As implemented, this 16 byte salt is equivalent to 3.25 bytes (26 bits) of pseudo-random data (52/256*16).
This person at least made their source code available. When you run closed-sourced security-sensitive software, you're just taking the vendor's word for it.
This is a poorly justified solution to a real security problem, which is the elimination of password logins. The author assumes that the weak point in logins is the password hash, and rarely if ever is this an attack vector in modern Linux.
Disabling password logins, moving to SSH public key based login and hardware tokens (such as the SSH private key stored in Yubikey) is a much better solution than the one proposed here.
14 comments
[ 1.5 ms ] story [ 35.1 ms ] thread> There is no way of configuring local root (like, available only through IPMI) on the frontend load-balancing servers through remote authorisation agent.
You can have users which are not allowed via sshd. You can also configure local auth that takes precedence over ldap attempts.
It's also very confusing in what it does:
> found collision to that single hash attacker actually got access to all servers with that hash.
yet with shadowd:
> One shadowd instance can be used for securely instanciate thousands of servers with same root password for each one.
I'm not sure how that's any different. You're still using one password.
The author proposes to have different hashes in each different servers but user only have to know one password. This is achieved by this shadowd.
So, if one server is compromised, the others are still safe.
(Consider this as a beginning to understand the rest of the README)
What's wrong with good old fashioned pam modules to put users in sudo/non-sudo groups?
It uses 16 bytes of salt, but each byte is crippled to roughly 1/5th of the amount of psudo-random bits it can carry. As implemented, this 16 byte salt is equivalent to 3.25 bytes (26 bits) of pseudo-random data (52/256*16).
This person at least made their source code available. When you run closed-sourced security-sensitive software, you're just taking the vendor's word for it.
Disabling password logins, moving to SSH public key based login and hardware tokens (such as the SSH private key stored in Yubikey) is a much better solution than the one proposed here.