Java Digest Hash and PHP Hash are different - java

I'm trying to authenticate a webhook from starling bank on a PHP 7.0.22 (Apache/2.4.6 (Red Hat Enterprise Linux)) server.
I've been told by support that the following java code is being used to generate the digest
private String calculateSignature(String sharedSecret, String requestJson) {
try {
String contentToDigest = sharedSecret + requestJson;
MessageDigest messageDigest = MessageDigest.getInstance("SHA-512");
byte[] digest = messageDigest.digest(contentToDigest.getBytes());
return Base64.getEncoder().encodeToString(digest);
} catch (NoSuchAlgorithmException e) {
throw new RuntimeException("Error calculating digest for payload [" + requestJson + "]", e);
}
}
The sharedSecret I already have and the requestJson I take from the webhook POST using:
$requestJson=file_get_contents('php://input') ;
my php code to generate the hash is as follows:
$concatenated_string=$sharedSecret . json_encode($requestJson) ;
$generated_hash=base64_encode(hash('sha512', $concatenated_string ));
This doesn't give the same hash. Whilst hacking to try and find an answer, I've also tried the following :
$concatenated_string=$sharedSecret . $requestJson ;
and different hash types and options:
$generated_hash=base64_encode(hash('sha512', $concatenated_string, true ))
$generated_hash=base64_encode(openssl_digest($concatenated_string, 'sha512')) ;

base64_encode and hash are effectively doing the same thing in this case:
https://stackoverflow.com/a/11195855/3323777
You should specify third argument as TRUE at your php code to match the java version:
raw_output - Setting to TRUE will return as raw output data, otherwise the return value is binhex encoded.
http://php.net/manual/ru/function.openssl-digest.php
I've ran your both snippets on java and php and found not difference when encoding a string "test". I advise you to output the json payloads to two files on both environments and use diff to compare them.

Related

Generating a dynamic password reset link

