Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 516
  • Last Modified:

Digest

Hello, I have a question please.

Is the digest method from the standard java (1.4 and later) is JVM dependent ???

What I mean. I use the digest to keep my passwords at the db somehow.
Is this going to be compatible to other JVM's ? For example if I change a cluster. The records will be the same but the JVM different.

Any ideas about how the method is being implemented ???
Thank you in advance.
0
pouli
Asked:
pouli
  • 9
  • 9
  • 7
1 Solution
 
CEHJCommented:
>>Is this going to be compatible to other JVM's ?

In short yes. A digest generated in 1.5 will be the same as one generated in 1.4
0
 
pouliAuthor Commented:
No matter the JVM's ???


What have you say about the 1.3?
Is it going to work ??
0
 
CEHJCommented:
Where you are able to use MessageDigest at all, the same algo should return the same digest of an identical source
0
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

 
pouliAuthor Commented:
Do you think that there is a problem because I save the digest as a string to the DB.

and then when I want to reconstruct it I read it as a UTF-8 and make the comparison ???
0
 
CEHJCommented:
What you should probably do is save it as a String by saving the hex value of the array. Although there *should* be the same de/encoding procedures, i would not bank on it for ever, but also i don't like the idea of attempting to encode an array that may be entirely invalid as a UTF-8 String. Yet another reason to go hex is that you've got a human-readable representation of the hash value ready to hand. Obviously, make sure that 0-padding is used.
0
 
pouliAuthor Commented:
Please, give me an example.
0
 
CEHJCommented:
You could use this on the digest byte array:

      public static String byteArrayToHexString(byte[] rawBytes) {
            StringBuffer sb = new StringBuffer(rawBytes.length * 2);
            for (int i = 0; i < rawBytes.length; i++) {
                  String s = Integer.toHexString(rawBytes[i] & 0xFF);
                  if (s.length() == 1) {
                        // leading zero
                        sb.append('0');
                  }
                  sb.append(s);
            }
            return sb.toString();
      }
0
 
pouliAuthor Commented:
ok One question
why do you
rawBytes[i] & 0xFF

filter the byte with & 0xFF

and what are u doing wihth the length ???
 if (s.length() == 1) {
                    // leading zero
                    sb.append('0');


Actually everything  :)
please
0
 
CEHJCommented:
>>why do you  rawBytes[i] & 0xFF

Because bytes are signed in Java. You need to 'unsign' it and that's what that does.

>>and what are u doing wihth the length ???

As i mentioned, you need to 0-pad the result or you'll get varying lengths returned for a 32 bit digest, depending on the values contained in each element of the array
0
 
objectsCommented:
whats your problem exactly?
0
 
pouliAuthor Commented:
The problem objects is that the same algorithm works under the same JVM and specific under 1.3

but when you run it under other JVM (ver 1.4) then it doesn't.
I will try the CEHJ's way and I will tell you again what the result is
0
 
objectsCommented:
post the code you currently use to store and retrieve your digest.
0
 
objectsCommented:
sounds like you need to use Base 64 encoding. Lots of implementations around, even one from Sun.
Let me know if u need more info.
0
 
CEHJCommented:
Base64 encoding is not a good idea. All it does is provide an encodable String from the digest. You can get the same effect by rendering the digest as a hex string *and* it's human readable without further decoding
0
 
pouliAuthor Commented:
Sorry, about my absence. ISP problems.

Problem has been solved CEHJ your code was perfect thank you.

Objects my I wanted to be difficult for somebody to read the passwprd from the DB and the Base64 is not the solution.

The algo is like this
1. take the curretn time
2. save the digest of the password  + currentime to a field
3. save current time to othe rfield as well.

Now when we want to check if the code is right we reconstruct the password in the opposite way:
1. read the timestap
2. Concatenate it with the password
3. Digest this
4. f it is the same with the one stored at the db then that's it The password is right otherwise it is wrong.\

That way there is no way to reverse the digest to see the password.
Except if somebody find a way to reverse a SHA-1 digest.

That's all my friends.

Talk u later
0
 
CEHJCommented:
8-)
0
 
objectsCommented:
> Objects my I wanted to be difficult for somebody to read the passwprd from the DB and the Base64 is not the solution.

would have to disagree there
you're just reinventing the wheel really.
0
 
CEHJCommented:
>>you're just reinventing the wheel really.

You're missing the point - it doesn't have to be encrypted twice and should be human readable
0
 
pouliAuthor Commented:
Sorry, that I haven't answered but I cannot see my Yahoo emails, I just think that you may have post a comment.

Now, to our subject.

--Objects--
Why am I reinveting the wheel ?
As far as I know Base64 does not use any key right ???
So everybody can read the pass + timestamp from the db right ???

Now, with the algorithm that we are talking about noboy can read the password unless he/she knows the keyword.

Only then he can make the same Digest, thus authenticated himself with the system.
Otherwise not.

Please ask me what is the point that you do not fully understand.

0
 
objectsCommented:
> As far as I know Base64 does not use any key right ???
> So everybody can read the pass + timestamp from the db right ???

No, you use Base64 to encode the digest into a string.

0
 
pouliAuthor Commented:
Ahh right. sorry objects. Now I have understoof what you mean by reinventing the wheel.

Yes you may be right although I haven't tried this.
Anyway seems that it works the way CEHJ post it to me and this is how we included it to our code.
No time for changes now.

Both ways are right and makes the job.

Thank you for the input objects.
0
 
objectsCommented:
No worries :)

u know where to find me when you have anymore questions.
0
 
pouliAuthor Commented:
Hey people could you please have a look. I think that I have posted this to the wrong category

http://www.experts-exchange.com/Databases/Oracle/Q_20971967.html

It is more Ant related
0
 
CEHJCommented:
>>Ahh right. sorry objects. Now I have understoof what you mean by reinventing the wheel.

Then there are now two people here that have not got the point ;-) The point is, you don't generally want digests in a format that's not human-readable - it just makes things difficult. If you go to download sites that have proper implementations where they show the MD5 hash of the file, you don't get that in Base64, you get the String representation, so you can see what it is and use it and manipulate it more portably
0
 
objectsCommented:
Sounds like there just 1 who's missing the point here :D
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 9
  • 9
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now