6 ms·

Non-repudiation and the joy of knowing you've been hacked

33 points by Vaismania 13y ago

bcoates 13y ago
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.
- thirsteh 13y ago
  Yes it does. The QR code just contains the TOTP key and title. Send it to the email account that will be protected by two-factor authentication using the key, and it won't really matter.
  - chimeracoder 13y ago
    > 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.
    - thirsteh 13y ago
      >> 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. 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.
- sp332 13y ago
  I like the setup since it doesn't require my phone or other device to be connected to the internet. Also, "bootstrapping" would be problematic since I have 2 or 3 devices that I keep my codes on. I switch between them often and I don't always carry the same device with me all the time.
trotsky 13y ago
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.
- thirsteh 13y ago
  It's by far the most accessible two-factor authentication method, and not as insecure you're making it out to be.
  - trotsky 13y ago
    What percentage of those android phones would you say are upgraded to a level where they don't have any publicly announced cve's against them that allow for rce or close enough? Like 5 or 10 percent? I agree that it's better than a single secret, but how does a soft toekn count as "something you have" if it can be stolen from your phone and not end up "missing"? My google auth secret continued to work without a hiccup after apple repaired and wiped my phone and i restored from their cloud backup service. That's not too bad for keeping my voice mail private, but it's a pretty weak protection for sudoers on boxes that are pretty much critical to your company existing.
daned 13y ago
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.
_kst_ 13y ago
"if your company uses SSH, chances are you have one Unix Login that all your admins/employees share" Is that really common? I've never seen it.
- deleted 13y ago
  [deleted]
- mercurial 13y ago
  Unfortunately not that uncommon.
- danielpal 13y ago
  We released Authy-SSH last september and this was by far the biggest feature request. You will be shockingly surprised if you knew the names of the companies that not only share unix accounts (which is very common) but were actually sharing Two-Factor Authentication keys.
- Joeboy 13y ago
  Probably more common is that everybody gets their own login, but also gets sudo privileges so everybody ends up working as root.
sehrope 13y ago
> 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. 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. [2]: http://www.jackdb.com/home.html http://www.jackdb.com/home.html
- amrali 13y ago
  I think the core issue behind this is the complexity of managing SSH keys across your infrastructure. Have a look at https://bastio.com https://bastio.com 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!
  - 13y ago
quanticle 13y ago
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?
- emingo 13y ago
  Seriously. I almost stopped reading after this bit... '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...?
  - antitrust 13y ago
    Oftentimes, the decisions admins make are determined by the needs of management of fellow employees. 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.
  - badman_ting 13y ago
    Right, even in the worst shops I've worked in I never saw that. It's madness.
  - w0rd-driven 13y ago
    A lovely anecdote: When I worked for Bellsouth.net, the ISP, our router credentials started with a shared admin/(password) pair. The change happened, according to speculation, because of a breach that couldn't be tracked back to a specific user. 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...
tel 13y ago
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?
threepipeproblm 13y ago
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?
- dragonwriter 13y ago
  > isn't "being able to proof where something comes from or who did what" just repudiation? 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.
  - threepipeproblm 13y ago
    ah

33 points by Vaismania 13y ago

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.

thirsteh 13y ago
Yes it does. The QR code just contains the TOTP key and title. Send it to the email account that will be protected by two-factor authentication using the key, and it won't really matter.
- chimeracoder 13y ago
  > 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.
  - thirsteh 13y ago
    >> 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. 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.
sp332 13y ago
I like the setup since it doesn't require my phone or other device to be connected to the internet. Also, "bootstrapping" would be problematic since I have 2 or 3 devices that I keep my codes on. I switch between them often and I don't always carry the same device with me all the time.

trotsky 13y ago

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.

thirsteh 13y ago
It's by far the most accessible two-factor authentication method, and not as insecure you're making it out to be.
- trotsky 13y ago
  What percentage of those android phones would you say are upgraded to a level where they don't have any publicly announced cve's against them that allow for rce or close enough? Like 5 or 10 percent? I agree that it's better than a single secret, but how does a soft toekn count as "something you have" if it can be stolen from your phone and not end up "missing"? My google auth secret continued to work without a hiccup after apple repaired and wiped my phone and i restored from their cloud backup service. That's not too bad for keeping my voice mail private, but it's a pretty weak protection for sudoers on boxes that are pretty much critical to your company existing.

daned 13y ago

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.

_kst_ 13y ago

"if your company uses SSH, chances are you have one Unix Login that all your admins/employees share" Is that really common? I've never seen it.

deleted 13y ago
[deleted]
mercurial 13y ago
Unfortunately not that uncommon.
danielpal 13y ago
We released Authy-SSH last september and this was by far the biggest feature request. You will be shockingly surprised if you knew the names of the companies that not only share unix accounts (which is very common) but were actually sharing Two-Factor Authentication keys.
Joeboy 13y ago
Probably more common is that everybody gets their own login, but also gets sudo privileges so everybody ends up working as root.

sehrope 13y ago

> 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. 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. [2]: http://www.jackdb.com/home.html http://www.jackdb.com/home.html

amrali 13y ago
I think the core issue behind this is the complexity of managing SSH keys across your infrastructure. Have a look at https://bastio.com https://bastio.com 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!
- 13y ago

quanticle 13y ago

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?

emingo 13y ago
Seriously. I almost stopped reading after this bit... '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...?
- antitrust 13y ago
  Oftentimes, the decisions admins make are determined by the needs of management of fellow employees. 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.
- badman_ting 13y ago
  Right, even in the worst shops I've worked in I never saw that. It's madness.
- w0rd-driven 13y ago
  A lovely anecdote: When I worked for Bellsouth.net, the ISP, our router credentials started with a shared admin/(password) pair. The change happened, according to speculation, because of a breach that couldn't be tracked back to a specific user. 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...

tel 13y ago

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?

threepipeproblm 13y ago

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?

dragonwriter 13y ago
> isn't "being able to proof where something comes from or who did what" just repudiation? 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.
- threepipeproblm 13y ago
  ah