A new Two-way password encoding service allowing decoding of encoded passwords

Details

Description

For password encoding Jetspeed currently only provides the MessageDigestCredentialPasswordEncoder in the security component.
While highly secure, this encoding solution cannot be used when you would like to be able to recover lost passwords, like providing the clear text value back to the user to a know/trusted email address. Or for an trusted administrator to be able to do the same manually.

Therefore, I'll provide a new two-way encoding solution based on PKCS #5 PBE (Password Based Encryption), which uses a cipher generated from a secure password to encode user passwords. For this solution I'll provide a service which both implements the security component SPI CredentialPasswordEncoder as well as a decode method to retrieve the clear text value of an encoded password.

Thus, I'll add a new PasswordEncodingService interface to the jetspeed-api and a PBEPasswordService implementation in the security component.
The PBEPasswordService both extends a POJO PBEPasswordTool class, which also can be used standalone through a main method, as well as the CredentialPasswordEncoder.

This way, this new service can both be made available as a portlet service through the Jetspeed Spring configuration for usage from specialized Portlet Applications, as well be used as a replacement for the default MessageDigestCredentialPasswordEncoder.

Example Jetspeed Spring configuration how to make use of the new service could be as follows.

In security-spi-atn.xml:

<!-- A Two-way encoding password service which also implements CredentialPasswordEncoder
this Service can be used instead of for example the default provided MessageDigestCredentialPasswordEncoder -->
<bean id="org.apache.jetspeed.security.PasswordEncodingService" name="org.apache.jetspeed.security.spi.CredentialPasswordEncoder" class="org.apache.jetspeed.security.spi.impl.PBEPasswordService">
<constructor-arg index="0">
<!-- secret PBE key password -->
<value>********</value>
</constructor-arg>
</bean>

Encode/Decode a user password using Password Based Encryption
Usage: PBEPasswordTool <encode|decode> <encoding-password> <username> <password>
encode|decode : specify if to encode or decode the provided password
encoding-password: the password to be used for encoding and decoding
username : the name of the user to which the provided password belongs
password : the cleartext password to encode, or the encoded password to decode

I'm also going to provide an extension to the PasswordEncodingService interface as well as an implementation, which will one to (lazy) upgrade from one PasswordCredentialEncoder to a new one. More specifically, from using MessageDigestCredentialPasswordEncoder to PBEPasswordService.

This allows existing system which cannot upgrade the stored passwords directly because they are created using a one-way encryption, to gradually migrate to a two-way encryption solution (if you really need it, it is less secure of course).

First of all, I'll provide a new interface AlgorithmUpgradePasswordEncodingService which defines a boolean usesOldEncodingAlgorithm(PasswordCredential) method.
This method can be used to check if a selected PasswordCredential are has its password encoding upgraded.

Furthermore, I'll provide an AlgorithmUpgradeCredentialPasswordEncoder interface extending CredentialPasswordEncoder allowing to recode a password from the old encoding to the new encoding during user authentication when the user has provided a (validated) clear text password value.

Finally, as implementation, I'll provide a AlgorithmUpgradePBEPasswordService class extending the PBEPasswordService and implementing the above interfaces.
For this class to be able to distinguish between "old" not yet recoded passwords and already PBEPassword encoded passwords, it evaluates several timestamp properties from the InternalCredential (or PasswordCredential), and for this, it needs to be configured with the date when the switch is made between the "old" CredentialPasswordEncoder and the PBEPasswordService encoding.
And, to be able to authenticate not-yet recoded passwords, it needs an instance of the "old" CredentialPasswordEncoder.

And example configuration of this AlgorithmUpgradeCredentialPasswordEncoder (in security-spi-atn.xml):

To make sure the AlgoritmUpgradePBEPasswordService can reliably know if an encoded password needs to be upgraded, I've also improved some of the InternalCredential modifying (and querying) methods as in some situations, the ModifiedDate, PreviousAuthenticationDate and LastAuthenticationDate were not set/updated as needed. These changes should have no effect on current/other usages as these fields weren't used much (yet).