To reset my password I want to send the user a link to site/account/{hash} where {hash} is a hash of the user's password and a timestamp.
I have the following code to hash only the email and have a readable link:
String check = info.mail;
MessageDigest md = MessageDigest.getInstance("SHA-1");
String checkHash = Base64.encodeBase64String(md.digest(check.getBytes()));
if(checkHash.equals(hash)){
return ResponseEntity.ok("Password reset to: " + info.password);
}else{
return ResponseEntity.ok("Hash didn't equal to: " + checkHash);
}
The problem is that when I convert this to Base64 it may include / signs what will mess up my links and checking of the hash.
I can simply replace any unwanted signs by something else after the hashing but is there some other way to have your hash only include a certain part of codes?
Also I know the returns are still sent unsafe but this is just for testing and debugging.
The RFC 3548 specifies a variant often called "base64url" specifically designed for that purpose. In this variant, + and / are replaced by - and _.
Java 8 has built-in support with the new Base64 class. If you're stuck with an older version, the Base64 class of Apache Commons can be configured to be url safe by using the new Base64(true) constructor.
Other options might be:
Don't use Base64, but transfer the bytes as hexadecimal
representation (which will not contain any special characters):
String checkHash = toHex(md.digest(check.getBytes()));
with
private static String toHex(byte[] bytes) {
StringBuilder sb = new StringBuilder();
for (byte b : bytes) {
sb.append(String.format("%02X", b));
}
return sb.toString();
}
Use URL encoding/decoding on the generated hash (that's what you already know)

SHA1 sum on multilanguage strings

I have an android app that comminicates with a nodejs server via http.
To each request I add a SHA1 checksum that iterates over the key value pairs I'm sending to the server so that it would validate it on arrival.
I have tested this and it works okay as long as the values I'm sending are in English. Sending a request that contains a string value in Hebrew for example or that includes an unstandard character (like é, ç or à) will fail the request base on a checksum mismatch.
The checksum is calculated first in the andoird client (JAVA) and than in the nodejs server for verification.
I eliminated the possibility that this is caused due to the Right To Left nature of the Hebrew language by sending a single letter value, and it still failed.
What could cause this? I assume this might be because the encoding of a JAVA string for non standard characters is different from that of nodejs. But how can I solve this?
Here is the relevant code from the server side:
var shasum = crypto.createHash('sha1');
while (fieldsPointer < allFields.length
|| filesPointer < allFiles.length) {
shasum.update(fieldKey);
let fieldKey = allFields[fieldsPointer];
shasum.update(fieldKey);
let fieldValue = fields[allFields[fieldsPointer]];
shasum.update(fieldValue);
}
and the client side:
try {
MessageDigest md = MessageDigest.getInstance("SHA-1");
for(Entry<String, Object> entry : allParams.entrySet()) {
md.update(entry.getKey().getBytes());
if(entry.getValue() instanceof String) {
String value = (String) entry.getValue();
md.update(value.getBytes());
} else (...) // some other instance checking for non String values
}
String checksum = bytesToHex(md.digest());
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
I did some research based on Williams's comment.
It turns out all I need to do was to change this:
shasum.update(fieldValue);
to this:
shasum.update(fieldValue, 'utf8');
as stated in the nodejs crypto documentation for hash encoding: http://nodejs.org/api/crypto.html#crypto_hash_update_data_input_encoding
While this works, it is also a good idea to state the charset in the client side, as William stated in the comment below.
I did this by changing this:
md.update(value.getBytes());
to this
md.update(value.getBytes("utf8"));

Java and Php returns different hashes

So, PHP code:
$result = hash("whirlpool","xxx".$password."zzz");
JAVA:
import gnu.crypto.Registry;
import gnu.crypto.hash.HashFactory;
import gnu.crypto.hash.IMessageDigest;
public class WhirlpoolHash {
String result;
WhirlpoolHash(String pass) {
String to_encode = "xxx"+pass+"zzz";
IMessageDigest old_encoder = HashFactory.getInstance(Registry.WHIRLPOOL_HASH);
byte[] input = to_encode.getBytes();
old_encoder.update(input, 0, input.length);
byte[] digest = old_encoder.digest();
this.result = gnu.crypto.util.Util.toString(digest).toLowerCase();
}
public String Get() {
return this.result;
}
}
And the result vars are different. I need java class to return the same value as php does.
I have passwords stored in MySQL DB UTF-8 encoded generated by PHP and need to compare it with data sent by JavaFX app.
Of course i can send unencrypted password, and do it with php but I dont whant to.
So Java example for encrypting pwd with whirlpool algorithm using gnu-crypto jar was an answer.
I dont know why but jonelo.jacksum.JacksumAPI gives the result same as PHP.
Late response, but in case it helps someone else.
I had almost the exact same issue and used Bouncy Castle in Java. After some trial and error, I got the hashes with Whirlpool to match my PHP hash, which looked similar to yours. Assuming you pass in the password:
WhirlpoolDigest messageDigest = new WhirlpoolDigest();
final String convertedHash = "xxx" + password + "yyy";
messageDigest.reset();
final byte[] bytes = convertedHash.getBytes();
messageDigest.update(bytes, 0, bytes.length);
byte[] hash = new byte[messageDigest.getDigestSize()];
messageDigest.doFinal(hash, 0);
System.out.println(Hex.toHexString(hash));
The biggest issue for me was the final steps - the doFinal() and the Hex.toHexString() ...
My maven dependency looked like this:
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-ext-jdk15on</artifactId>
<version>1.64</version>
</dependency>

Why encrypted and base64 encoded text appears different on Windows and Linux

I have a legacy system that uses hibernate interceptor to encrypt (and encode) and decrypt (and decode) some fields on some database tables. It makes use of the OnSave, OnLoad and OnFlushDirty methods. This code turns out to be buggy as data read from this system, when transferred to another application still has some of the records encrypted and encoded (some encrypted multiple times). The challenge for me here is that I could perform the decryption and decoding (as many times as necessary) when the receiving application is on a Windows machine. I get a BadPaddingException when I try to repeat the same thing when the receiving application is a linux VM.
Any help/suggestions will be greatly appreciated
here is a snippet of the hibernate interceptor
public boolean onLoad(Object entity, Serializable arg1, Object[] state, String[] propertyNames, Type[] arg4) throws CallbackException {
if (key != null){
try {
if (entity instanceof BasicData) {
for (int i = 0; i < state.length; i++) {
if (state[i] instanceof String){
String cipherText = (String)state[i];
byte[] cipherTextBytes = Base64Coder.decode(cipherText);
byte[] plainTextBytes = dCipher.doFinal(cipherTextBytes);
state[i] = new String(plainTextBytes, "UTF8");
}
}
return true;
}
} catch (Exception e) {
e.printStackTrace();
}}return false;}
I'd have to guess here but if you mean this Base64Coder the problem might be the following:
It is unclear how the base64 string has been created, i.e. which encoding had been used.
If you use UTF-8 to get the bytes of a string and create a base64 from those bytes you'll get a different result than if you'd use ISO Latin-1, for example.
Afterwards you create a string from those bytes using UTF-8, but if the base64 string had not been created using UTF-8, you'll get wrong results.
Just a quote from the linked source (if this is the correct one):
public static String encodeString (String s) {
return new String(encode(s.getBytes())); }
Here, s.getBytes() will use the system's/jvm's default encoding, so you should really ensure it is UTF-8!
If you control both sides, encode and decode, better way to use DatatypeConverter:
String buffer = DatatypeConverter.printBase64Binary( symKey );
byte[] supposedSymKey = DatatypeConverter.parseBase64Binary( buffer );

java decoding base64 String

I realise this is probably more of a general java question, but since it's running in Notes\ Domino environment, thought I'd check that community first.
Summary:
I don't seem to be able to decode the string: dABlAHMAdAA= using lotus.domino.axis.encoding.Base64 or sun.misc.BASE64Decoder
I know the original text is: test
I confirmed by decoding at http://www5.rptea.com/base64/ it appears it is UTF-16.
As simple test, using either of below:
String s_base64 = "dABlAHMAdAA=";
byte[] byte_base64 = null;
String s_decoded = "";
byte_base64 = new sun.misc.BASE64Decoder().decodeBuffer(s_base64);
s_decoded = new String(byte_base64, "UTF-16");
System.out.println("Test1: " + s_decoded);
byte_base64 = lotus.domino.axis.encoding.Base64.decode(s_base64);
s_decoded = new String(byte_base64, "UTF-16");
System.out.println("Test2: " + s_decoded);
System.out.println("========= FINISH.");
I get the output:
Test1: ????
Test2: ????
If I create String as UTF-8
s_decoded = new String(byte_base64, "UTF-8");
it outputs:
t
no error is thrown, but it doesn't complete the code, doesn't get to the "FINISH".
Detail
I'm accessing an asmx web service, in the SOAP response, some nodes contain base64 encoded data. At this point in time, there is no way to get the service changed, so I am having to XPath and decode myself. Encoded data is either text or html. If I pass the encoded data thru http://www5.rptea.com/base64/ and select UTF-16, it decodes correctly, so I must be doing something incorrectly.
As side note, I encoded "test":
s_base64 = lotus.domino.axis.encoding.Base64.encode(s_text.getBytes());
System.out.println("test1 encodes to: " + s_base64);
s_base64 = new sun.misc.BASE64Encoder().encode(s_text.getBytes());
System.out.println("test2 encodes to: " + s_base64);
they both encode to:
dGVzdA==
...which if you then feed into 2 decoders above, as expected, decodes correctly.
If I go to site above, and encode "test" as UTF-16, I get: dABlAHMAdAA= so that confirms that data is in UTF-16.
It's like the data is genuine base64 data, but the decoder doesn't recognise it as such. I'm slightly stumped at the moment.
Any pointers or comments would be gratefully received.
The string has been encoded in UTF-16LE (little-endian), where the least significant byte is stored first. Java defaults to big-endian. You need to use:
s_decoded = new String(byte_base64, "UTF-16LE");
i have used your sample "dABlAHMAdAA=" on my base64 decode online tool and it seems like you are missing the Apache base64 jar files
Click the link below.
http://www.hosting4free.info/Base64Decode/Base64-Decode.jsp
The code behind the website is
import org.apache.commons.codec.binary.Base64;
public class base64decode
{
public static void main(String[] args) throws UnsupportedEncodingException
{
byte[] decoded = Base64.decodeBase64("YWJjZGVmZw==".getBytes());
System.out.println(new String(decoded) + "\n");
}
}

Categories

Resources