Hacker News Reader

Comment by artie_effim | Hacker News Reader

you don't - you use an directory (LDAP, Active Directory) or AAA service (RADIUS,TACACS+) to manage that. There should never be a shared password. If it is a cloud shared service, same rules apply. You have to know who did what when, and with a shared PW you cannot. Even if all people have the same privileges, you gotta know who did what.

View on HN

In my experience this is what it often boils down to. If access control isn't possible, it immediately and totally rules out using that service. For many companies this is how they have to operate for auditing purposes, and they have to be audited otherwise their clients can't use them, etc.

Although to be honest, out sourcing things like this is often not possible in itself. For internal passwords, everything should be linked to a single-sign-on system of some sort I think.

This is fine for things your organization controls. It isn't possible when dealing with lots of outsourced services. Too few services provide a way to hook into your LDAP or Active Directory.

True, but there still shouldn't be a shared password. Personal accounts for everyone.

For the few truly top-level master accounts around, a printed password in the safe will do fine. It should be painful and feel dangerous to use those, because it is.

This isn't possible for every service. For example, our company Twitter account. Twitter doesn't allow any way for individuals to have their own passwords and post to the account. We have a social media team, all of whom need to be able to post to the Twitter account. There is no way around sharing a password for that (and it's just one example of many). It's great to be idealistic and say don't share passwords, but in the real world, it's not always possible.

A 30 second Google turns up at least two third-party services that lets you delegate access to your Twitter account without sharing the password.

If you have a good internal service for auth/z, you can store passwords for less-critical outside services in plain text files on a network filesystem, with permissions locked down so that only the relevant people can read those files. In terms of security this seems similar in strength to what Passpack does--it lets authorized users see the actual passwords if they want to, or you can build applications on top to read from the file and log in to outside services. I did something like this once for FTP-style logins, and it worked all right.

Apart from that case, you really can integrate Kerberos or similar into your own applications, using e.g. SASL.

Reply on news.ycombinator.com