Configuring secure passwords

You might recall from the security audit in Chapter 1, Anatomy of an Unsafe Application, that the security of passwords stored in cleartext was a top priority of the auditors. In fact, in any secured system, password security is a critical aspect of trust and authoritativeness of an authenticated principal. Designers of a fully secured system must ensure that passwords are stored in a way in which malicious users would have an impractically difficult time compromising them.

The following general rules should be applied to passwords stored in a database:

• Passwords must not be stored in cleartext (plaintext)
• Passwords supplied by the user must be compared to the recorded passwords in the database
• A user's password should not be supplied to the user upon demand (even if the user forgets it)

For the purposes of most applications, the best fit for these requirements involves one-way encoding, known as the hashing of the passwords. Using a cryptographic hash provides properties such as security and uniqueness that are important to properly authenticate users, with the added bonus that once it is hashed, the password cannot be extracted from the value that is stored.

In most secure application designs, it is neither required nor desirable to ever retrieve the user's actual password upon request, as providing the user's password to them without the proper additional credentials could present a major security risk. Instead, most applications provide the user the ability to reset their password, either by presenting additional credentials (such as their social security number, date of birth, tax ID, or other personal information), or through an email-based system.

Storing other types of sensitive information                                        
Many of the guidelines listed that apply to passwords apply equally to other types of sensitive information, including social security numbers and credit card information (although, depending on the application, some of these may require the ability to decrypt). Storing this type of information to represent it in multiple ways, for example, a customer's full 16-digit credit card number, would be stored in a highly encrypted form, but the last four digits might be stored in cleartext. For reference, think of any internet commerce site that displays XXXX XXXX XXXX 1234 to help you identify your stored credit cards.

You may already be thinking ahead and wondering, given our admittedly unrealistic approach of using SQL to populate our H2 database with users, how do we encode the passwords? H2, or most other databases for that matter, don't offer encryption methods as built-in database functions.

Typically, the bootstrap process (populating a system with initial users and data) is handled through a combination of SQL loads and Java code. Depending on the complexity of your application, this process can get very complicated.

For the JBCP calendar application, we'll retain the dataSource() bean declaration and DataSource is a name in code in the corresponding SQL, and then add some SQL that will modify the passwords to their hashed values.