Your primary systems aren’t the only source of damaging exposed credentials. Third-party applications employed by your organization also have privileged logins that must be protected. Cloud platforms, software as a service (SaaS), and local third party applications such as ERP systems often have administrative logins with full control. These accounts allow the people in charge of your applications to perform management tasks, and should be kept private to as few individuals as possible, with strong password policies enforced.
How Third-Party Credentials Can Be Leaked
UpGuard has come across application credentials in several forms during research, but there are two common ways in which they are exposed. First, although it goes against all best practices and even basic security, organizations sometimes have documents that just list all of their applications along with credentials in a simple text document or spreadsheet. Without encryption, these documents are like a goldmine for attackers. It seems obvious, but these documents should never be created in the first place. There are many secure methods for storing passwords, and any of them are better than a notepad document named passwords.txt. It doesn’t take a data breach of a major application company to expose your data— your own credentials being exposed is far more likely, and results in the same consequences.
Secondly, we commonly find plain text application credentials in code that has been customized for organizations. Again, though deviating from best practices, which encrypt and/or store the credentials elsewhere, these are often left readable inside the code itself. This is common for integration purposes or automation, where multiple systems have to interact and require access to each other. The principle of least privilege suggests that these integrations should use custom accounts with only the access they need to perform their work. Administrative application credentials should not be used for this purpose and are a shortcut that could fully jeopardize the application and its data, should those credentials be exposed.
How To Securely Manage Third-Party Credentials
Most people working in technology have encountered the elementary mistakes described above, from CTOs/CISOs to support teams to dev teams.
You should consider the risks associated with third-party credentials both from your side, and the vendor side.
Your team: Lock down your third-party credentials
Avoiding using 'password.txt' seems laughably obvious, until you sit with UpGuard's BreachSight research team and stop laughing when you quickly realize that plain-text administrative credentials are easily discoverable in thousands of exposed internet-facing services. Keep administrative credentials safely locked away, and only accessible to administrators. Use lower-privileged credentials for application-level access.
Your vendors: Audit your third-party vendors with security questionnaires
Most organizations can get their head around locking down their third-party credentials. But what's often neglected is the importance of auditing your third-party vendors using security questionnaires (full disclosure - we help automate that!).
Why? Here's an example. A key control to prevent malicious use of third-party credentials is 2FA (Two Factor Authentication), so that even if the credentials are compromised, another layer of security exists between an attacker and their target. However, there's no point having a password security checklist that specifies 2FA on administrative credentials if half your vendor applications don't even support 2FA in the first place. If you're serious about assessing, monitoring and reducing your third-party vendor risk, you need to understand their security posture fully and hold them accountable to your standards.
This article is part of a series. Read more articles in the series at Vendor Risk: The Impact Of Data Leaks From Your Third-Party Vendors.
Learn more about solutions that help you with third-party risk management.