Show HN: Secure login distribution service

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.

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...

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.

Don't authenticate to servers with a password. Ever. Use public key authentication.

What's wrong with good old fashioned pam modules to put users in sudo/non-sudo groups?

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.

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.

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.

I've tried to understand what this is but I can't crack the English. Anyone got an ELI5?