13

I'm an European software developer and I am changing company. To do my job, during the years I have received (from my boss and colleagues) a lot of non-personal shared secrets, like:

  • root accounts passwords (eg. AWS, Google Cloud, Azure, ...)
  • access to servers (passwords and/or SSH keys)
  • company-wise online accounts credentials (eg. GitHub, elearning platforms, ...)
  • API keys

Clearly, anyone with this kind of information would be able to do nasty things, like accessing customer's data, or even deleting S3 buckets. That's needless to say that something like that would be huge for a small company.

To be clear: I want to leave my current employer on good terms. Despite my contract did not require me for a quit notice period, I proposed to stay one month after my announcement to prepare the team (document things, help hiring someone else, etc.). I even said to my boss and colleagues that they will be free to text me after my leave if they will need my help.

My boss initially was quite "fine" with my resignation; however during the last few days he started to act in a weird way to me (cold greetings, "forgetting" to CC me in some emails, ...). Maybe those things are just in my head, however I would like to protect me against any kind of future issues. What if one day a colleague of mine accidentally destroyed a database? To protect himself, would he blame me because I had the passwords?

Those access details are either stored on my company email (that I would lose access after quitting), on my computer (the policy is "bring your own laptop") or my Google account (I use "save password" in Chrome). Those are not best practices, but everyone else does the same. I will clearly clean my computer/accounts after quitting, but there will be no evidence that I did not print or memorize such secrets.

As a final note of mess, they will not be able to rotate keys/passwords in the short term (e.g. the day next my quit). Some passwords have never been changed since the accounts were created, even after other employees left.

What would you do?

5
  • 1
    Are these passwords that everyone shares? Or are they passwords particular to your ID? That is to say are you a) all sharing account "admin" and everyone knows the password to it........... or b) do you have your own account "throwaway_admin" and your own password that nobody else knows? If the account "throwaway_admin" was deleted at 5:00 on quitting time, would that suffice? Oct 4, 2019 at 1:18
  • A good point in your defense, if necessary, is that the previous leavers still also have access as the passwords have never been changed...
    – Solar Mike
    Oct 4, 2019 at 4:27
  • 1
    @Harper I have tons of "admin" accounts (eg. AWS account root access, servers root SSH keys, API keys) and a few of "my name" accounts (eg. AWS IAM account). My issue is about the first kind of secrets, it would be easy to delete/deactivate individual accounts on my last day in front of my boss. Thank you!
    – throwaway
    Oct 4, 2019 at 7:55
  • @SolarMike you are right, moreover in my country this kind of criminal offence is personal, so in a court they must prove that an hypothetical S3 bucket was deleted by me. I do not want go to the point to prove that I am not a dickhead!
    – throwaway
    Oct 4, 2019 at 7:59
  • in regards to "accidentally destroyed a database" or any similar issues: If your dba or inhouse IT-guy is worth his money, all client-connections and operations including details of who, where & when would be stored in a log anyway so it would be hard to blame you, unless you manage to bypass their firewalls and remotly compromise and capture their system and wipe even the logs of the routers and firewalls clean ;)
    – iLuvLogix
    Oct 7, 2019 at 14:36

10 Answers 10

38

What would you do?

I would make a list of all these logins and offer to help the person who was tasked with changing all of them. As each password change was completed (by the other person, using passwords unknown to me), I would cross it off the list.

During my final month, I would send the updated list with each of my weekly status reports, and then the final list on my last day.

If any remained unchanged, I would rest easy, knowing that I gave them a month along with everything they needed to get the job done.

