Ok after experimenting a little bit I found out that resin was calling my AbstractAuthenticator implementation "authenticate" method that takes an HttpDigestCredentials object instead of DigestCredentials (still don't know when is called each one of them) the problem is that HttpDigestCredentials doesn't have a getDigest() method, instead it has a getResponse() method which doesn't return a hash or at least not a comparable one.
After creating my own hash of [[user:realmassword] [nonce] [method:uri]] the hash is very different, in fact I think getResponse() does not return the digest but maybe the server response to the browser?.
Any way this is my debugging log :
USER:user:PASSWORD:password:REALM:resin:METHOD:GET:URI/appe/appe.html:NONCE:HsJzN+j+GQD:CNONCE:b1ad4fa1ba857cac88c202e64528bc0c:CLIENTDIGEST:[B#5dcd8bf7:SERVERDIGEST:I4DkRCh21YG2Mk14iTe+hg==
as you can see both the supposed client nonce is very very different from the server generated nonce, in fact the client nonce doesn't look like a MD5 hash at all.
Please has someone does this before? is there something missing in the HttpDigestCredentials? I know digest is barely used.
Please, I know about SSL but I can't have an SSL certificate just yet so don't tell me "Why don't you use SSL". ;)
Update:
Not sure if was the right thing to do but, as I read before Resin uses base64 format for hashes so I used apache commons-codec-1.6 to use encodeBase64String() method and now the hashes look alike but they are no the same.
I tried both passwordDigest.getPasswordDigest(a1+':'+nonce+':'+a2); passwordDigest.getPasswordDigest(a1+':'+nonce+':'+ncount+':'+cnonce+':'+qop+':'+a2);
and none of them gives the same hash as the one from HttpDigestCredentials.
Ok I finally made it . Weird subject Huh, only two views?
First, digest authentication makes use of user, password, realm, nonce, client_nonce, nonce_count, method, qop, and uri. Basically it uses the full digest spec. So in order to calculate the hash one must calculate it with all the whistles. Is just a matter of calling the get method for each one of the variables from HttpDigestCredentials except for user and password. The user will come in the form of a Principal and the password you must look for it yourself in your DB (in my case a DB4O database).
Then you must create a PasswordDigest object, that will take care of generate a hash with the getPasswordDigest() method, but first one must set the format to hex with passwordDigestObject.setFormat("hex").
There is one for the HA1 getPasswordDigest(user,password,realm) and there is another getPasswordDigest() method that takes just one string and one can use it to generate the rest of the hashes, both HA2 and with the previous hashed HA1 the final hash, of course with the nonce nonce_count client_nonce and qop, of course each one separated by a semicolon.
Then it comes the tricky part, although resin works with base64 encoding for digest when you call the getResponse() method from HttpDigestCredentials it returns a byte array (which is weird) so in order to compare it with your hash what I did was use the Hex.encodeHexString() method from org.apache.commons.codec.binary.Hex and pass the HttpCredentialsDigest getResponse() return value, and that will give a nice hex String to compare.
I was doing it the other way around, I was using the Base64 hash from PasswordDigest and converting the HttpDigestCredentials hash to Base64 and the resulting string were never the same.
Related
(Update: still stuck after changes made from John's comment)
I am hoping for somebody to kindly try to explain in layman's terms how the signature is generated in the following example? I am pretty much stuck at this point.. I get the same result in an online hash generator (see picture below) and in my own code; but it differs from the example in the website (also pictured below).
https://www.gate.io/docs/apiv4/en/#authentication
edit: website seems only reachable through google search, direct link gives 404? So I attached the page as image, see below
Request: List all orders
GET /api/v4/futures/orders?contract=BTC_USD&status=finished&limit=50
HTTP/1.1
secret:
secret
resulting signature string (edit: updated, thanks #John Glenn)：
GET\n/api/v4/futures/orders\ncontract=BTC_USD&status=finished&limit=50\ncf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e\n1541993715
(note that in the example on the website, there are line breaks for readability)
Signature generated according to the example:
eae42da914a590ddf727473aff25fc87d50b64783941061f47a3fdb92742541fc4c2c14017581b4199a1418d54471c269c03a38d788d802e2c306c37636389f0
Explanation from the website:
Signature generation method is HexEncode(HMAC_SHA512(secret,
signature_string)), i.e., the hexadecimal digest output of HMAC-SHA512
with APIv4 secret as secret and signature string as message.
But if I put it into a HMAC-SHA512 generator (e.g., https://www.javainuse.com/hmac), the value I get is:
58000238bf5eef226028e108df259184f14bf3021eb27c324a808334d187da42c38f4510b30215ee9b0c05d6352396e99f67fa920079746bb4dfd70506592f6d
I suspect I am missing a very essential point but I am quite lost at this time..
thank you very much for your help!
Your resulting signature string is incorrect. According the to website, this is how you should build it, with each element separated by \n.
request verb
request URL
plain text query string from the URL
hash of the request body, which is an empty string in this case
the Unix timestamp in seconds
For your example, the resulting signature string values should be:
GET (but you have POST)
/api/v4/futures/orders
contract=BTC_USD&status=finished&limit=50 (MISSING from your string)
just use the empty string hash value from the example
use the Unix timestamp from the example
Solved!
The "\n" were not regular expressions but actual newlines in the example. In other words, the newlines should be entered as ascii newline character.
Then I got the same result in the generator as from the website.
I am investigating the CyberSource REST API and want to test the JSON Web Token Authentication method as documented here: https://developer.cybersource.com/api/developer-guides/dita-gettingstarted/authentication/GenerateHeader/jwtTokenAuthentication.html
I am unable to replicate the sha256 hash of the JSON payload described in the JWT Payload/Claim Set section.
{
"clientReferenceInformation" : {
"code" : "TC50171_3"
},
"orderInformation" : {
"amountDetails" : {
"totalAmount" : "102.21",
"currency" : "USD"
}
}
}
I've attempted to use the sha256sum command in binary and text format on a file containing the payload example. I've also attempted running this command on different permutations of this payload, such as without whitespace or newlines.
I expect to get the example hash of
2b4fee10da8c5e1feaad32b014021e079fe4afcf06af223004af944011a7cb65c
but instead get
f710ef58876f83e36b80a83c8ec7da75c8c1640d77d598c470a3dd85ae1458d3 and other dissimilar hashes.
What am I doing wrong?
Since the alleged "example" hash contains 33 hex characters one can see that it is not a possible valid output of SHA256. So there is nothing you can do to make your example match theirs.
There is also a base64 example in that discussion, but it is also not valid base64. By adding an extra padding character '=' to the base64 it can be made valid, and decoding it reveals that it mostly matches the alleged SHA256 hash.
My guess is that the values on that page are just examples of what values look like to the human eye rather than test vectors you are supposed to match exactly.
Probably you are not doing anything wrong. Hash functions have a avalanche effect, wherein any different bit in the input changes a lot the output hash. If the site's original example used a different encoding, or had a different order for the JSON elements, or even had more or less tabs, spaces, line breaks, or any other "trash" character, you'll have a hard time to find a fitting message for the hash showed in the site.
Usually, cryptographic solutions use canonicalizations to avoid this kind of problem (different hash values for semantically equal messages). However, the JWT specification doesn't specify any type of canonicalization for JSON.
In short, I think you don't have to worry about this. Your JWT implementation will be correct as long you use a valid (correctly implemented) hash function.
Also, I noticed that the JWT specification doesn't specify a "Digest" field for the JWT payload. So, you may not even need to use this field. Unless CyberSource REST API makes it mandatory.
I have implemented this http://jacob.jkrall.net/totp/ in vbscript.
My code given the same hex gives the right 6-digit otp, so that part is working.
I've also verified the HMAC-SHA-1. encoding against an online generator, http://www.freeformatter.com/hmac-generator.html#ad-output, same input gives same output.
My time is the same as http://www.currenttimestamp.com/
I've generated a qrcode at http://www.qr-koder.dk/ with the string otpauth://totp/$LABEL?secret=$SECRET and the google authenticator app reads the code and starts outputting the 6 digit code changing every 30 seconds.
BUT THE CODES FROM THE APP DOES NOT MATCH THE 6-DIGIT CODE THE VBSCRIPT GENERATES!
I've even tried trunc(time/30) +/-7500 steps to see if it was a timezone/daylight saving problem, to no avail.
As the other parts of the routine to generate the 6 digits seem to work I've come to the conclusion I don't understand this:
the url on the qr-code is
otpauth://totp/$LABEL?secret=$SECRET
with the explanation
LABEL can be used to describe the key in your app, while SECRET is the
16-character base32-encoded shared secret, which is now known to both
the client and the server.
So when I calculate HMAC-SHA-1(SECRET, time()/30)
should the SECRET be the same string given to both the app and the calculation?
If I select a secret of 1234567890, the base32 is GEZDGNBVGY3TQOJQ according to http://emn178.github.io/online-tools/base32_encode.html.
Should I then take
HMAC-SHA-1("1234567890", time()/30)
or
HMAC-SHA-1("GEZDGNBVGY3TQOJQ", time()/30)
?
I believe I've tried both, and neither works.
The system unix time is correct.
I guess the problem might be with the secret in your HMAC-SHA-1 function. It very much depends on what the HMAC-SHA-1 expects.
Your string "123456790" might be a binary string. Is it an ascii representation or utf8? I.e. is this string 10 bytes or 20 bytes long?
I recommend getting the input string in your VBScript right.
On the other hand, instead of writing your own VBScript, you can also use a ready made solution like the privacyIDEA authentication server, which is open source and also comes with TOTP.
I'm try to understand how the Certificated works in the https protocol.
With wireshark, I can capture the certificates, first,I export the singedCertificate, and calculate the hash value; Second, I export the encrypted data, and decrypt it with the public key, the result should equal to the hash of signedCertificate.
This is an example of the decryption:
3021300906052b0e03021a05000414a1038465d47c003d8540ec33879f86e24c43b21a
I found that "a1038465d47c003d8540ec33879f86e24c43b21a" equal to the hash of the signedCertificate, but the head "3021300906052b0e03021a05000414" seemed something relates to the method of hash and encryption.
So, my question is,what's the format of this "a1038465d47c003d8540ec33879f86e24c43b21a".
finally I solve this question.
It's so easy, open the file with wireshark, then everything looks fine.
How to encrypt a nsstring and store it in a file, and how to decrypt the same.
Please suggest me wat api's i shld use...
This is the function i used for encryptiong.
DES_cfb64_encrypt( ( unsigned char * ) pchInputData, ( unsigned char * ) pchOutCipher,
size, &schedule, &ParityKey, &no, DES_ENCRYPT );
I had to convert this to base64 so that i can store it in a file.
pstrResult = Base64encoding(size,( unsigned char * )pchOutCipher);
You can use gpgme
If you only need to support 10.5 or higher you can use the CommonCryptor API. The first comment to this post shows an example category for encrypting/decrypting NSData's:
http://iphonedevelopment.blogspot.com/2009/02/strong-encryption-for-cocoa-cocoa-touch.html
While not an API call, you could implement a simple XOR cipher. This is quick and simple to implement and depending on the characteristics of your string (i.e. if it is of fixed length) can be very secure. If you have a variable length string XOR encryption may not be secure enough depending on your needs. Have a look at the Wikipedia article.
If you are storing a password first decide whether or not you need to re-use the password or whether you just need to check that the user has entered the correct password.
If you just need to verify that the user has entered the correct password, then store the password using a hash, and compare the hash of the user input with the hash you have stored. If both hashes are equal, then the user has [probably] typed it correctly. See more information about hashes at Wikipedia.
If you need to re-use the password (i.e. for authenticating with other services, such as connecting to an Internet service), use Apple's Keychain service. If you are targeting the iPhone, then check out this related document.