On 9 jul 2008, at 19:40, AMuse wrote:

> Leif: I'm not sure I understand the problem you are facing clearly.
>
> What is the security problem in keeping your customers' login
> passwords available to employees?


The security problem lies in trusting the employee after he quits his
job. At that point he might save all the customers' passwords and use
them for personal gains without our authorization. Currently this is
only a hypothetical threat, but still a risk that must be considered.
The remedy to this would be exchanging every password that the
employee has ever had access to, but this would require an increasing
amount of effort as our customer base grows.

> For that matter, why would you want people to have access to each
> others' passwords?


This is not about people's personal passwords, but the password that a
customer provides us with so we can get our job done on their server.
As a rule of thumb we have very little control over the customers'
servers, and in the case of shared hosting we might even be using the
one and only user account that the customer has access to, so
exchanging the password there would also cause additional effort for
the customer.

> That is usually a security risk in itself, and makes incident
> response and forensics a lot more difficult.


This exactly what we have realized, but due to the nature of our
business we need shell or sftp access all the time. Classical
solutions, such as distributing public keys using LDAP or centralized
authentication using Kerberos are not feasible as they would require
modifications that we're not entitled (or even authorized) to do to
the customers' servers.

With the default authentication options of SSH (none, password,
keyboard-interactive and public key) only public keys seem to enable
keeping the secret out of the hands of employees.
That's why we're looking for a solution that would only require adding
a row to the authorized_keys file on each new server we need access to
and a private key that should never leave our trusted server but only
be used for calculating responses to the authentication requests.


/Leif Åstrand

>
>
> Leif Åstrand wrote:
>> Dear Experts,
>>
>> I'm working at a consulting agency facing the security problem in
>> keeping our customers' login passwords available to employees. This
>> basically means that when someone quits we would have to replace
>> all the passwords that he has had access to.
>>
>> The first step towards a better solution would be using public key
>> authentication, but if the private keys where available to the
>> employees we would still be facing the same problems.
>>
>> The next step would be keeping the private keys stored out of reach
>> from the employees, who would only forward the authentication
>> challenges to the entity managing the private keys, i.e. the same
>> concept as normal agent forwarding but in reverse.
>>
>> We've constructed a simple proof of concept consisting of three
>> parts:
>> 1) A "key server" where a ssh agent is loaded with private keys.
>> 2) A wrapper on the key server listening to a tcp port and
>> forwarding all connections to the unix socket used by the ssh agent
>> there.
>> 3) A "fake" ssh agent for the clients, which opens a unix socket
>> and forwards all connections through a ssh tunnel to the tcp port
>> on the key server.
>>
>> By pointing SSH_AUTH_SOCK to the socket of the fake agent one can
>> then use the private key on the key server for authentication when
>> connecting to a host with a matching public key. Limitations with
>> this simple solution include that they leave tcp ports open that
>> anyone with access to clients or the server might use and that the
>> key server has no functionality for providing varying levels of
>> access depending on where the employee is allowed to log in.
>>
>>
>> At that point we realized that we do not have the resources to
>> develop an industrial strength solution, that we are probably not
>> the only company facing these problems and that there might already
>> exist a system, or at least bits and pieces, that might solve our
>> problem. We've been looking for a solution out there, but all the
>> search phrases we can come up with only give us even more
>> descriptions on how normal agent forwarding works...
>>
>>
>> Is anyone of you aware of a system that we might use, or even
>> existing pieces that would fit into the pattern?
>>
>>
>> /Leif Åstrand

>