Reversible password storage

Storing a password with reversible encryption (or a simple table encoding) is, in practice, storing it in cleartext: whoever reads the file and knows (or deduces) the algorithm recovers the password. Unlike a slow, salted hash, there is nothing to "crack", only the operation to undo.

The pattern and how to reverse it

The typical case is an application that encrypts its own admin password in an .ini/.conf with a hand-rolled scheme. For example, Argus Surveillance DVR maps each character to a fixed hex block; its DVRParams.ini stores Password0=ECB453D1... and inverting the table is enough:

ECB4->1  53D1->4  6069->W  F641->a  E03B->t  ...   ->  14WatchD0g...

A public exploit usually ships the table; if a block is missing, the rest of the already-known password lets you complete it with a minimal brute force of the last character (for example against SMB). The same principle appears in many well-known formats, for which a decoder already exists:

# Cisco Type 7 (router/switch config)
echo '<type7>' | ciscot7 -d          # or https://github.com/theevilbit/ciscot7
# GPP cPassword (AD SYSVOL, AES key published by Microsoft)
gpp-decrypt <cpassword>
# VNC stores the password XORed with a fixed key in the registry/file
# home-made "encryption" that is really base64
echo '<blob>' | base64 -d

It is a credential source as valid as secrets in source, and the recovered password is often reused on other services (credential reuse).

Requirements

Read access to the file/registry where the application stores its secret and identifying the encoding algorithm (usually from the product name). No dictionary or GPU is needed: the reversal is deterministic and instant.

Nuance. Do not confuse it with cracking a hash: here there is no dictionary or brute force against a one-way function, but an invertible transformation. That the value "looks like" a hash (long, hex) does not mean it is one; it is worth identifying the algorithm (product name + "password encryption") before assuming a crack is needed. In AD, enabling the "Store password using reversible encryption" attribute on an account or GPO has the same effect: the password comes out in cleartext with a DCSync.

How to detect it. The reversal happens offline on the attacker machine and leaves no trace of its own, so detection sits at the sides: the read of the config file holding the secret (a 4663/4688 over the .ini/.conf, or SYSVOL access in the GPP case) and, above all, the reuse of the recovered credential (a valid login of that account from an unusual host or time). In AD, a query that enables ENCRYPTED_TEXT_PWD_ALLOWED or a selective DCSync are the signature of abusing the reversible attribute.

Defence. Never "encrypt" passwords with reversible or home-made schemes. If the system must authenticate against an external service and needs the secret in cleartext, protect it with the OS credential store and strict permissions; to verify your own passwords, use slow salted hashes (bcrypt, Argon2). In AD, never enable "reversible encryption". It is a sibling of cPassword in GPP.