[sip-comm-dev] Generic password storage


#1

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. 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.
We could use the following scenario (very similar to what firefox
uses, for example):
The user starts SC. If any (encrypted)saved account passwords are
found in the configuration and the master password is set, a master
password input dialog is presented to the user. If the master password
is not set, then we can use some default hard coded password (or
nothing at all?). The saved accounts' passwords are decrypted with the
master password. When adding new account passwords to be remembered,
the master password input is also presented. The encrypted account
passwords could be stored in the same configuration property as
previously.

3 and 2. Define and implement CredentialsStorageService.
Seems straightforward at the moment. An interface for doing all the
things described above is required.

4. Change all existing protocol implementations to use the above service
Actually all protocol implementation extend the abstract
ProtocolProviderFactory that handles accounts and passwords, so all
the changes should be in one place.

5. Password migration: provide a transition utility that would migrate
passwords currently stored in one’s configuration file to the new
utility. The utility would need to do this automatically without
bothering the user.
This could potentially be tricky. SC needs to somehow detect that the
new system is in use and convert everything. Another possibility is to
convert everything only when setting/updating the master password,
since if the master password is not set, there's no real security
anyway.

Hope to hear some comments/suggestions.

Cheers,
Dmitri

···

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


#2

Hi Dmitri, all,

I'm Ben, one of your mentor for this GSoC and glad to talk to you.

I'm not an expert in security providers so maybe someone could have
more useful remarks than I do.
You seems to have a very clear view of this project and everything you
present here make sens to me.
To me it would be interesting to make a quick survey on the different
security providers to see which one should be used.
About the migration, I don't think we should worry about it as, like
you said, detecting if the service is just installed should be very
straightforward.

Cheers,

Ben.

···

On Thu, May 6, 2010 at 23:28, Dmitri Melnikov <dmitri807@gmail.com> wrote:

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. 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.
We could use the following scenario (very similar to what firefox
uses, for example):
The user starts SC. If any (encrypted)saved account passwords are
found in the configuration and the master password is set, a master
password input dialog is presented to the user. If the master password
is not set, then we can use some default hard coded password (or
nothing at all?). The saved accounts' passwords are decrypted with the
master password. When adding new account passwords to be remembered,
the master password input is also presented. The encrypted account
passwords could be stored in the same configuration property as
previously.

3 and 2. Define and implement CredentialsStorageService.
Seems straightforward at the moment. An interface for doing all the
things described above is required.

4. Change all existing protocol implementations to use the above service
Actually all protocol implementation extend the abstract
ProtocolProviderFactory that handles accounts and passwords, so all
the changes should be in one place.

5. Password migration: provide a transition utility that would migrate
passwords currently stored in one’s configuration file to the new
utility. The utility would need to do this automatically without
bothering the user.
This could potentially be tricky. SC needs to somehow detect that the
new system is in use and convert everything. Another possibility is to
convert everything only when setting/updating the master password,
since if the master password is not set, there's no real security
anyway.

Hope to hear some comments/suggestions.

Cheers,
Dmitri

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

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


#3

Hey Dmitri,

Adding to what Ben said:

На 06.05.10 23:28, Dmitri Melnikov написа:

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?

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?

We could use the following scenario (very similar to what firefox
uses, for example):
The user starts SC. If any (encrypted)saved account passwords are
found in the configuration and the master password is set, a master
password input dialog is presented to the user.

That's the idea yes. This behaviour will be implemented in the service
implementation.

The saved accounts' passwords are decrypted with the
master password. When adding new account passwords to be remembered,
the master password input is also presented.

Only the first time though. Right?

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.

4. Change all existing protocol implementations to use the above service
Actually all protocol implementation extend the abstract
ProtocolProviderFactory that handles accounts and passwords, so all
the changes should be in one place.

Indeed.

5. Password migration: provide a transition utility that would migrate
passwords currently stored in one’s configuration file to the new
utility. The utility would need to do this automatically without
bothering the user.
This could potentially be tricky. SC needs to somehow detect that the
new system is in use and convert everything.

I am not sure I understand. Why would this be an issue? Migration would
be handled by the new service implementation. If the migration code is
there - then we are using the new system. What's there to detect?

We do need to be able to distinguish passwords that were stored with the
old system but this could be as simple as using a new property name for
really encrypted passwords.

How does this sound?

Emil

···

Another possibility is to
convert everything only when setting/updating the master password,
since if the master password is not set, there's no real security
anyway.

Hope to hear some comments/suggestions.

Cheers,
Dmitri

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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


#4

Hi Ben,

Hi Dmitri, all,

I'm Ben, one of your mentor for this GSoC and glad to talk to you.

Nice to meet you, Ben!

