Non-repudiation and the joy of knowing you've been hacked
blog.authy.com
blog.authy.com
'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.'
Chances are???? What credible sys admin would ever do something like that...?
I have on frequent occasions mouthed words along these lines: "It's a bad idea to do it that way, but I can see how it would be much cheaper, efficient or easier to teach employees, so I will tell you the best way to do this bad thing."
You can carefully set up the best security possible, but the instant that a client or bigwig is waiting on something because of it, credentials will be shared and you or other employees may be ordered to share them.
It's just how it is.
If a company's smart, it'll only take one such complication to change that behavior. That behavior barely made sense in 1999 though and any company using shared super-user privileges in 2013 is just asking for a world of hurt...
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...".
It wouldn't start out that way as things would be "locked down" at first but every 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].
This is one of the problems that we're solving with JackDB[2](disclosure: I'm the founder). 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 per user you can selectively grant/revoke access to user's without asking them to "forget" old credentials.
[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.
JackDB: I like that the service keeps an audit trail on database transactions transparently, it is a big thing for companies that have to be compliant to a set of standards (i.e., health sector, financial sector, etc.) Good job!
Regarding SSH, it has the advantage that you can (and should!) have multiple authorized keys for the same account. For example for the bastion host to connect to our VPC of servers we use individual SSH keys tied to the same proxy account. Databases generally don't allow that type of access.
Some allow using client certificates to login (which nobody uses). Some allow integration with external LDAP/AD (which very few use). The vast majority uses standard username/password based authentication that hopefully is going over SSL (seriously go and check ... for most DBs by default it's sent over plaintext).
Some places try to have per user database accounts (possible tied to AD/LDAP) but that usually devolves to the same app password sharing as the privileges aren't kept in sync or it's just too much of a pain to provision vs just giving someone the app password.
I'm curious, your VPC bastion; how do you make managing SSH keys scalable given that setup? And why not separate accounts which in fact help with keeping sane logs of who did what, and distribute the risk of compromise across several accounts?
Yep. Couple of mouse clicks and a user no longer has access to one or more data sources (grants are role based). Similar effort for provisioning new users.
If the level of effort for a secure system is on par with emailing a password to a co-worker then people will actually use it. Plus with JackDB nobody other than the system admin even has the DB passwords so a normal user can't even send an email out if they wanted to.
> I'm curious, your VPC bastion; how do you make managing SSH keys scalable given that setup? And why not separate accounts which in fact help with keeping sane logs of who did what, and distribute the risk of compromise across several accounts?
At the moment things work for us as we're a very small team. Obviously something more scalable would be needed once you have a large number of people involved. The single proxy account is for convenience. That way the SSH keys to log into the other servers (accessible only through the bastion) can be shared. All servers (bastion included) log the public keys used to connect so we do have a trail of who/what/when. It would just be a bit more involved to filter it. Given our relatively small size it feels like a good tradeoff of security and convenience.
As we grow it's definitely something to (repeatedly) revisit, as is true about any security procedures.
Is that really common? I've never seen it.
Send it to the email account that will be protected by two-factor authentication using the key, and it won't really matter.
Unless, of course, the email is intercepted in transit.
If your email is being sent in the clear, it doesn't matter whether or not you use SSL and/or two-factor authentication to connect to your server - the email has been compromised long before.
> Unless, of course, the email is intercepted in transit.
> If your email is being sent in the clear, it doesn't matter whether or not you use SSL and/or two-factor authentication to connect to your server - the email has been compromised long before.
This isn't really as big of an issue as people make it out to be. TLS is fairly prevalent for MTAs.
Anyway, I assumed this was describing a scenario where a sysadmin/IT guy sends a QR code to another employee, in which case it is all internal.
No, "repudiation" is (in the relevant sense) denying responsibility for sending data or some other action. Non-repudiation is the property of a system that prevents (or, at least, makes more difficult) repudiation.