In this sample from Ktor website https://ktor.io/samples/feature/auth.html they use an account "test" with password "test" as example.
#UseExperimental(KtorExperimentalAPI::class)
val hashedUserTable = UserHashedTableAuth(
getDigestFunction("SHA-256") { "ktor${it.length}" },
table = mapOf(
"test" to Base64.getDecoder().decode("GSjkHCHGAxTTbnkEDBbVYd+PUFRlcWiumc4+MWE9Rvw=") // sha256 for "test"
)
)
I need to create another entry, but I can't figure out how they got that hash. I tried to sha256 the word "test", salted or not, tried to base64 the result... Nothing matches that hash so I'm unable to create another user.
Anyone could enlighten me here on how to create a compatible hash with that code?
After a lot of try and errors... Here's how to duplicate that:
echo -n ktor4test | openssl dgst -binary -sha256 | openssl base64
I hope this helps someone in the future not to waste the same time as myself.
Related
I am trying to learn John. I've been through the FAQ and this tutorial, but am stuck.
I have made a RAR4 password hash. It's super simple. The password is 'test'. I now want to use a tool to crack it.
I've saved it to a file "test.txt".It has:
Red dead redemption.rar:$RAR3$*1*de613099dc859cfd*00000000*16*0*1*b52125c28c4fc60a1c00f313d0fb68ca*33:1::Red dead redemption.torrent
When running the following command, I get 'No password hashes loaded'
What should I do to get this working please?
Command: john.exe test.txt
$$ in your hash specify that they are encrypted with yescrypt, Hence you need to specify format to the john
john.exe --format=crypt test.txt
This should work
I am creating a "change password" form where the user is required to enter the previous password first, then a new password (twice).
I should compare the entered "previous password" to the one already stored.
My web application uses an LDAP server to store user credentials. Password is apparently stored using SHA.
So what I do is get the previous password entered by the user, digest it using SHA1, then compare it.
String oldPass = request.getParameter("oldpass");
String enteredOldPass= App.getInstance().getCipher().cipher(oldPass);
String ldapPassword= ctx.get("userpassword");
But this isn't working, because the passwords are different. When I store "test" in the LDAP I obtain {sha}qUqP5cyxm6YcTAhz05Hph5gvu9M= when calling .get("userPassword"), whilst I get a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 when hashing "test" by myself.
What am I doing wrong here? It seems that a step is missing since my result is purely hex, while the one I get from the LDAP is ASCII. But I tried converting the string to hex (using string to hex online converters) but the result is still differnet.
You don't do any of this.
You attempt to rebind as the user with that password. It either succeeds or fails. That tells you whether it was right or wrong. The API and protocol and server will take care of any hashing required.
Or, if you're using an LDAP server that supports the extended change-password operation, you provide the old and new passwords in the extended operation.
you must convert to binary, then convert to base64. Try this:
echo -n "test" | sha1sum | awk '{print $1}' <br>
The result will be a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
echo -n "test" | sha1sum | awk '{print $1}' | xxd -r -p | base64
The result will be qUqP5cyxm6YcTAhz05Hph5gvu9M=
I am having trouble properly setting headers for the Bitfinex API (https://www.bitfinex.com/pages/api). I have no trouble with the un-authenticated Get calls but I cannot get my authenticated Post calls working. An example call that I am working with is a Post to "/balances". I am hoping that somebody who uses the API can help me with what I am doing wrong. Here is some sample input and output (fake keys of course) that I am currently generating:
Private Key:
012345abcdef
API Key:
000111aaafff
Payload:
{"request": "/v1/balances","nonce": "1413737362"}
Base64 Payload:
e3JlcXVlc3Q6IC92MS9iYWxhbmNlcyxub25jZTogMTQxMzczNzM2Mn0=
Using the OpenSSL command:
echo -n 'e3JlcXVlc3Q6IC92MS9iYWxhbmNlcyxub25jZTogMTQxMzczNzM2Mn0=' | openssl dgst -hmac 012345abcdef -sha384 -hex
to get a signaure of
b18953370fad9bd5dd482d6ae07aeb96fdebd812e98cbf847f2d923bf66d1579eb31e10e1d79c7ae8405c54e28d0ae2a
So I get the Headers:
"X-BFX-APIKEY" "000111aaafff"
"X-BFX-PAYLOAD" "e3JlcXVlc3Q6IC92MS9iYWxhbmNlcyxub25jZTogMTQxMzczNzM2Mn0="
"X-BFX-SIGNATURE" "b18953370fad9bd5dd482d6ae07aeb96fdebd812e98cbf847f2d923bf66d1579eb31e10e1d79c7ae8405c54e28d0ae2a"
I have been trying everything I can think of and the responses I get from the API switch between "Invalid X-BFX-SIGNATURE." and "Invalid json.".
Where is the flaw in my process? I cannot see what I am doing incorrectly.
I was using a Unix system call to run the OpenSSL command. The result was returned in two lines, I was only reading the first line. Reading all lines until encountering and End of File solved the problem.
As the title says, I have both the signature and the private key and would like to know the string that generated the signature.
To sign my string I would do this:
$ echo 'data to sign' > data.txt
$ openssl dgst -sha1 -sign privateKey.pem -out data.sha1 data.txt
$ openssl enc -base64 -in data.sha1 -out data.b64 -A
And I end up with a 172 bytes signature.
What I would like to know is if there's a way to reverse the process.
Thank you.
You wont be able to do this. A Hash such as SHA1 is a one way type of encryption. Once the encryption is done its done and there is no going back.
Basically no, but if you know the string was relatively short and had some defined structure, you could brute force it until you get a matching hash value. For long and random strings it is impossible.
If I run the openssl command line in hmac mode (as below), is the key used for the hmac used directly or is it hashed before using it as the key?
echo "foo" | openssl dgst -sha256 -binary -hmac "test" | openssl base64
Similarly, when encrypting a file with openssl (as below)is the pass phrase hashed with the salt? (If so how is it done? A pointer to the right source file would be even better.)
openssl enc -salt
The hmac option does not use salting or hashing; it just uses the passphrase directly as the key. See apps/dgst.c in the source distribution:
else if (!strcmp(*argv,"-hmac"))
{
if (--argc < 1)
break;
hmac_key=*++argv;
}
...
if (hmac_key)
{
sigkey = EVP_PKEY_new_mac_key(EVP_PKEY_HMAC, e,
(unsigned char *)hmac_key, -1);
if (!sigkey)
goto end;
}
The enc command does seem to use some form of salting, at least in some cases. The relevant source file is apps/enc.c, but seems to come with some caveats:
/* Note that str is NULL if a key was passed on the command
* line, so we get no salt in that case. Is this a bug?
*/
if (str != NULL)
{
/* Salt handling: if encrypting generate a salt and
* write to output BIO. If decrypting read salt from
* input BIO.
*/
It then uses the function EVP_BytesToKey (in crypto/evp/evp_key.c) to generate a random key. This function seems to be a non-standard algorithm, which looked perhaps plausibly OK at a very brief glance but I couldn't attest to it beyond that.
Source snippets and comments are all from the OpenSSL 1.0.0 release.