![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Password management
Jan. 13th, 2015 07:26 pmSo here's a question that I'm unable to solve. It's possible I'm dragging myself down a rabbit hole. Or missing the bloody obvious.
I'm building a new server. There's no SSH/telnet/etc. There's only a console. (And, if necessary, it doesn't need to run a normal getty; I can run whatever I like).
Emergency access to the server is via the console (and will be "burn after use"; ie the server gets rebuilt).
How do I ensure that only "authorised access" is allowed? Clearly we can't have a common root password, 'cos that would end up being known.
So idea #1 is generate random password on build, store password in a password vault. This has niceties; pulling the password can trigger a time rebuild event, is trackable, etc.
The question then becomes "how do we guarantee access to the vault is properly secure"; what's to stop a person bypassing the front door? Passwords stored in a vault must be decryptable (in order to be used) so _could_ be stolen. (Security through obscurity? use a commercial product where we can't know the algorithm used to encrypt?).
Idea #2 was something like OPIE or S/KEY... but then there's still a shared secret that needs to be stored somewhere (any key that can be algorithmically defined can be repeated by an attacker).
Every idea I've come up with ends up just punting the question back a level. The only way I could break the loop was to use eTrust Control Minder (aka eTrust Access Control, originally called SEOS) to even prevent root from accessing the password database and ensuring it's only accessed via the front doors.
There's got to be a better way.
But I'm not seeing it :-(
I'm building a new server. There's no SSH/telnet/etc. There's only a console. (And, if necessary, it doesn't need to run a normal getty; I can run whatever I like).
Emergency access to the server is via the console (and will be "burn after use"; ie the server gets rebuilt).
How do I ensure that only "authorised access" is allowed? Clearly we can't have a common root password, 'cos that would end up being known.
So idea #1 is generate random password on build, store password in a password vault. This has niceties; pulling the password can trigger a time rebuild event, is trackable, etc.
The question then becomes "how do we guarantee access to the vault is properly secure"; what's to stop a person bypassing the front door? Passwords stored in a vault must be decryptable (in order to be used) so _could_ be stolen. (Security through obscurity? use a commercial product where we can't know the algorithm used to encrypt?).
Idea #2 was something like OPIE or S/KEY... but then there's still a shared secret that needs to be stored somewhere (any key that can be algorithmically defined can be repeated by an attacker).
Every idea I've come up with ends up just punting the question back a level. The only way I could break the loop was to use eTrust Control Minder (aka eTrust Access Control, originally called SEOS) to even prevent root from accessing the password database and ensuring it's only accessed via the front doors.
There's got to be a better way.
But I'm not seeing it :-(
