while migrating from 2.1 to 3.1 we've had a similar issue and it could be 
solved by explicitly using "old-encoding".
Maybe you could find useful information in this thread:

-- Steffen

-----Urspr√ľngliche Nachricht-----
[] Im Auftrag von Alan Wright
Gesendet: Mittwoch, 21. September 2011 15:51
An: General Discussion for the Resin application server
Betreff: [Resin-interest] MD5 base64 hash algorithm differences betweenresin 2 
and 4

--Scott thanks - preparedStatement.unwrap() did the job for using 
OraclePreparedStatement but given the JavaDoc warning about the cost of calling 
unwrap() we are have to make a policy decision to only use 
OraclePreparedStatement where we really need a feature such as named parameters 

I am still migrating from 2 to 4.00.22

Old logins are not working and it seems there is an acknowledged difference 
between the implementations of the algorithm between resin 2&  4.

eg: password=  TzW4CeGhlPNePIaacjYO6w==  dbPassword(created under resin 2)=  
TzW4CeGhlPNePIaacjYODr  digest=  MD5-base64

It seems the difference is only for the last few characters.

Presumably if the difference in the implementation is just to do with the 
length of the generated string and/or padding then this could be relied upon.

If I implement a scheme to replace the correct encodings as users login can I 
rely on an assumption that the first 15 characters will match for the same 
password under each implementation to provide a good enough match that triggers 
an update of the database with the full/correct encoding?

I have seen reference in forums to a digest option "old-encoding", is this 
still available?

If it is how would I amend the following to get a copy of the old digest value?

             PasswordDigest digest = new PasswordDigest();
             digest.setAlgorithm("MD5"); // Must match resin.conf
             digest.setFormat("base64"); // Must match resin.conf
             aPasswordDigest = digest.getPasswordDigest(userNameValue, 

If I can't rely 100% on the similarity of the first chars of the encoded 
password to identify valid logins and update the encoding I would like to be 
able to check the dbpassword against both encodings and update the db with the 
correct encoding as necessary.

Asking users for passwords is not an option and wholesale resetting of 
passwords is not ideal from a customer service perspective.

Thanks in advance for any clarification.




Alan Wright
Athene Systems

tel 0845 230 9803

Athene Systems Limited
Registered Office:
Shieling House
Invincible Road
GU14 7QU

Registered in England and Wales No. 3156080

resin-interest mailing list

resin-interest mailing list

Reply via email to