In the moment I'm struggling a little bit with the generation of HMAC for Amazon MWS.
I thought I understood how it works.
With the Scratchpad I generated a request. Scratchpad shows the string to sign and also the SHA 256 HMAC and the Base64 HMAC.
The string to sign consists of 4 lines like it's described in the docu.
There are several Onlineconverter for HMAC. I tried:
https://www.freeformatter.com/hmac-generator.html
https://codebeautify.org/hmac-generator
When I convert the string to sign which Scratchpad generated (the 4 lines), I get an other SHA 256 HMAC then Scratchpad generated.
Also there are several Onlineconverter for Base64. I tried:
https://www.freeformatter.com/base64-encoder.html
https://www.base64encode.org
When I convert the SHA 256 HMAC which Scratchpad generated, I get an other Base64-String then Scrathpad generated.
This confuses me. What I don't understand?
Other point:
Later I think I want to use GET and not POST. Do I get this right, that the string to sign for GET also has to be in 4 lines and not in one line as it would be executed later? That's how I understand the docu.
I used these links:
http://docs.developer.amazonservices.com/en_US/dev_guide/DG_QueryString.html
http://docs.developer.amazonservices.com/en_US/dev_guide/DG_SigningQueryRequest.html
https://mws.amazonservices.com/scratchpad/index.html
To answer my own questions.
Generate SHA256 with an Onlineconverter:
I suppose the Problem is the LF. The Onlineconverter maybe have problem with it. Maybe they use CRLF. Better don't try to check your SHA256 with Onlineconverters.
Generate base64 with an Onlineconverter:
The SHA256 Scratchpad shows is not the value you convert with base64. You have to convert the Hex-Value of the SHA256.
Query to sign with GET:
If you want to use GET, the query to sign has to look like the query to sign for POST. Also the four lines. Only swap POST with GET.
Related
I need to build a XMPP client. The server PLAIN mechanism to auth. (using zlib compression I think)
I captured trafic from other xmpp system thats use PLAIN mechanism and the text appear to be Base64 (id + token) ADc1Y2M2OWY0MzQwMTUwMjgyOWIwMWY2MDAyN2E0NDE2ADE1YTk0NzM3NTRiYjY2MGExMGYzYTA5MzA5NWQxMmY3 is what the client return. I put that into a Base64 decoder and its give me this : 75cc69f43401502829b01f60027a441615a9473754bb660a10f3a093095d12f7.
When I encode this using a Base64 encoder, Its give me something else than the first Base64 string (NzVjYzY5ZjQzNDAxNTAyODI5YjAxZjYwMDI3YTQ0MTYxNWE5NDczNzU0YmI2NjBhMTBmM2EwOTMwOTVkMTJmNw)
Can someone explain me? I couldn't find anything on google.
Edit:
https://xmpp.org/extensions/xep-0034.html#example-3
the result of your decoding is not correct, in fact the decoded value
contains two binary values that can't be displayed as a character
(here substituted by a �):
�75cc69f43401502829b01f60027a4416�15a9473754bb660a10f3a093095d12f7.
What you encoded then is based on a string in which the two binary
values are not present, so you encoded basically something different
and got of course a different result.
From jps
I am trying to take a plaintext password and hash it for comparison to password hashes stored in FreeBSD's /etc/master.passwd. My goal is to have a node.js program able to authenticate against the master.passwd database using existing account credentials.
I've set up a FreeBSD account, called test1. I gave it a password of "password". Looking at master.password, I see this in the password field:
$6$nEIifU2XZ9VDx3l5$RUW0Udy60Hon9OsoTAz8DcH0uvZ4E3p5CXFScrC694EF1Cpkf8/5GUtC750NZXnMFYZsMlBZE52INFlBUvWMb0
My understanding is that the $ characters act as delimiters for three fields:
The hash algorithm (6 being SHA512)
The salt, base64 encoded.
The salted password hash, base64 encoded.
I tried to replicate the hashing algorithm in Node.js like this:
const crypto = require("crypto");
let passwordPlain = "password"
let salt64 = "nEIifU2XZ9VDx3l5"
let salt = Buffer.from(salt64, "base64");
let passwordHashed = crypto.scryptSync(salt, passwordPlain, 64);
let passwordHashed64 = passwordHashed.toString('base64');
console.log(`$6$${salt64}$${passwordHashed64}`);
I would have expected to see my plain-text password of "password" hashed with the salt and displayed to match what's in master.password. What I got was very different.
$6$nEIifU2XZ9VDx3l5$Y9/0OCikTExQlo0lLp5FVK6DuANVx7BOXZ/spLvTyFvJstUVpJGeanqE+U6Uca63PagSiGNDfMbg35MpTUT/dQ==
I've tried passing the salt without base64 decoding. I've tried including the $ delimiters as part of the salt. I even tried Hmac instead of scrypt. Nothing works.
I'm beginning to wonder if it's not base64 encoded. The document that suggested it was is fairly dated, mentioning only MD5 hashing. Also, I would expect to see at least some base64 padding with equal signs in my master.passwd and I don't. Finally, I came across an example on the FreeBSD website that shows a password hash with a dot in it, and as far as I know that's not part of the base64 set of characters. (Only letters, digits, and + /)
I'm also thinking about Node.js scrypt() vs. FreeBSD crypt(). It was the closest thing I could find and when I use the default key length of 64 and remove the two padding characters, the base64 encoded length is a perfect match for the length of what's in master.passwd. But still, the hashes are very different.
I'm hoping someone can shed some light on things as I have come to the limit of my internet searching skills on this one.
Links to reseached pages:
https://stackoverflow.com/questions/34810547/what-is-freebsd-md5-and-why-does-it-produce-hashes-in-non-hexadecimal-notation?r=SearchResults&s=1|51.4889
https://www.freebsd.org/doc/handbook/security-intro.html
sha512crypt-node is a NodeJS implementation of the SHA512-based crypt implementation. The following code provides the desired hash:
const crypt = require('sha512crypt-node')
const hash = crypt.b64_sha512crypt('password', 'nEIifU2XZ9VDx3l5')
console.log( hash ) // $6$nEIifU2XZ9VDx3l5$RUW0Udy60Hon9OsoTAz8DcH0uvZ4E3p5CXFScrC694EF1Cpkf8/5GUtC750NZXnMFYZsMlBZE52INFlBUvWMb0
Further usage examples can be found here.
sha512crypt-node and also the SHA512 part of the FreeBSD implementation of crypt are based on the algorithm described here, see also [1][2].
crypto.scrypt (or crypto.scryptSync) from NodeJS is based on the scrypt algorithm described here, see also [3][4]. Ultimately, these are different algorithms, so that matching hashs cannot be expected.
This article here compares various algorithms including scrypt and the SHA512 part of crypt and should be of interest to you, especially with regard to security.
I am using the GitHub API to download a file from GitHub. I have been able to successfully authenticate as well as get a response from github, and see a base64 encoded string representing the file contents.
Unfortunately, I get an unusual error (string length is not a multiple of 4) when decoding the base64 string.
The HTTP request is illustrated below:
GET /repos/:owner/:repo/contents/:path
The (partial) response is illustrated below:
{
"name":....,
"download_url":...",
"type":"file",
"content":"ewogICAgInN3YWdnZXIiOiAiM...
}
The issue I am encountering is that the length of the string is 15263 bytes, and I get an error in decoding the string (string length is not a multiple of 4). I am using node.js and the 'base64-js' npm module to decode the string. Code to execute the decoding is illustrated below:
var base64 = require('base64-js');
var contents = base64.toByteArray(fileContent);
The decoding causes an exception:
Error: Invalid string. Length must be a multiple of 4
at placeHoldersCount (.../node_modules/base64-js/index.js:23:11)
at Object.toByteArray (...node_modules/base64-js/index.js:42:18)
:
:
I would think that the GitHub API is sending me the correct data, so I figure that is not the issue.
Am I performing the decoding improperly or is there another problem I am overlooking?
Any help is appreciated.
I experimented a bit and found a solution by using a different base64 decoding library as follows:
var base64 = require('js-base64').Base64;
var contents = base64.decode(res.content);
I am not sure if it is mandatory to have an encoded string length divisible by 4 (clearly my 15263 character length string is not divisible by 4) but the alternate library decoded the string properly.
A second solution which I also found to work is specific to how to use the GitHub API. By adding the following to the GitHub API call header, I was also able to get the decoded file contents:
'accept': 'application/vnd.github.VERSION.raw'
After much experimenting, I think I nailed down the difference between the working and broken base64 decoding.
It appears GitHub Base-64 encodes with:
UTF-8 charset
Base 64 MIME encoder (RFC2045)
As opposed to a "basic" (RFC4648) Base64 encoder. Several languages seem to default to the basic encoder (including Java, which I was using). When I switched to a MIME encoder, I got the full contents of the file un-garbled. This would explain why switching libraries in some cases fixed the issue.
I will note the contents field contained newline characters - decoders are supposed to ignore them, but not all do, so if you still get errors, you may need to try removing them.
The media-type header will do the job better, however in my case I am trying to use the API via a GitHub App - at time of writing, GitHub requires a specific media type be used when doing that, and it returns the JSON response.
For some reason the Github APIs base64 encoded content doesn't decode properly at all the online base64 decoders I've tried from the front page of google.
Python works however:
import base64
base64.b64decode("ewogICAgInN3YWdnZXIiOiAiM...")
Hi Im fairly new to base64 code and could do with some info/help etc. I have recently used it while converting my photos into code as part of an experiment regarding my sculptures, I converted a photo into 152 pages of base 64 using an online converter, just to get started. I was wondering how I can reverse this, and also if I edited out some code would the image change or would it not convert at all!? Like I said I am interested in using this to help my experiments. thanks for any info .
Base64 decode functions will decode it. If you remove some of the base64 code it may not translate back into a valid image or translate into valid base64 code at all depending on how much you remove. Depending on how the image was originally compressed, it MAY give you something, but the results will be incredibly unpredictable... So you'll never know what the result of the change will be on the final product. Part of the base64 standard involves a padded width (which is why some strings end in up to 2 = signs).
I am trying to decrypt a hashed string using
Security::cipher($strHashedPassword, Configure::read('Security.salt'));
doesn't seem to be giving the desired result. Does anyone have any experience with this? From the docs it looks like this should work.
Please note that you cannot decrypt a hashed string. Hashes are irreversible by definition. They can't be decrypted because they're not encrypted to begin with, they're hashed. If you're really trying to decrypt a password hash (as produced by the AuthComponent?) you're out of luck.
Security::cipher can only decrypt strings that it encrypted as well, in which case you'd be talking about a cipher text, not a hash.
If you can demonstrate that this doesn't print "test":
$cipherText = Security::cipher('test', Configure::read('Security.salt'));
echo Security::cipher($cipherText, Configure::read('Security.salt'));
you have found a bug in Cake, most likely the one linked to by #infinity. Otherwise, you're trying something impossible.
Hi have a look at CakePHP forum:
http://cakephp.lighthouseapp.com/projects/42648/tickets/471-securitycipher-function-cannot-decrypt