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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>* 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >* 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 < [EMAIL PROTECTED]> 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 > > > > > > > > > >
