Hi all, Ben, Dmitri, Emil,
I was thinking about the requirements of my first term gsoc project,
the generic password storage. Here are some of my thoughts:
1. Select a Java utility that we’d be able to use for storing passwords
I'm not sure what exactly we are looking for.
Well basically we need to determine who will be encrypting the passwords
and possibly writing them to the disc. Are we going to use java's own
certificate/encryption utilities, or a third party lib with an API
that's closer to the password management we'd like to have. If yes, then
I don't see a reason to use a third party library for password
management (if you think otherwise, please correct me here). We have
everything we need at our disposal, that is the ConfigurationService
and the standard Java Security Provider (and if that is not enough, we
already include a trimmed down version of BouncyCastle that we could
make use of).
Java has a default
security provider implementing JCE that can do things like encryption
and decryption, there are other security providers (like BouncyCastle)
that have more algorithms, and then there are libraries (for example
jasypt) that simplify these processes to some extent. But in any case,
some kind of persistent storage is still required, a database or
OK, I generally like the idea of reusing the configuration service for
the storage itself. George, I remember we discussed things along these
lines a few days ago. Care to chime in?
First of, we discussed about the possibility to use the facilities in
Java that enable key management. On second thought though, the purpose
of a key management system is to store *assymetric/symmetric* keys and
allow you to retrieve them programatically. In our case, we only want
to store passwords, which have nothing to do with cryptography keys,
i.e. we need a password management system.
Another concern (already covered by Dmitri) is how to build a good
password management system capable of integrating with GNOME/Mac
OS/KDE/e.t.c.. Like Dmitri has already described in his application..
"a factory method seems to fit in this situation. We have a
PasswordStorage interface, a PasswordStorageFactory and concrete
PasswordStorage implementations. A default storage implementation
should be available always as a fall-back option if none other are
This default storage implementation (InternalPasswordStorage?) will
utilize the JCE facilities and the ConfigurationService to manage
The encrypted account
passwords could be stored in the same configuration property as
That's an option. I like the idea of a centralized password management
utility (like the one in firefox), and from that perspective it would
probably be easier to also have the passwords stored with a property
prefix of their own.
That would save cpu cycles and make it easier to distinguish between
encrypted and base64 encoded passwords, like Emil already mentioned in