ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: resultClass for BLOB field
Date Tue, 19 Dec 2006 04:51:49 GMT
Not to beat a dead horse....but I think Nathan's point was that it should
not be possible to decrypt the password.  It's fairly standard practice to
use a hash algorithm such as SHA1 combined with a random initialization
vector (random junk appended to and stored with the password).

Cheers,
Clinton

On 12/18/06, Karen Koch <kmkoch@sbcglobal.net> wrote:
>
> Yes, actually, I misspoke when I said I was decrypting the password.
> There are times when other data that I'm encrypting has to be decrypted in
> order to present it to the user (as in user-defined challenge question to
> confirm identity in case they forgot their password) or to pass on to a
> third party (as with credit card transaction processing), both over SSL, but
> I don't actually bother to decrypt the password...
>
> Thank you, though!
> Karen
>
> *Nathan Maves <nathan.maves@gmail.com>* wrote:
>
> Just a thought but you might want to think about never decrypting a
> password.  I would just compare the two encrypted version.
>
> Just one extra safety step :)
>
>
>
> On 12/18/06, Clinton Begin <clinton.begin@gmail.com> wrote:
> >
> >
> > Sorry Karen, I messed up in my explanation. I didn't fully read your SQL
> > or your mapping.
> >
> > You can't do it directly like that.  This is one of the few (perhaps the
> > only?) type that iBATIS can't return directly.  You'll need to create a
> > class that has a byte[] property, "Password" for example.  Since you're
> > doing a number of operations for encryption and transformation from string
> > to binary types, a Password class might be useful anyway.
> >
> > If you're in control of this database, I always recommend storing such
> > things as hex in a CHAR or VARCHAR field, rather than binary. That way you
> > could just map it to a string.  It's way easier to deal with in every way,
> > its no less secure and it's probably faster.
> >
> > If you're not in control of the database, you'll need to do as I
> > suggested above.
> >
> > Cheers,
> > Clinton
> >
> > On 12/18/06, Karen Koch < kmkoch@sbcglobal.net> wrote:
> > >
> > > Re: your comments, Clinton, the field is not huge, and I just want to
> > > grab a stored encrypted password in order to decrypt it and compare to the
> > > user-entered password (part of a login procedure).
> > >
> > > Now, my latest problem: substituting "byte[]" in for the resultClass
> > > yields a java.lang.ClassNotFoundException exception for byte[].  (I
> > > forgot to mention having already attempted that.)
> > >
> > > <select id="getEncryptedPassword" resultClass="byte[]"
> > > parameterClass="string">
> > >         SELECT Password FROM EPLoginAccount WHERE EmailAddr = #value#
> > >
> > > Perhaps I'm not familiar with how to return an array from a
> > > statement.  A bit of help?
> > >
> > > Thanks again,
> > > Karen
> > >
> > > *Clinton Begin <clinton.begin@gmail.com >* wrote:
> > >
> > > Right.  We don't make use of the JDBC Blob/Clob classes.  So you have
> > > to use a byte[] (byte array).
> > >
> > > However, if your BLOB is huge, you might want to stream it directly to
> > > disk, or even directly to the browser.  In this case you'll want to bypass
> > > iBATIS, as it likely doesn't make sense to map huge data structures to
> > > anything resident in memory.
> > >
> > > Cheers,
> > > Clinton
> > >
> > > On 12/18/06, Karen Koch < kmkoch@sbcglobal.net> wrote:
> > > >
> > > > Hello --
> > > >
> > > > I think this is a simple one:  What is the proper resultClass to use
> > > > when returning only a single column (of BLOB type) as the result of a
> > > > statement?  SqlMaps doesn't seem to like "BLOB".
> > > >
> > > >  <select id="getEncryptedPassword" resultClass=???
> > > > parameterClass="string">
> > > >         SELECT Password FROM EPLoginAccount WHERE EmailAddr =
> > > > #value#
> > > >  </select>
> > > >
> > > > Thanks!
> > > > Karen Koch
> > > >
> > >
> > >
> > >
> >
>
>

Mime
View raw message