Live data from Hacker News

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

blog.authy.com

21–30 of 30 posts

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

#21
post #5
post #3

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.

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.

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

#22

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?

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

#23
post #2

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.

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.

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

#24
post #22

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?

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...?

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.

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

#27

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?

> 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

#28

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?

> 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.

ah

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

#29
post #22

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?

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...?

Right, even in the worst shops I've worked in I never saw that. It's madness.

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

#30
post #22

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?

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...?

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...

Post reply on HN