• A web application
  • Some active administrator accounts.
  • Some inactive administrator accounts.
  • No existing "audit" mechanism to keep old accounts for.
  • Inactive administrators cannot log in.

Is it more beneficial or less to periodically delete inactive administrator accounts? Are there any experiences for or against that argue for one side?


I'll argue to delete them. The only thing that prevents these accounts from being used is:

Inactive administrators cannot log in.

And that is a defense against brute forcing (or fooling) an authentication, yet it does not defend against privilege escalation.

OWASP guidelines for web applications argue that a client should never hold a session with authentication for two separate accounts. That would prevent privilege escalation in most cases. Yet, by far, not all web applications follow OWASP guidelines.

Therefore, keeping those inactive but still privileged accounts is a possibility of an attack vector.

The other side of the coin is that the procedure for deleting the accounts may consume resources or, even, be insecure in itself. But managing to produce an account deleting procedure that is vulnerable to an attack is much less probable than being hit by a privilege escalation.

Just don't make the periodic account deletion procedure to delete the inactive accounts by first logging into an active administrator account over the network.

  • This is an awesome point that I simply didn't consider, pretty much convinced me outright. – Kzqai Nov 23 '16 at 0:16

The moment I come across a question like this, I am always compelled to say "Yes, please delete the inactive accounts". Why? Because it is "good practice" to remove old accounts that are no longer in use. Some use cases that are borderline applicable to this scenario:

  • Username reuse: If the usernames are "gclooney" rather than "admin22", you have lesser collisions when creating usernames if a new admin resolves to the same username/handle
  • Resource wastage: I agree we are no longer running an application on a Raspberry Pi. But still, it is memory waste and also an additional check. Not only do you now check for whether the username is correct, you would also need an additional check for their validity.
  • Unnecessary enumeration: Supposing a data leak/SQL injection leads to leakage of (admin) user info, you now run the risk of leaking more information than needed, if say, you also have ex-admin's first and last names stored in a related DB record.
  • grochmal's point on OWASP guidelines.

Always err on the safer side and assume the bad guy can turn the weirdest of things to their advantage!

  • I don't totally agree, it really depends on the application is designed. Imagine separate storage of "permissions" and users (like object ACLs). If you delete a user and a new one is created with the same identifier, you will grant the new user with the old one permissions. IMO, I would keep it but erase sensitive data (like password hashes). – r00t Nov 22 '16 at 21:59
  • "If you delete a user and a new one is created with the same identifier, you will grant the new user with the old one permissions" - but isn't that a question of user provisioning? Are you saying when a user is removed, there is a "dangling pointer" of sorts to the now-removed userid? – katrix Nov 22 '16 at 22:06
  • And absolutely, all of this depends on how the application is designed for sure. But this is more a broad-spectrum approach to an application whose details we don't know much about. – katrix Nov 22 '16 at 22:07
  • yes absolutly, I was thinking about a reference, like two SQL tables with a foreign key with a constraint. "this is more a broad-spectrum approach to an application whose details we don't know much about" - IMO, we cannot do security without looking at the details. Making generic recomendations could lead readers to mistakes. – r00t Nov 22 '16 at 22:13
  • "data leak leads to enumeration of admin accounts" -- now you effectively have honeypot accounts which will stand out in audit logs – Ben Voigt Nov 22 '16 at 22:13

Is it more beneficial or less

The question is, "What reasons could there be to NOT delete them?" What could be less beneficial about it? There are far more reasons, (as the other posters have mentioned), to delete them, then to not.

Deleting: < 30 minutes

!deleting: > many days of disaster recovery


In response to Kzqai

If your database is setup correctly, you should have your users in their own table. So their history I would hope is part of a different table. And if not, I suggest you re-assess your database configuration. Furthermore, If you follow good practices, you should have backups of your database that you could reference in the event of looking back at old/deleted users. But realistically, if the database is configured well, you could delete a user, with no impacting affects on anything else tied to that user.

  • Really the main con of deleting that I'm aware of (and certainly, I was leaning towards deleting from the start) is that deleting admin accounts also involves deleting any information trail. Who were past admins? What did they do? How can I contact them? What parts of the system were linked to those accounts? Etc etc. – Kzqai Nov 23 '16 at 0:19
  • @Kzqai See my edit, I felt this response needed to be more substantial. – TheValyreanGroup Nov 23 '16 at 1:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.