SIP Communicator GSoC 2010 Application Part 2

The Problem
This part describes what the project idea is all about and what needs to be done.
The thing with security is that a system is secure only as much as it's weakest link. That weakest link happens to be the password most of the time. Not only can it be easy to guess, even worst, it can be SEEN by simply knowing a thing or two about how the system works. SIP Communicator (SC) stores it's passwords insecurely in a Base64-encoded string inside ~/.sip-communicator/sip-communicator.properties. Just grep for PASSWORD=, run base64 -d on that value and you're done, you have the password for the account. Sure, only the user can read files in his home directory. But insecure still and good software needs good security.
If we go deep into the code then here's what we have (mostly taken from my letter to SC dev list):

AccountManager loads the accounts on start-up in a separate thread. It's doLoadStoredAccounts() method is called for all supported
ProtocolProviderFactory implementations, and this method (besides other things) decodes the stored password and puts it in a map along with other properties; the map is then passed into the ProtocolProviderFactory.loadAccount() is done for all accounts for the given protocol. Now, inside ProtocolProviderFactory.loadAccount, a protocol specific AccountID is created from the passed-in properties map.
After that, things get interesting: in the same method ServiceRegistration object is created with the call bundleContext.registerService(...). This triggers inside a new thread a call chain from ProtocolProviderFactory*Impl.register() (which has our created AccountID with the password inside) to ProtocolProviderFactory.loadPassword(bundleContext, accountID) which does the same thing as doLoadStoredAccounts() - loads and decodes the password.

Actually, it seems that doLoadStoredAccounts() password decoding is some old code that should be deleted, I commented it out and it ran ok. So the things that needs to be refactored to support third party password storage utilities is ProtocolProviderFactory's loadPassword and storePassword methods.

Of course we still must preserve the current plaintext storage because not everyone runs GnomeKeyring/Kwallet/other utility, but we still must have a system that can identify what password storage utility is available and use it or fall back to the default plaintext base64 storage.