[sip-comm-dev] Generic password storage


#1

Hi all, Ben, Dmitri, Emil,

Hi all,
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
which?

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
configuration.

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
present.".

This default storage implementation (InternalPasswordStorage?) will
utilize the JCE facilities and the ConfigurationService to manage
passwords.

The encrypted account
passwords could be stored in the same configuration property as
previously.

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
his reply.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey George

На 07.05.10 16:37, George Politis написа:

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
present.".

This default storage implementation (InternalPasswordStorage?) will
utilize the JCE facilities and the ConfigurationService to manage
passwords.

A few clarifications here. We did agree that within this GSoC project we
will only worry about a cross-platform java storage mechanism.

George, I guess you are referring to our off-list discussion where we
also talked about the possibility we would one day also add support for
native key rings.

Note however that this would be entirely hidden from the rest of the
application which would continue accessing passwords through the same
methods of the same password service.

The day we decide to have OS dependent storage we'll it would most
likely be enough for its bundle activator to register a
platform-specific implementation. In other words, I don't think we need
to worry about factories and such.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Absolutely, I only wanted to emphasize the extensibility of the mechanism. Thank you for the clarifications!

···

On 05/07/2010 05:08 PM, Emil Ivov wrote:

Hey George

На 07.05.10 16:37, George Politis написа:

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
present.".

This default storage implementation (InternalPasswordStorage?) will
utilize the JCE facilities and the ConfigurationService to manage
passwords.

A few clarifications here. We did agree that within this GSoC project we
will only worry about a cross-platform java storage mechanism.

George, I guess you are referring to our off-list discussion where we
also talked about the possibility we would one day also add support for
native key rings.

Note however that this would be entirely hidden from the rest of the
application which would continue accessing passwords through the same
methods of the same password service.

The day we decide to have OS dependent storage we'll it would most
likely be enough for its bundle activator to register a
platform-specific implementation. In other words, I don't think we need
to worry about factories and such.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net