Written by: John Hancock
What is the Issue?
Applications and systems in various ways, some of which are more secure than others. The simplest of approaches is to store these in plaintext within a file or the registry. This is, for hopefully obvious reasons, not a good idea. An attacker could simply read the file from disk and access all your information.
Another approach, which at least on the surface seems secure, is to encrypt passwords with a known, static key. You still end up with a random string to be stored away, right? Unfortunately, this all breaks down the second anyone gets ahold of the application and extracts this key, which does happen and often easily. It becomes the same as storing it in plaintext.
What Can I Do About It?
If you’re building or commissioning your own application, you can completely avoid this. Require the use of a one-way hashing algorithm, like bcrypt for example, to store passwords without fear of them being reversed by a clever attacker. They might still be able to steal the hashes, but it’s a long road ahead to crack them using a brute force attack.
But what if you’re using someone else’s application that you have no control over? You might be able to research what password storage method they use to verify it’s secure, or grab the hash database and use a hash identifier tool (such as hash-identifier which is included with Kali Linux). You might not have the technical know-how or the level of access (like with web-based tools) to be able to check. What then? Some alternative ways to mitigate bad password storage, depending on the type of application, might include ensuring you use strong, unique passwords across different accounts (with the assistance of a password manager) or limiting access to the application behind firewalls or other access control mechanisms.
Examples in the Wild
Within a Windows domain, Group Policy Preferences allowed users, in a now deprecated feature, to store passwords within polices. However, they were stored using an AES key that has been made public. Attackers with access to the domain could retrieve these credentials within Group Policy Preferences which are stored in SYSVOL on a domain controller which is accessible by any domain user. Then they could easily recover the plaintext password for a quick way to elevate their access on the network.
TrackIt, a commonly used IT Help Desk software, stores passwords with a set encryption key. By gaining access to the network share it is stored on or directly accessing its database, these passwords are easily reversed, and an attacker could gain full access to the ticketing system. These are two examples, but this is an issue to be on the lookout for across your environment. The data is only as secure as the encryption mechanism.
If you’re looking for someone to determine whether your data is secure, DenSecure is here to help. We find vulnerabilities and suggest countermeasures to help keep your credentials secure – reach out today.
