Online examples of SQL database APIs tend to go like this:
Perhaps fine for pedagogical material, and I do the same during development. However, I don't want that for production - hardcoding a database (or any) password in application code simply offends my sensibilities.
Secret splitting divides a message into a number of pieces. In the simplest scheme, all the pieces are required to reconstruct the message. To split the message into, say, 5 pieces, generate 4 random strings, each of the same length as the message, then XOR the message and the random strings together. Save the random strings and the final XOR output. To reconstruct the message, XOR the 5 pieces of saved data.
I've written a package called SpsSplitPasswordStore that implements the simple secret splitting scheme described above. The motivation is to avoid both hardcoding the database password in application code and saving the password in clear text in a file.
The following saves a password:
The file 'sps1.dat' doesn't particularly look like it contains a password. (Yes, security through obscurity, I know.)
This code reconstructs the password:
Thus the database connection preparation code becomes like this:
The security claim I make for SpsSplitPasswordStore is that it is more secure than hardcoding your database username/password pair in your application code.
While convenience usually trumps security in the real world, in this case, SpsSplitPasswordStore also makes it more convenient to change the application's database password without requiring changes to the application.
Edit: Available at http://ss3.gemtalksystems.com/ss/SpsSplitPasswordStore.html.