Lester Burnham wrote:No. MD5 is a hash or digest - it's a one-way street, with no way to get the original text back.
What you want is a cipher like AES or Triple-DES; read up on JCE, which is the standard Java API for doing encryption/decryption. The SecurityFaq has some good links about that.
Lester Burnham wrote:Yes. You would store the original password in hashed form, and when someone logs in, you would hash the password they entered, and then you can compare the two hashes (they must be identical).
Lester Burnham wrote:What do you mean by "convert back"? As mentioned before, you can't get back the original text after it has been digested.
Also -and this is true not just in the context of encryption- it's almost always a bad idea to use "new String(byte[])" and "String.getBytes()" - in this day and age, you need to consider encodings. Those two code snippets use the platform default encoding, which is generally not what you want.
Lester Burnham wrote:Isn't that exactly what you posted a few posts back, and to which I responded in my subsequent post? What is getting compared is the hash/digest of the original password (which you have stored somewhere), and the hash/digest of the newly sent password.
Farakh khan wrote:
Thanks for your replies
The problem is that I am not storing password in one db and not comparing the two hashes by getting the password from one machine. I am passing parameters from my server to the bank server and getting response from their machines.
The whole problem am facing to understand the Integration manual. Please ignore my whole previous posts as this was what I conceived but let me know some clue regarding:
Bank in Integration manual says:
======================
Run an encryption mechanism using the secure hash key shared with the merchant to compare it with the value of the field vpc_SecureHash passed. If this test is unsuccessful then the authentication fails and the user is redirected back to the merchant with a corresponding error code.
Farakh khan wrote:I am really confused now as to how I complete this task. I read two times the whole messages but still unable to understand
Henry Wong wrote:
Farakh khan wrote:I am really confused now as to how I complete this task. I read two times the whole messages but still unable to understand
It would help if you tell us what you don't understand. Or better yet, what you think you read, so that we can figure out where your logic went wrong... but I'll try again.
Basically, an md5 hash is one-way... you can take a password and take a md5 hash of it, but you cannot undo the hash.
So, let's say you need to set a password. You take the password, take the md5 hash of it, and store it (the hash) in the database.
Later, you challenge the user for the password, you now have the password, and you need to compare it to the password in the database. How do you do it? Well, since you can't undo the hash, you can't get the original password back, so hence, you can't compare if the two passwords are the same. What you can do is to take a md5 hash of the password, that you just from the password challenge, and compare if the two hashes are the same... because of the way md5 works, if the two hashes are the same, then chances are the two passwords were the same.
Henry
My question is how the bank server will understand my md5 hash because bank server might used different hashing algorithm?
Lester Burnham wrote:
My question is how the bank server will understand my md5 hash because bank server might used different hashing algorithm?
MD5 is a standardized algorithm. Whatever implementation the bank uses had better produce exactly the same results as whatever implementation you're using.
1) Why am getting vpc_SecureHash=null
2) It means my servlet is not sending the secure has key from doPost method
Lester Burnham wrote:
1) Why am getting vpc_SecureHash=null
2) It means my servlet is not sending the secure has key from doPost method
Use an HTTP monitor (or proxy) to see what -exactly- goes over the wire. That should point out quickly what is and is not being sent. Something like https://tcpmon.dev.java.net/ should work, or hook up a servlet filter to your servlet that records all parameters.
Lester Burnham wrote:Sounds like a question for the tech support people of the bank.
Don't they provide working example code?
Lester Burnham wrote:That's where an HTTP monitor/proxy comes in handy - it can tell you the differences between what the PHP version sends and what the Java version sends.
You mean Java and PHP is generating different versions?
Lester Burnham wrote:
You mean Java and PHP is generating different versions?
I don't know - that's for you to find out. But since the Java version doesn't work -and the PHP version presumably does-, it seems logical to assume that there must be some differences. Have you gotten the PHP version to run successfully? If not, then that would be a good place to start.
Lester Burnham wrote:
Next thing you need to do is to make your web app submit to 127.0.0.1:8180 instead of the bank URL, and you need to set the server name and port to the correct values of the bank URL.
error HTTP Status 404 - /127.0.0.1:8180/servlet/PaymentManager
Lester Burnham wrote:That URL looks incorrect - pay particular attention to the details.
Lester Burnham wrote:So: are those requests byte for byte identical?
Farakh khan wrote:I just want to clear my concepts. when the password parameter sent then md5 encrypted the password and displayed as hash in the user URL and when the server gets how it understand by decrypting.
Always! Wait. Never. Shut up. Look at this tiny ad.
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|