7
  • 3
    This is a reasonable answer but it fails to sufficiently protect the departing employee. Throwaway's fear is not that the company will encounter some security breach damage after he leaves, but that they will encounter some security breach damage and blame it on him. Throwaway wants to demonstrate that he no longer has access to the company's protected assets. Oct 4, 2019 at 3:46
  • 5
    @A.I.Breveleri: The company chose to give out shared credentials to its employees instead of using specific user accounts which can be disabled individually. That's on them, not on OP. If OP simply alerts the company well in advance of their departure date that the passwords on these credentials (listed by OP) need to be changed; that suffices to cover OP. If the passwords have not been changed, the company is liable for the consequences of not changing those passwords. Joe's answer already contains more diligence than is (minimally) required to cover OP's behind, it's not insufficient.
    – Flater
    Oct 4, 2019 at 9:12
  • Let them be signed off as the passwords are changed away from the original. Oct 4, 2019 at 12:34
  • 1
    This almost goes too far in some ways, and yet not far enough, IMO. I would provide a document with the list, state that "<employee> will perform best-effort work of cleansing password managers of the aforementioned credentials and that <employer> will not hold <employee> liable for subsequent leakage or usage of the aforementioned credentials" ... have a lawyer review it, and have <employee> and <employer> both sign it. (IN BLOOOOD) ... leave it up to the employer at that point as to whether the credentials pose a risk as-is, but cover yer arse.
    – svidgen
    Oct 4, 2019 at 16:55
  • 5
    This is a reasonable answer. It is not the OPs responsibility to deal with IT security when leaving the company. A good IT department should know EXACTLY who has what access and to make the appropriate changes when someone leaves. Making a list should not be necessary, but shows good faith.
    – Keltari
    Oct 6, 2019 at 0:23
9

You are indeed vulnerable to that kind of accusation. However, this is partly a mess of your own making, because you have not used good security practices so far. You know that, and I won't belabor it.

Generally there are three types of security model for a service-oriented web site.

  • One login (account/password) for the corporate account. All the users at the company are expected to share the password, and any one of them can cause mayhem. MailChimp is like this, for instance.
  • A master account/password for the corporate account. It's possible to just share that password, but they also provide the ability to create individual sub-accounts - a login/password for each employee. Every activity is journaled to its sub-account PayPal works like this: my logins for ABC Company are ABCCo-Harper and ABCCo-HarperAdmin. (The first is only priv'd for point-of-sale).
  • The site allows real-human accounts only, then associates companies with the humans. Examples are a Facebook business "Page", where any number of humans are admins, contributors or advertisers.

Servers on your own premises surely accept the "sub-account" model; stop sharing root and set up admin accounts with sudo.

Untangling this twisted web

It's too late to do the most important thing: swerve way out of your way to select providers with robust password architectures. When setting up our business systems, I was very selective about this; however still, half our accounts are the shared-password kind because so few vendors support sub/real accounts.

On "real-human accounts only" sites, the site has already forced you into a competent security model. Right now: make sure the correct humans at your company have an account, and promote them appropriately; at least one must be the highest rank. On your last day: tell the system to dissociate your account with the company's asset. Easy peasy.

On sites capable of individual sub-accounts, right now: set up sub-accounts for the correct humans at your company including yourself, issue them passwords, and forget the passwords you issued them. Make sure appropriate staff have the master password, and ask them to change it immediately. On your last day: Walk away and don't log back into your sub-account. They should delete it, but if they don't, who cares? The system's journaling will prove you did nothing.

On all other sites, first: make sure the relevant people have the correct passwords.

You have a variety of passwords which have not changed for far too long. Change them. That also applies to any password that you have stored in a way you know is stupid. Presume it to be compromised and change it NOW and give them the new password. You need to do this now, while there is still a month of recovery time. Doing this in your last week is much too late.

And clean up behind yourself; once you have reset them, delete all the passwords from places they should not be, like emails (!), Google docs, and the like. Not sure how I feel about password managers; they're far from the worst and not far from the least bad way to deal with it.

And don't make any new messes; if someone asks for a password, don't email/tweet/Facebook messenger it. Stop doing that. Write it down on paper, seal it in an envelope and hand it to them. Physical security is their problem. Or call them on the phone and read it to them.

Distributing new passwords

I am dealing with technophobe pointy-hairs, so I do passwords on paper. I make an MS-Word document listing every account, and A B C D E F G where the passwords would go. That can be distributed electronically. Then I have another sheet which says simply A B C D E F G with a space for a password for each one, and that I hand deliver. For pointy-haired managers who are unlikely to use them, I put the master passwords in an envelope saying "Master Passwords! Do not open except in emergency".

