Hi!
One day after i understood what you explained me.
HexUtils.convert just do an hex representation in a string format of the
binary number represented by the array of byte.
I taught that a solution to my problem could be implement a custom realm,
that extends JDBCrealm and overwrite the method getPassword in such a way
protected String getPassword(String username) {
System.out.println("username= "+username);
String password=super.getPassword(username);
log.info("password="+password);
String hexpassword=HexUtils.convert(password.getBytes());
log.info("hexpassword="+hexpassword);
return hexpassword;
}
In theory should work , but I don't know why tomcat still uses the
getPassword of the JDBCrealm , cause I don't see messages printed.
But this is an other problem, and that's better I open another thread.
I hope I'm following the rigtht way
On 3/23/06, Alessandro Colantoni <[EMAIL PROTECTED]> wrote:
>
> Hi !
> I'm lost. Sorry.
> I don't understand when you say
> >I can guarantee that
> >MessageDigest.digest(), which returns an array of bytes, will NOT return
> an
> >array of bytes every time that can be transmitted on a URL i.e. is a
> printable
> >string.
>
> I will try to explain better what I have done
> I have an algorithm called manolo (from the name of the manager of the
> other application that passed it to me).
> I wrote a class
> public class ManoloMessageDigestSpi extends MessageDigestSpi implements
> Cloneable
>
> I have in this class the field
> private byte[] digest = null;
>
> I implemented the method engineDigest:
>
> protected byte[] engineDigest(){
> byte[] completedDigest=this.digest;
> engineReset();
> return completedDigest;
> }
>
> in the engineUpdate(byte input) I just set the field digest with the
> encrypted value of input using the manolo algorithm.
>
>
> I wrote a Provider called ManoloProvider
>
> public final class ManoloProvider extends Provider{
>
> public ManoloProvider() {
> super("manolo", 1.0, "algoritmo pasado por Manolo el 21-03-2006");
> put ("MessageDigest.manolo","
> com.steria.tc.security.ManoloMessageDigestSpi ");
> }
> }
> Then in a servlet that load on startup I do something like that
>
> Security.addProvider(new ManoloProvider)
>
>
> In the context.xml of my application I put
> <Realm className = "org.apache.catalina.realm.JDBCRealm"
> digest="manolo"
> .....
> ....
> />
>
> When The other application(developed in power builder) store a password
> use the manolo algorithm to encrypt it. So what it stores is the same
> value of
> MessageDigest.update(cleartext);
> MessageDigest.digest().toString().
>
> So let's call:
> cleartext : password in cleartext
> digested : password encrypted
> converted: digested converted with HexUtils.convert
> At the end, when Tomcat authenticates it will compare converted with
> digested and always fail.
>
> Everything work fine if was my application to store password, storing
> RealmBase.Digest(cleartext,manolo)
>
> Thanks for attention
> Alessandro
>
>
>
>
>
>
> On 3/22/06, Jay Burgess <[EMAIL PROTECTED]> wrote:
> >
> > Then maybe I'm misunderstanding something. But I can guarantee that
> > MessageDigest.digest(), which returns an array of bytes, will NOT return
> > an
> > array of bytes every time that can be transmitted on a URL i.e. is a
> > printable
> > string. That's why it has to be encoded in some form, and two hex
> > chars/bytes
> > is the way this gets encoded.
> >
> > However, if you really do want to undo the encoding, simply reverse the
> > logic of
> > the encode() method in the MD5Encoder.java file.
> >
> > Alternatively, if you are just trying to authenticate something in your
> > code, it
> > may work to just run through the digest and encode steps yourself, then
> > compare
> > your end result with what the user sent. If they're the same, then
> > they're
> > authenticated, without you needing to "undo" anything.
> >
> > Jay
> >
> > -----Original Message-----
> > From: Alessandro Colantoni [mailto: [EMAIL PROTECTED]
> > Sent: Wednesday, March 22, 2006 12:37 PM
> > To: Tomcat Users List
> > Subject: Re: return (HexUtils.convert(md.digest())) in RealmBase
> >
> > Thanks for answer.
> > I'm sure that the byte representation is printable, because that's a
> > very
> > easy algorithm, and it is working since some year storing correct
> > encrypted
> > password with the other application.
> > What i should need is an inverse operation of the HexUtils.convert.
> > Is there such an algorithm?
> > I 'll explain better.
> > Lets call this inverse operation convert_inv.
> > It should be so that
> >
> > HexUtils.convert
> >
> > (convert_inv(myAlgorithm(myClearCredential)))=myAlgorithm(myClearCredential).
> > So including convert_inv in myAlgorithm (while the other application
> > follow
> > with the original one) I solve my problem.
> >
> > Is it possible?
> > Thanks for help
> > Alessandro
> >
> >
> >
> >
> >
> > On 3/22/06, Jay Burgess <[EMAIL PROTECTED]> wrote:
> > >
> > > I think this is the right answer:
> > >
> > > digest() returns a sequence of bytes. Depending on the values of the
> > > individual
> > > bytes, if you were to try and convert it to String, you can end up
> > with
> > > non-printable characters, etc.
> > >
> > > I'm assuming that HexUtils.convert() turns each 4 bits of each byte
> > into a
> > > hex
> > > character, so that you end up with a proper String representation of
> > the
> > > digest
> > > that can be sent as part of a URL.
> > >
> > > Jay
> > >
> > > | Jay Burgess [Vertical Technology Group]
> > > | http://www.vtgroup.com/
> > >
> > >
> > > -----Original Message-----
> > > From: Alessandro Colantoni [mailto:[EMAIL PROTECTED] ]
> > > Sent: Wednesday, March 22, 2006 12:12 PM
> > > To: Tomcat Users List
> > > Subject: return (HexUtils.convert(md.digest())) in RealmBase
> > >
> > > Hi All!
> > > I saw that both method Digest(..) and digest(..) in RealmBase return (
> >
> > > HexUtils.convert(md.digest())) and not just
> > > md.digest().toString.
> > >
> > > My problem is that user table is maintained by another application
> > > developed
> > > in an other technology.
> > > My application uses this table just to authenticate.
> > > The password of user table is encrypted with an algorithm I've been
> > done.
> > > I wrote a MessageDigestSpi for that algorithm, I wrote my provider, I
> > > registered it and everything looks work fine.
> > > Except that of course if I do:
> > > RealmBase.Digest(myCredentials,myAlgorithm);
> > >
> > > I get a result different from doing
> > > MessageDigest md = MessageDigest.getInstance(myAlgorithm);
> > > md.update(myCredentials.getBytes());
> > > md.digest().toString;
> > >
> > > but the same result of
> > > MessageDigest md = MessageDigest.getInstance(myAlgorithm);
> > > md.update(myCredentials.getBytes());
> > > HexUtils.convert(md.digest())
> > >
> > > So the problem is that the other application stores without using the
> > > HexUtils.convert method
> > > but when tomcat authenticates it uses it.
> > >
> > > One solution could be write a Realm class that extends the JDBCRealm
> > (the
> > > one I'm using) and overwrite these methods.
> > > But I'm afraid that in different versions of Tomcat (i don't want link
> > to
> > > one) could be different signature of these methods.
> > > There's another solution?
> > > At least avoiding overwriting these very important methods?
> > >
> > > And just for curiosity, why HexUtils.convert has been utilized?
> > >
> > > Thanks in advance for help and have a nice springtime
> > > Alessandro
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
