Colleagues sharing passwords.That was a big fat NO when I was a sysadmin - and for a good reason. But now, since I'm closer to development, it feels like no one really cares about the passwords. If I tell my colleague I'll take 10 minutes more because I can't log in, he OFFERS me his credentials. And sends them over saying "in case you need it". [the next day the same colleague was complaining his account is locked out. Oh, wonders! How on Earth...!]

But seriously, password sharing is a serious problem. I would fire the person on spot if I caught him sharing his credentials! This is the 8th deadly sin! IDC if they are for non-prod. Most people reuse their passwords in multiple systems, and even non-prod envs can bring the prod down! Or worse - install a trojan.

This is so true. I worked in a big organization and we had like a master account for quite a large part of the servers on the network. This account had been in use for 20 years and been circulating around - it was meant for performance testing purposes but it got shared around and used for all kinds of shit. Password was really weak too, something like six characters. We finally killed it last year like 5 months before i left the company and by the time I left they were still dealing with random shit breaking because they used the credentials that were now no longer existing for all kinds of shit. Death penalty for all that commit this very avoidable security sin. 1) don't have a master account with access to everything like this 2) if you must, at least make sure not everyone has access to it ffs

Why would you fire the employee when it's your own fault that you don't have implemented a system that doesn't make employees doing that?
Giving induvidual blame for a faulty system is short sighted and bad. 🤷🏼‍♂️

wiki - system theory
https://en.wikipedia.org/wiki/...

In the early days before we had a finished MVP, we had a password manager that people could log into with privileged access controls for envs, test accounts, etc. Now that we're a little more mature as a product, we integrate it all through a secrets provider.

In the past, I and others on my team would end up sharing passwords due to a lack of sophistication on the admins and ops teams part. It's never a good practice, but sometimes it's necessary.

@SortOfTested I disagree. It's never necessary, unless there is a severe threat and using someone else's credentials is the only option.

If sysadmins fail to provide accesses - block the progress until you have those accesses ready. This should put on some heat on admins from the mgmt levels, and they will be forced to overcome whatever is stopping them.

I am sorry, but using someone's else credentials is no better than an identity theft or a successful phishing attack imo.

It's not perfect, but a little better if that someone else enters his/her credentials himself/herself rather than just sharing a password. Or shares a jwt [assuming it expires within a day]. That [or anything equivalent] I could justify. But sharing a password -- strictly NEVER.

@netikras
You seem to come from somewhere that has an inverted power balance. Stay there, it's a better place.

Where I am, if you don't deliver, you're at fault. Doesn't matter why, management is too stupid to know right from wrong, so you have to let people eat the consequences of their failed bureaucracy.

@heyheni if an employee has an organisational obstacle preventing him from doing his job, the employee is to address the management first and not to look for hacks in the system, unless instructed otherwise.

If I failed to implement something in the system I should be made aware of that. I am to never be left in the dark by silently overcoming my failure by sharing data that is strictly meant to not be shared.

I'm just a person who's very sensitive about company secrets' sharing.

[truth be told I didn't read the article, idk if I answered your question]

@SortOfTested I come from the sysadmin's chair. I was the person who was responsible for all the accesses and policies. If you are asked "who did the change", you can easily find the person in the logs. But you can NEVER find whether that person was someone else using not his creds. There have been incidents in my experience. Bad incidents. I've seen what damade could such a simple act of carelessness do and I never want to see this happening again.

Like I agree, but there’s just one thing...

The social contract is broken and I don’t give a single fuck anymore.

@netikras That was not @heyheni's point. It's not about who's to blame, it is about designing a system that prevents faulty behavior.

You can identify someone who is sharing their credentials and punish them. Then someone else does this. You punish then too. And so on. But none of this changes these credentials having gotten out. Ultimately the risk you wanted to prevent still occurred.

So you can identify blame and probably be somewhat right about who's fault caused what, but all this is is being the guy who saw a car coming, crossed the street anyway, because the traffic light showed that they could and on their tombstone were the words, "He was right".

Primary objective should preventing employees from creating security risks.

@Maer I see your point (and saw that point in heyheni's comment too).

However, some of the actions cannot be controlled by the system. The traffic light could say RED and the person could still try and cross the street "because he feels lucky today". I could try to enforce 2FAs at every corner in the company, yes. But that is not what I'm trying to achieve. I want to see employees self conscious, responsible and careful. I want employees to understand that any step outside the rules puts the company and everyone in it in danger.

Of course, we could work in a prison-like or kindergarten-like environment! But enforcing things has its own consequences (rigidity, monotony, temptation to work outsmart the system, etc.). But it's unhealthy. And it's "grey".

As for the traffic light reference - I can try to enforce things all I want, but if I happen to have highly motivated idiots in my staff they will find a way to cross the line.

@heyheni in a lot of cases I would agree with you but in this case you are short sighted.
There is no system in place that guards against every case or all stupidity. If this was always possible we would not have a COVID-19 outbreak.
People not being able to use other people's Credentials will require biometrics what might be against the law to force employees to provide that to an information system. Also they will still be able to log in and keep that session alive. Just in case. Sure sharing the account becomes more impractical but do becomes the solution. Also biometrics suck as a security measure.

I agree, but:

- if you have a nonprod environment that can bring down prod, then your environments need sorting, pronto. The two should be entirely independent.
- if you have a situation where people commonly feel the need to share credentials, then that's a bigger underlying issue than someone actually sharing them. Whatever it is - too much red tape, ops guys taking forever to grant requests, users randomly being locked out, etc. - it needs fixing.

@AlmondSauce I agree!

Yepp, these things do need fixing, however, the ops problem will never be sorted if it's never brought to the daylight. And it never will be if people will keep on choosing a more convenient path - sharing secrets that are not meant to be shared.

Well, most systems I've worked with could be impacted [prod] by doing one or other thing in npe. Depends entirely on a setup. Pushing code changes to repo from an npe also count as an ability to impact prod ;) PRs and reviews? The four-eyes principle could be hacked. E.G. How closely do you review PRs saying "revert commit xyz" ? :)

As I got the link, I'd add something here.

When you - as a developer - for what ever reason share your credentials, then you're commiting fraud. Your credentials are your identity.

If management punishes you for not doing that, then I think you should really look for another job.

Main security issue: Uninformed, uneducated person.

As an developer, I'd expect you to understand that your credentials are used to represent your identity. That should be common knowledge.

Trying to prevent things is a wrong choice.

You must teach. I got really tired of doing this and it can take a year or two, but teaching the higher ups and the devs is the only sensible thing to do.

Otherwise you'll still have a Peggy Sue that works eg. in Sales, get's a call from "Peter from Dev Team" and sends eg the companies tax reports to an unverified e-mail address. Social engineering is the most common way to get highly classified information.

And that's a job of a developer too.

It doesn't change if you don't try to trigger change. If they won't do it, you should leave. You're at a constant risk of being framed.

And especially developers need a lot of teaching.

Most people don't like this fact, but it's true.

Security must start person first, then everything else.

You can't make an person secure.

The person needs to know what's secure.

@JustThat yes and no. Most of the time a breach ends in fast fix and don't give a fuck if noone takes a sharp stick, puts some spices on it and repeatedly stabs someone....