Of course you have to know the salt, but I'm suggesting something like using a different storage medium, so that one vector of attack cannot get both keys- unknown to the attacker.
That's dangerously close to "security through obscurity" - whatever process reads the passwd store has to know about and have permission to read the salt store - so just putting it in a different file or giving it a different name only buys you a false sense of security.
The reason for moving the passwords out of /etc/passwd is that there are a s lot of processes that do need to read the user list but don't need access to the passwd hash. But there is nothing to gain from splitting the salts out of /etc/shadow into a another file
Comments
Of course you have to know the salt, but I'm suggesting something like using a different storage medium, so that one vector of attack cannot get both keys- unknown to the attacker.
I should have made that more clear.
That's dangerously close to "security through obscurity" - whatever process reads the passwd store has to know about and have permission to read the salt store - so just putting it in a different file or giving it a different name only buys you a false sense of security.
The reason for moving the passwords out of /etc/passwd is that there are a s lot of processes that do need to read the user list but don't need access to the passwd hash. But there is nothing to gain from splitting the salts out of /etc/shadow into a another file