I'm writing a plan to audit my password policy, and I was stuck on one of my policy controls which was making sure that No password should be stored in a readable format.

What is the best practice that I should follow to audit this control? knowing that I will be auditing almost 40 components.


While cleartext storage of passwords is a bad thing, some kinds of "reversible obfuscation" (e.g. Base64 encoding, or ROT13 "encryption") are not much better, and should be detected as well.

The right way to audit the password storage and verification method is to look at the specification, i.e. the document that states what algorithm is used, and with what parameters. If that document exists, just read it. If that document does not exist, assume the worst; from an audit point of view, unspecified behaviour is as bad as weak behaviour.

Looking at the database is akin to reverse engineering: while it tends to work (you can indeed learn a lot of things through reverse engineering), it also indicates that the product designers are not collaborating with the auditors, and that will make the audit meaningless.

(In a hurry, as an auditor, you could make do with a copy of the source code, and see for yourself how the code processes passwords. Source code is not a good substitute for proper documentation, but it is still much better than inference from a cursory look at a database.)

  • 1
    I 100% agree (see my update), but the auditor still needs to review the output (the passwords in storage) to see if the entire process is resulting in the expected result. I have seen far too many instances of the proper specification being used (in documentation and code) but some error or mishandling used at some point that resulted in radically different results (even plain passwords in databases). I would say that the auditor needs to check both, especially if the auditor is not a code specialist (not an uncommon scenario). – schroeder Jun 12 '15 at 16:03
  • The second paragraph is just plain wrong. Source code tells you what actually happens, and the database, the actual results. In many applications, the specification often does not match what actually gets implemented. You should never rely an audit solely based on specification; while specification review might be a decent substitute if you can't get the source code, or if the source code is just total mess and your time-strapped, but it can never replace reviewing the actual source code. Having a clear security specification is a good sign, but in the end it's the implementation that matters. – Lie Ryan Jun 13 '15 at 10:30

The best way to check this is source code review. You should check that the application uses strong hashing, how it uses salt, and doesn't log sensitive data. Also, if the password database supports hash upgrade, then make sure that you take note of the weakest hashing scheme that's still accepted and how many users are still on older/weaker hash.

The drawback with auditing only the database data is that it may be hard/impossible to distinguish between whether a password field is hashed (good) or encrypted (not good).

You should also audit the application log, make sure the application does not logs passwords (e.g. If exception during login).


I would inspect the password storage to see if there are noticeable patterns (e.g. "password1234"), or create a 'test user' with a known password and see if that password is in cleartext in the password stores.

The latter option allows for the possibility of automated tests.

Mostly though, this type of audit only needs to be performed once and upon changes to the way passwords are stored. You could simply manually verify that the passwords are hashed (that means they tend to be the same length and no 'words').


Tom Leek has the more correct way to audit proper password handling, which indicates a weakness in your control - you should have a control that deals with a range of acceptable ways to handle the storage of passwords which is more robust than simply 'not readable'.

That being said, it is also important to look at the storage to see if it is being applied in the expected way.

  • 1
    Hashed and preferably also (uniquely) salted. – Jeroen Jun 12 '15 at 5:35
  • Yes, of course :) but that's outside the scope of this particular control. – schroeder Jun 12 '15 at 6:00

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.