Spotting the Sin During Code Review

Its pretty easy to identify the risks when you encounter a password system. Most properties tend to be pretty easy to validate. And, most of the things you could get wrong could be deemed an acceptable risk, depending on the environment. Its easy to pawn off password problems as end- user issues, but we implore you to look at this auditing checklist with a critical eye as to which things you can easily address.

Password Content Policy

Note that these items are not applicable if using a one-time password scheme.

  • Does the enrollment system automatically generate strong passwords?

  • Does the system allow for arbitrarily long passwords?

  • Does the system allow short passwords?

  • Does the system have some policy to help ensure that passwords will be harder to guess (for example, require no dictionary words and at least one nonalphanumeric character)?

  • Is there any sort of throttling on login attempts?

  • Are there situations where users are intentionally locked out of accounts due to failed login attempts?

  • Does the system require users to change their passwords on a regular basis?

  • When users change a password, is there protection to ensure that they wont choose passwords that were previously associated with the accounts?

Password Changes and Resets

  • Can logged-in users change their passwords via a secure channel?

  • If so, do the changes require passwords to be re-authenticated?

  • Are technical support people able to perform password resets for accounts?

  • If so, do they have to follow sufficient authentication procedures in all cases (for example, do they require users present credentials, such as a drivers licenses)?

  • Does the system support automatic password resets that end users (or attackers ) can initiate?

  • If so, what sort of information must users know or have to reset passwords, and how likely is it that attackers targeting users could learn the information?

  • If password resets occur, what is the delivery mechanism (for example, e-mail) for the reset passwords?

  • If a system comes with preestablished usernames and passwords, does the system force a password change on first login?

Password Protocols

  • Is a standard/well-known protocol being used? This should be an absolute requirement, but there are many such protocols that are still insufficient for many needs, so the remaining checks are still worthwhile. Generally, strong (zero-knowledge) password protocols such as SRP (Secure Remote Passwords) and PDM (Password Derived Moduli) receive high marks; Kerberos-based systems are okay if you use it for both encryption and authentication; and most other things will be pretty poor to bad. In particular, standards such as traditional UNIX crypt(), HTTP Digest Auth, CRAM-MD5 (Challenge-Response Authentication Mechanism), and MD5-MCF (Modular Crypt Format) all have weaknesses, and should only really be used over a pre-authenticated connection.

  • Does the password protocol send the password to the server, or some function of the password (including the stored validator itself)? Unless youre using a zero-knowledge password protocol (a specific class of protocols where people can prove they know the password without revealing the password to anyone who doesnt know it), this will be true.

  • If so, is the password sent over a secure channel, where the client properly authenticates the server before sending the password (over an encrypted and integrity protected link)?

  • Does the password protocol involve the client issuing a challenge and making sure it receives a proper response (usually an authenticated copy of the challenge)? It is important that the challenge can never repeat.

  • Does the password protocol involve the server issuing such a challenge as well?

  • Does the protocol explicitly name the parties as part of the exchange, and have each party confirm the name to the other?

  • Does the protocol prove not only that the client knows the password, but also that the server has the proper validator?

  • Does the authentication result in a key, and is that key (or some cryptographic function thereof) then used to perform ongoing encryption?

Password Handling and Storage

  • When the user types in a password, is there any visual indication of the password length or text? Note for the ultra - paranoid : even showing asterisks
    can give away the length of a password.

  • Are passwords stored in the clear? Thats bad!

  • Are passwords stored in weakly protected permanent store?

  • If not, are password validators stored using a fixed- size output produced by a cryptographically strong one-way mechanism applied to the password (very preferably a standard mechanism, such as PKCS #5, discussed in the Storing and Checking Passwords section)? Reversible mechanisms are about as bad as in-the-clear passwords.

  • Is there a random salt included in the one-way calculation that is different for each password? Salt protects against precomputation attacks, but not targeted crack attacks. About 32 bits worth of salt is good.

  • Is the algorithm iterated a large number of times to help deter crack attacks? For example, rather than hashing the password, you run the hash algorithm thousands of times, hashing the results of the prior hash.

  • If the validator database is stolen, can the attacker log in as the user without using the password? That is, can one use the validator to masquerade as a client? Making such a determination is often best done by a cryptographer.

  • Are all failed logins treated in a uniform manner (same response time and same error handling)?

  • When logging authentication failures, does the program log the password used in the attempt?



19 Deadly Sins of Software Security. Programming Flaws and How to Fix Them
Writing Secure Code
ISBN: 71626751
EAN: 2147483647
Year: 2003
Pages: 239

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net