• Post Reply Bookmark Topic Watch Topic
  • New Topic

comparing digest always return false. why?  RSS feed

 
Philip Fry
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I've been trying to write my first app, and I'd like for it to store users passwords. Eventually.I have been am using apache.derby for a database and been able to add users to the table in the said database.
Records consist of: login(string), hash(string), salt(string). Or varchars rather.
I've been using JPassworField for getting password char[] arrays. Then have been converting them to byte[]->to Strings, and inserting them into the table. Like this:



The query: "select * from users;" displays everything as it should so it's all good. Originally I was trying to retrive each hash as byte[] array as follows:

but some exception would be thrown saying getting byte[] from varchar field cannot be done. So i tried changing the field data type to a varchar for bit data, or a blob, as I found in some Oracle's pdf doc these were the data fields types I could retrieve bytes[] array. No luck, whatever. So I moved on to using Strings.

Now, here's what just won't work and I honestly am not able to comprehend. Hashes are generated and stored in a digested forms using:



How I convert Strings to byte[] arrays (which also seams to be working):



Then I compare digests with:



digesta and digestb are instance varaiables btw.

And like I said before, select * query shows all the records as it should, and hashes are composed of some weird characters. But encoding/decoding? seams to be working, and I have checked that by displaying system,outs before and after every step involving storing/retrieving/converting the particular hash in question.

compareHashes method never ever evaluates to true(*). I am sure that there is something not quite right with converting Strings to chars[] and bytes[], I cannot figure out what though.
And yes, I am aware that assigning passwords to Strings is not the brightest idea, as such strings could be dumped and what not. However, since I haven't been able to use chars[] and bytes[], it appeared as a good and easy enough, temporary and optional solution. I was wrong yet again. No surprises there

Hence my question: how do i compare stored digests with generated digests on the go for them to be equal? I know am quite close to solving it, as when i put the above two methods in a separate class along with main method, surprisingly it works(*):



There are neither exceptions or errors and code compiles so am not sure what else to post.
Also, my English is far from awesome, so I hope you guys can understand what I am trying to say here.

Help?
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16057
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch.

It looks like you have some binary data, in the form of a byte array, and you're trying to store that in a string, for example in your generate method:

Strings are meant for storing text, not arbitrary binary data. Don't try to force arbitrary binary data into a string.

If you really want to store bytes in a string, then use for example Base64 encoding. The Apache Commons Codec library contains a Base64 encoder and decoder that you could use.
 
Philip Fry
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow. Thanks for such a quick reply.

I'll look into what you suggested.
I'd rather avoid converting Strings into bytes[], just haven't been able to find a way yet.
 
Philip Fry
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just came back to say thanks to Jasper again. That library is great and sorts out the issue.
 
Paul Clapham
Sheriff
Posts: 22819
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's good that you have something working; but the real problem was that you chose to use a varchar column in your database table for something which isn't text. Some kind of binary-data column would have been better in that you wouldn't have to use the Base64 workaround.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!