portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Reopened: (JS2-550) A new Two-way password encoding service allowing decoding of encoded passwords
Date Sun, 02 Jul 2006 13:12:30 GMT
     [ http://issues.apache.org/jira/browse/JS2-550?page=all ]
Ate Douma reopened JS2-550:

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

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"

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"
    <constructor-arg index="0">
      <!-- secret PBE key password -->
    <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>
    <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>

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 new Two-way password encoding service allowing decoding of encoded passwords
> ------------------------------------------------------------------------------
>          Key: JS2-550
>          URL: http://issues.apache.org/jira/browse/JS2-550
>      Project: Jetspeed 2
>         Type: New Feature

>   Components: Security
>     Versions: 2.1, 2.1-dev
>     Reporter: Ate Douma
>     Assignee: Ate Douma
>      Fix For: 2.1, 2.1-dev

> 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
> 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"
>     <constructor-arg index="0">
>       <!-- secret PBE key password -->
>       <value>********</value>
>     </constructor-arg>       
>   </bean>       
> In jetspeed-services.xml:
>   <bean id="PortalServices" class="org.apache.jetspeed.services.JetspeedPortletServices">
>      <constructor-arg>
>        <map>
>          <entry key="PortletRegistryComponent">
>            <ref bean="org.apache.jetspeed.components.portletregistry.PortletRegistry"
>          </entry>
>          ...
>          <entry key="PasswordEncodingService">
>            <ref bean="org.apache.jetspeed.security.PasswordEncodingService" />
>          </entry>
>          ...
>        <map>
>      <constructor-arg>
>    </bean>
> Using the PBEPasswordTool standalone is possible as follows.
> Running the following command
>   java -cp jetspeed-api-2.1-dev.jar:jetspeed-security-2.1-dev.jar:commons-codec-1.3.jar
> gives the following output:
>   Encode/Decode a user password using Password Based Encryption
>   Usage: PBEPasswordTool <encode|decode> <encoding-password> <username>
>     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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message