Ate Douma
added a comment - 02/Jul/06 20:11 I'm also going to provide an extension to the PasswordEncodingService interface as well as an implementation, which will one to (lazy) upgrade from one PasswordCredentialEncoder to a new one. More specifically, from using MessageDigestCredentialPasswordEncoder to PBEPasswordService.
This allows existing system which cannot upgrade the stored passwords directly because they are created using a one-way encryption, to gradually migrate to a two-way encryption solution (if you really need it, it is less secure of course).
First of all, I'll provide a new interface AlgorithmUpgradePasswordEncodingService which defines a boolean usesOldEncodingAlgorithm(PasswordCredential) method.
This method can be used to check if a selected PasswordCredential are has its password encoding upgraded.
Furthermore, I'll provide an AlgorithmUpgradeCredentialPasswordEncoder interface extending CredentialPasswordEncoder allowing to recode a password from the old encoding to the new encoding during user authentication when the user has provided a (validated) clear text password value.
Finally, as implementation, I'll provide a AlgorithmUpgradePBEPasswordService class extending the PBEPasswordService and implementing the above interfaces.
For this class to be able to distinguish between "old" not yet recoded passwords and already PBEPassword encoded passwords, it evaluates several timestamp properties from the InternalCredential (or PasswordCredential), and for this, it needs to be configured with the date when the switch is made between the "old" CredentialPasswordEncoder and the PBEPasswordService encoding.
And, to be able to authenticate not-yet recoded passwords, it needs an instance of the "old" CredentialPasswordEncoder.
And example configuration of this AlgorithmUpgradeCredentialPasswordEncoder (in security-spi-atn.xml):
<!-- A Two-way encoding password service which also implements CredentialPasswordEncoder
Furthermore, this extension of the PBEPasswordService supports lazy upgrading from an old CredentialPasswordEncoder
like the default provided MessageDigestCredentialPasswordEncoder
-->
<bean id="org.apache.jetspeed.security.PasswordEncodingService"
name="org.apache.jetspeed.security.spi.CredentialPasswordEncoder"
class="org.apache.jetspeed.security.spi.impl.AlgorithmUpgradePBEPasswordService">
<constructor-arg index="0">
<!-- secret PBE key password -->
<value>********</value>
</constructor-arg>
<constructor-arg index="1">
<!-- old MessageDigestCredentialPasswordEncoder to be upgrading from, using SHA-1 -->
<bean class="org.apache.jetspeed.security.spi.impl.MessageDigestCredentialPasswordEncoder">
<constructor-arg index="0"><value>SHA-1</value></constructor-arg>
</bean>
</constructor-arg>
<constructor-arg index="2">
<!-- startPBEPasswordEncodingService: date before which old encoded passwords need to be recoded (on authentication)
(SimpleDateFormat) format: yyyy-MM-dd HH:mm:ss
-->
<value>2006-07-02 15:00:00</value>
</constructor-arg>
</bean>
To make sure the AlgoritmUpgradePBEPasswordService can reliably know if an encoded password needs to be upgraded, I've also improved some of the InternalCredential modifying (and querying) methods as in some situations, the ModifiedDate, PreviousAuthenticationDate and LastAuthenticationDate were not set/updated as needed. These changes should have no effect on current/other usages as these fields weren't used much (yet).

A very simple enhancement easy to add, so there it is
It requires an optional boolean constructor parameter "simpleEncryption" which defaults to false, so the current default behavior isn't changed by this.

Ate Douma
added a comment - 30/Jun/06 15:58 A very simple enhancement easy to add, so there it is
It requires an optional boolean constructor parameter "simpleEncryption" which defaults to false, so the current default behavior isn't changed by this.

Well, as you are around this area: how about the opposite – less security.

I have just packaged Jetspeed2 as EAR for JBoss. JBoss comes with a "simple" password encryption algorithm in its database-based JAAS module. After setting up the queries for this module (I had to make the Jetspeed tables look like simple User/Password and User/Roles tables), I found that I still could not log in because although I specified the same algorithm, the password as encoded by JBoss did not match the password as encoded by Jetspeed.

I quickly found out about Jetspeed's "advanced" hashing for password copy protection. As I did not want to write a new JBoss JAAS module, I wrote a new MessageDigestCredentialPasswordEncoder that does "simple" password hashing.

The additional user name hashing could easily be made optional using a configuration property for the default MessageDigestCredentialPasswordEncoder. This would save me from maintaining my extra class .

Michael Lipp
added a comment - 30/Jun/06 15:21 Well, as you are around this area: how about the opposite – less security.
I have just packaged Jetspeed2 as EAR for JBoss. JBoss comes with a "simple" password encryption algorithm in its database-based JAAS module. After setting up the queries for this module (I had to make the Jetspeed tables look like simple User/Password and User/Roles tables), I found that I still could not log in because although I specified the same algorithm, the password as encoded by JBoss did not match the password as encoded by Jetspeed.
I quickly found out about Jetspeed's "advanced" hashing for password copy protection. As I did not want to write a new JBoss JAAS module, I wrote a new MessageDigestCredentialPasswordEncoder that does "simple" password hashing.
The additional user name hashing could easily be made optional using a configuration property for the default MessageDigestCredentialPasswordEncoder. This would save me from maintaining my extra class .