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 fo…
It's by far the most accessible two-factor authentication method, and not as insecure you're making it out to be.
Non-repudiation and the joy of knowing you've been hacked
21–30 of 30 posts
Re: Non-repudiation and the joy of knowing you've been hacked
#22I 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?
'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...?
Re: Non-repudiation and the joy of knowing you've been hacked
#23Does 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.
Re: Non-repudiation and the joy of knowing you've been hacked
#24I 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?
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...?
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.
Re: Non-repudiation and the joy of knowing you've been hacked
#25Re: Non-repudiation and the joy of knowing you've been hacked
#26Re: Non-repudiation and the joy of knowing you've been hacked
#27Doesn'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?
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.
Re: Non-repudiation and the joy of knowing you've been hacked
#28Doesn'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?
> 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.
Re: Non-repudiation and the joy of knowing you've been hacked
#29I 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?
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...?
Re: Non-repudiation and the joy of knowing you've been hacked
#30I 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?
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...?
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...