I think the author is missing the real problem. Why is there a single "admin" account at all? Why don't users log in with their "normal" user accounts, and then use some kind of authenticated, audited privilege escalation (like sudo, for example) to perform tasks that require administrative privileges?
> Which brings us to shared accounts. Having worked with hundreds of companies over the past couple of years, we've learned that shared accounts are ubiquitous, specially for infrastructure accounts (if your company uses SSH, chances are you have one Unix Login that all your admins/employees share). Which makes non-repudiation harder.<p>I've seen this first hand at a number of large companies for both unix accounts and (even more so) with database accounts. After some period of time (varies from 1 month to 1 year) everybody who worked on an application would have the database credentials of the application and would use them to diagnose app issues. New members of the team for an app would be given all the credentials too as "it's the only way to get things done...".<p>It wouldn't start out that way as things would be "locked down" at first but <i>every</i> app ended up like that. Add to this that folks tend not to ever rotate their application database passwords for fear of breaking something and you've got a ton of people with the same access credentials and no way to distinguish them. People would join/leave the group (or even the company) that managed an app and would forever have access to all the databases for the app[1].<p>This is one of the problems that we're solving with JackDB[2](<i>disclosure: I'm the founder</i>). It allows you to share data sources without sharing passwords. User's authenticate as themselves and the server proxies the database connection for them. All executed commands (SQL, etc) are added to an audit trail and since you can tie actions to actual users you know who made changes, who queried customer records etc. Similarly since access is done <i>per user</i> you can selectively grant/revoke access to user's without asking them to "forget" old credentials.<p>[1]: Yes firewalls can block things as well but if you're still an employee somewhere then you can probably get passed the internal firewall by tunneling through some other server you have access to.<p>[2]: <a href="http://www.jackdb.com/home.html" rel="nofollow">http://www.jackdb.com/home.html</a>
The idea that a serious compromise will present a clear path back to a specific ssh key that got used by the attackers and that you'll possibly be able to stop it just by turning off that key is pretty laughable. But then again, so is protecting your core infrastructure with 1.5 factor android soft tokens. Google isn't even willing to make it sound like especially strong protection for your gmail account. How much for a CAC style pki infrastructure? Hard to believe it's more than $50-$100/seat for a small organization. If you're worried about figuring out which employee got his phone dropped after your whole backend got molested perhaps an actual security posture would be more suitable.
Why do so many people need access to this 'admin' account. Is this an infrastructure problem? I'm struck by the idea the author is discussing how to properly share access to a single account on an OS that was conceived as multiuser.
"if your company uses SSH, chances are you have one Unix Login that all your admins/employees share"<p>Is that really common? I've never seen it.
Does obtaining the original Google authenticator QR code actually let you impersonate the authenticator? I was hoping it was a one-time shared secret only used for the authenticator to identify itself to the server for bootstrapping purposes and that a used QR code would be worthless.
Doesn't non-repudiation mean the opposite of what he is saying? I.e. isn't "being able to proof where something comes from or who did what" just repudiation?
How should we store passwords? IAM is clearly a big industry for big companies, but lots of people have the problem. There has to be a simple solution?