As far as generating passwords, I finally ran out of AOL disks :) So I use a scrap of perl and /usr/lib/dict/words to generate a CorrectHorseBatteryStaple-type password tuned to work on most sites and be mobile-friendly (i.e you're not typing shifts more than characters).

Getting them to reset behind you

When distributing new passwords to them, send a separate email professionally advising them that you have changed passwords, the list of accounts you have changed passwords for, and state that you provided the password list on paper (or however). CC this to your personal, offsite email address, and BCC it to your lawyer. It goes without saying this email should NOT contain any passwords.

Then, on quit, send them another email the same way reminding them that you are leaving the compay as of date/time and please change the shared passwords behind you. Again, CC to your personal and BCC to your lawyer.

Really, at this point, you've done all you can do. If they have problems, you and your lawyer wave those documents around in court, showing it was their responsbility to change the passwords behind you, and you told them that. (Of course you also deny doing anything; but by showing their negligence, you undercut any claim of damages.)

Hopefully, if you do as I say, you have "warmed them up" to the idea of changing their passwords from time to time. They, too, know they need to do it; you just did the heavy lifting for them.

Now, enroll an ally at the company at resetting the passwords behind you.

DO NOT under any circumstance log into an account "to see if they changed the password". No matter how curious you are! You shouldn't even possess any more passwords; you should have deleted them from wherever you keep passwords. Be thorough. Certainly if there is litigation, they will subpoena your laptop, and a list of accounts from 1password, etc.. If they show you kept passwords, that will undercut your defense that it wasn't you.

3
  • 1
    Thank you for the time spent writing such a good answer. I think it will work for most people in my position. I am still in trouble because I have only 1 week left and changing some password/key would be a real PITA (for bad practices established before my arrival, eg. an API key may be shared among several services, no one remembers which, let's change it and see what breaks). My other fear is: if I ask them to change everything I know, will they suspect (since no one has a clear list of all company credentials!) that I am planning to do something nasty with the forgotten (unchanged) secrets?
    – throwaway
    Oct 4, 2019 at 7:51
  • 3
    I really doubt they would infer any ill intent. They would see it as a CYA move, which is exactly what it is!, and probably ignore you. You just need to do your part of password handover as responsibly as possible, and leave a paper trail that you did, So you have that paper trail to wave around in court if thee's a dispute. Or alternately, you quit, they go whatevs, *someone else gets fired and they go 'holy smoke, that guy will wipe us out, where are all those notes throwaway gave us?' Oct 4, 2019 at 15:13
  • @throwaway also, security is always inconvenient. Nature of the beast. Preparing poorly makes it lot more inconvenient, which is the problem they face today. Oct 4, 2019 at 15:34
3

As an IT manager with over 2 decades in the field, I can tell you there is nothing you need to do. Proper IT security means that the department should have records of which users or applications have access to which resources. When someone leaves, or there is an audit, or just changing passwords/keys/etc on a schedule, these records should be referenced and updated. Unfortunately, not every IT department does this, which leaves them unknowingly vulnerable.

While not necessary, making a list of everything you have access to, shows your company good faith. It might not be a bad idea to tell them to invest in a proper password control system.

2

Firstly, I would identify the people/person taking over your role. If you can't find that person, make it your manager.

Open a LastPass Corporate account (other secure login , charged directly to the company. Invite yourself and your replacement person to the account. Add all the login details that you have secured (insecurely) in your email.

Any logins that are tied directly to you - change them so that they use corporate details. E.g instead of registering as '[email protected]', use '[email protected]' - that can then lead to a distribution list.

As you add identities to lastPass, remove them from any system that you will be able to access after you leave. Also disable any personal login details (e.g your AWS user accounts - DON'T delete the root user accounts :) ) once you know you won't need them any more.

Keep a record in Excel of all changes made (e.g 'AWS Account 123456 - password changed for Fred Bloggs' - don't put any secret information in there). Give that record to your manager when you leave, disassociate your personal account from LastPass (if it was connected to the corporate account), and send an email to your manager strongly suggesting that they change the LastPass master password and all the accounts within.

As someone else said previously; don't try to log into any accounts 'to see if the password was changed'. You don't want any audit record of your accesses showing up after you've left.

1
  • I'd favor an on-site solution like KeePass2, instead of giving the passwords to a third-party service like LastPass.
    – tmh
    Oct 4, 2019 at 17:40
1

When you're in this sort of critical position, the professional thing to do is compose a handover document/manual for whoever succeeds you to the role.

This would include any knowledge specific to the role, step by step procedures for anything important or job specific, and a section including usernames and passwords.

This serves as a reference for the next person and becomes part of the companies resources. I have seen handover documents I made over a decade ago still in use several people later, with them just updating or adding to it through the years. A good handover document is a valuable training and reference asset.

Take your time and do it properly. I do them complete with screenshots, diagrams and procedures broken down to their basics as if the readers are beginners.

1

What would you do? Thank you in advance!

Do nothing. If you still have the capability to log into any account after your last day, don't do it! Yes, the company can suffer some sort of security breach and you can be accused but as long as you stop logging into those accounts there will be no evidence of wrongdoing on your part.

If you left on good terms they should not even consider you as a suspect if any security breach happens. I have left companies with such privileged information and had the self control to not attempt to use it. Do the same and you should have nothing to worry about.

1

Let's clarify a few things before making a recommendation:

When you leave you are expected to no longer access your company network typically via employee handbook, a NDA, etc... some sort of agreement, if that is not in place a. your employer's dumb b. you should still no longer access the network cause of ethics.

So as far as you go, once your gone stop worrying about it, you own none of it including your account & work email.

Now, if you want to be nice... create a document or better yet a keepass file and share it. You can check keepass into source.

0

It's probably too late for this, but if you can or in the future, leverage a technology such as Active Directory/LDAP with a centralized key store. Your company's setup is spaghetti.

Right now, your best bet is to pass everything on to someone else. If possible, they should update all of the passwords, keys, and secrets, and put them in a key store behind security.

With such technologies, you'd have a centralized set of users, roles, groups, and permissions. With the right ecosystem, such as Active Directory with Azure Key Vault, all of the secrets can be centralized and be hidden behind a policy that defines the right permission set.

Also, for example, you can use Active Directory for pretty much everything. The e-mail, the Azure environment, server logins, etc. Everything is a domain account, and everything is always hidden by one thing: Your domain login. This is elegant.

When an employee departs from the workplace, their account is simply disabled, and thus their access to every key and secret is also disabled. Their access to every server, source control, or cloud environment is disabled. It's very clean. It just takes proper business architecture. Some migration tools may exist but moving all of the keys would be kind of a mess, depending on how you stored them (excel, notepad, napkins, etc.)

0

You don't need to do anything. In the legal system, there is the standard of "innocent until proven guilty". That means if they have a security breach and they blame you for it, they have to prove in court that you were the one who hacked them using your credentials. Which, given their security spaghetti, they will probably be unable to do even if you did hack them, so legally you're probably not liable for anything (IANAL).

Professionally, what you should do is you should tell them "these are the things I know I have access to" (you may have access to other things you don't know/have forgotten) and enumerate as many of them as you can. Then send that email to your boss and/or to the infosec department at your company. After that, there's not much you can do; it's their job to revoke your permissions and make sure you don't have access after you leave. If they choose not to do that, that's on their head, not yours. As for your responsibility, ethically (and also probably legally) you should not use those credentials you have, even if they are still valid, for any reason, after your last day in the office. Which I'm sure was probably your plan anyway and didn't need restating, but that's the long and short of it.

-1

As a final note of mess, they will not be able to rotate keys/passwords in the short term (eg. the day next my quit). Some passwords have never been changed since the accounts were created, even after other employees left.

That's wrong, it doesn't make sense, and you have to urge them to change this policy. It may seem a rude request, but the consequences if someone does damages with those credentials and accuse you may be much worse than the risk to burn bridges with the company.

I would write an email to the boss like:

Dear boss, this mail is to remember that I still have access to the following accounts: . Since I will leave in , I kindly ask you to take actions during this timespan to change the credentials and assign them to other people. Best regards

The last day (or a few days before), I would send another mail clearly stating that if the credentials will not be changed, I will take legal actions to protect myself.

Also, BCC both mails to your lawyer.

4
  • 5
    "I will take legal actions to protect myself." Such as? Sounds like a rather empty threat.
    – FooTheBar
    Oct 4, 2019 at 7:27
  • Well, let the boss decide if they want to take the risk to discover if it's really an empty threat, or they prefer to simply change the passwords. However, if you BCC the above emails to your lawyer, you can at least demonstrate that you asked to be disassociated from the accounts. Oct 4, 2019 at 8:23
  • 2
    I think you probably didn't mean pretend, which is a false friend with some (all?) Romance languages. In English, pretend means act as though something is true when you know it isn't. I think you probably meant "you have to try to get them to change this policy". Oct 4, 2019 at 8:47
  • @PeterTaylor you are right, thanks. I have rephrased it. Oct 4, 2019 at 8:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .