

Non-repudiation and the joy of knowing you've been hacked - Vaismania
http://blog.authy.com/repudiation

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

------
sehrope
> 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
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!

~~~
sehrope
Thanks. I've previously worked in technology in the financial services
industry so a lot of the ideas for auditing/compliance come from meeting the
expectations of that market. Our logic is that if it's seamless enough for
them to use it and satisfies their compliance requirements, it should be good
for most other industries as well.

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.

~~~
amrali
I couldn't agree more; client certs are too much work and come at a non-
trivial maintenance cost, same goes for AD/LDAP. So JackDB also acts as
authentication provisioning front-end for a DBMS so users don't have to do
that themselves and suffer the maintenance cost/overhead. Interesting.

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?

~~~
sehrope
> So JackDB also acts as authentication provisioning front-end for a DBMS so
> users don't have to do that themselves and suffer the maintenance
> cost/overhead.

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.

------
trotsky
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
It's by far the most accessible two-factor authentication method, and not as
insecure you're making it out to be.

~~~
trotsky
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
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_
"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.

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

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

------
threepipeproblm
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
> 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
ah

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

