One of the easiest ways ivision consultants escalate privilege is reusing a password from a low-privilege account to authenticate to a high-privilege account. It doesn’t happen all that often, but when it does, it’s a quick compromise.

When developing or managing applications, it is standard practice to have different kinds of accounts: admin accounts, user accounts, testing accounts, and maybe some others. The general assumption is: admin accounts should be carefully guarded, regular user accounts should be guarded and secure, and testing accounts can be shared or documented publicly—after all, they don’t give any access in production, right? That thought process can cause problems when there is password reuse.

Something we have seen on pentests is a testing account having the password testP@$$w0rd!1234 and the admin account having the password adminP@$$w0rd!1234. An attacker can look at the test user’s password and easily guess the admin password.

Less often but more concerningly, we see applications with the same password for both testing and admin accounts. These usually occur when an application has reused passwords during development and those are carried through to staging or production without being changed.

This is a very simple process mistake that can bypass a lot of security investment. Does you company have a strict policy about ensuring testing passwords and patterns are never used for anything else? What about setting unique admin passwords? It can’t hurt to double-check the passwords in your application.