I'm not an expert in security providers so maybe someone could have
more useful remarks than I do.
You seems to have a very clear view of this project and everything you
present here make sens to me.
To me it would be interesting to make a quick survey on the different
security providers to see which one should be used.

Well, basically Bouncy Castle provider implements a lot of different
algorithms. The default provider, SunJCE, has less, but it too has all
the popular encryption algorithms like AES and TripleDES. I haven't
used any other providers, but to the programmer there's really not
much difference because all of them implement the Java Cryptography
Extension API.

About the migration, I don't think we should worry about it as, like
you said, detecting if the service is just installed should be very
straightforward.

Yes, I suppose it's not really a problem as I first imagined.

Cheers,

Ben.

All the best,
Dmitri

···

On Fri, May 7, 2010 at 11:28 AM, Benoit Pradelle <b.pradelle@gmail.com> wrote:

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


#5

Hi Emil,

Hey Dmitri,

Adding to what Ben said:

На 06.05.10 23:28, Dmitri Melnikov написа:

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 think that since we only need a small part of what crypto libraries
can do, the default SunJCE provider should be enough to
encrypt/decrypt a password with some popular algorithm like AES.
Adding the heavyweight Bouncy Castle as a dependency would be too much
in this case. We could use Jasypt that abstracts the
encyption/decryption to a couple of lines of code, but it too uses the
same JCE API.

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?

We could use the following scenario (very similar to what firefox
uses, for example):
The user starts SC. If any (encrypted)saved account passwords are
found in the configuration and the master password is set, a master
password input dialog is presented to the user.

That's the idea yes. This behaviour will be implemented in the service
implementation.

The saved accounts' passwords are decrypted with the
master password. When adding new account passwords to be remembered,
the master password input is also presented.

Only the first time though. Right?

Well, yes, we can ask for the master password to unlock(decrypt and
display) the account passwords. When that window/dialog is closed, the
master password is cleared. Like in firefox.

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.

4. Change all existing protocol implementations to use the above service
Actually all protocol implementation extend the abstract
ProtocolProviderFactory that handles accounts and passwords, so all
the changes should be in one place.

Indeed.

5. Password migration: provide a transition utility that would migrate
passwords currently stored in one’s configuration file to the new
utility. The utility would need to do this automatically without
bothering the user.
This could potentially be tricky. SC needs to somehow detect that the
new system is in use and convert everything.

I am not sure I understand. Why would this be an issue? Migration would
be handled by the new service implementation. If the migration code is
there - then we are using the new system. What's there to detect?

As I understand it, when an old saved password is read from the
config, it is automatically encrypted and saved to the new property.
The old property is deleted. Am I correct?

We do need to be able to distinguish passwords that were stored with the
old system but this could be as simple as using a new property name for
really encrypted passwords.
How does this sound?

When I wrote this I was thinking in terms of a single password
property. Using a new property for the encrypted password is indeed a
simple solution.
There's still one more issue, what to do when there's no master
password: to use some hardcoded value or not to use encryption at all
in this case?

Cheers,
Dmitri

···

On Fri, May 7, 2010 at 1:47 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

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


#6

На 07.05.10 16:05, Dmitri Melnikov написа:

I think that since we only need a small part of what crypto libraries
can do, the default SunJCE provider should be enough to
encrypt/decrypt a password with some popular algorithm like AES.
Adding the heavyweight Bouncy Castle as a dependency would be too much
in this case. We could use Jasypt that abstracts the
encyption/decryption to a couple of lines of code, but it too uses the
same JCE API.

Agreed.

That's the idea yes. This behaviour will be implemented in the service
implementation.

The saved accounts' passwords are decrypted with the
master password. When adding new account passwords to be remembered,
the master password input is also presented.

Only the first time though. Right?

Well, yes, we can ask for the master password to unlock(decrypt and
display) the account passwords. When that window/dialog is closed, the
master password is cleared. Like in firefox.

Explicitly requesting the master password every time one wants to show
all stored passwords from within the configuration form is a good idea.
However, keep in mind, that you also need the master password every time
a protocol connects, or a new password is stored. The storage service
implementation would therefore need to keep a reference through its
entire lifetime.

As I understand it, when an old saved password is read from the
config, it is automatically encrypted and saved to the new property.
The old property is deleted. Am I correct?

You are.

We do need to be able to distinguish passwords that were stored with the
old system but this could be as simple as using a new property name for
really encrypted passwords.
How does this sound?

When I wrote this I was thinking in terms of a single password
property. Using a new property for the encrypted password is indeed a
simple solution.
There's still one more issue, what to do when there's no master
password: to use some hardcoded value or not to use encryption at all
in this case?

Using a hardcoded value (or an empty string for that matter) would give
us the mangling we have now. We implemented that because we considered
it a better option than storing plain text.

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