When creating a password with sha1pass, the first value from the token, is '4'.
For instance:
sha1pass test
gives us:
$4$GTdnmykS$25iwV+ruXRwor4pUmKF57uXHj70$
The token uses $ as separators: 25iwV+ruXRwor4pUmKF57uXHj70 is the computed hash, GTdnmykS is the generated salt, since I didn't supply a second parameter, but what does that 4 mean?
The 4 is actually hardcoded, this is the last line of sha1pass, which is a Perl script:
print '$4$', $salt, '$', $pass, "\$\n";
Why is the first value of that token '4', and what does it mean?
It's just a signature so you know what you're looking at is a SHA-1 password; $1$ is used for MD5, $5$ for SHA-2-256, and $6$ for SHA-2-512.
I've seen the convention used where $1$ denotes MD5 and $4$ denotes SHA1. It's hardcoded because it's simply encoding how the hash was generated for future comparison.
It's a signature telling you the hash type is used, that much is obvious.
Now, why is is present? It's because it's used for unix password hashes, check crypt (Unix):
If the salt begins with the string $digit$ then the Modular Crypt Format is used. The digit represents which algorithm is used in encryption.
Related
When checking a file through signtool, I get one hash, and when decoding the certificate, another. What am I missing?
Command:
signtool verify /a /ph /pa /v .\EmptyExe.exe
Hash of file (sha256): 9FCC67FA3FAA88BCDED22E9FCF6AE1D6D62A95A79A1C777743052DF16F63DADC
Decode octet string:
0001f...f003031300d06096086480165030402010500042066cea53b15089957fc4ca86e419e2058f562e17a802e23e7d5154d2e71412e1a
Parsed string: https://lapo.it/asn1js/#MDEwDQYJYIZIAWUDBAIBBQAEIGbOpTsVCJlX_EyobkGeIFj1YuF6gC4j59UVTS5xQS4a
According to my observation, when signing different files, only 3 fields change: hash, messageDigest, encoded hash.
What is stored in the messageDigest field?
Cut digital signature:
https://lapo.it/asn1js/#MIIGRgYJKoZIhvcNAQcCoIIGNzCCBjMCAQExDzANBglghkgBZQMEAgEFADBcBgorBgEEAYI3AgEEoE4wTDAXBgorBgEEAYI3AgEPMAkDAQCgBKICgAAwMTANBglghkgBZQMEAgEFAAQgn8xn-j-qiLze0i6fz2rh1tYqlaeaHHd3QwUt8W9j2tygggPFMIIDwTCCAqmgAwIBAgIQGhQKhwNj5Z5IvU4kiPIzqjANBgkqhkiG9w0BAQsFADBVMVMwUQYDVQQDHkoARwBvAGwAbwB2AGwAZQB2ACAAVABpAG0AbwBmAGUAeQAgACgAVABpAG0AXwBkAGUAdgApACAAMQA1AC4AMAA1AC4AMgAwADAAMDAeFw0yMTAzMDMwMjEzNTJaFw0zOTEyMzEyMzU5NTlaMFUxUzBRBgNVBAMeSgBHAG8AbABvAHYAbABlAHYAIABUAGkAbQBvAGYAZQB5ACAAKABUAGkAbQBfAGQAZQB2ACkAIAAxADUALgAwADUALgAyADAAMAAwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsdIyw8JcPlDHM1fQGiBKmpWRYRhrOe31xwvYTYaQ02Uc-g0pIGzCu3Q-o6MS0i-2efIKs5shX0HFkLjMy1zgZc2F-PTx8f8HySRxroi5QVngQWLxu638sB9uYdVqBwWyNd7scZx-Z9Fd-kS0rFRIPlyuLCg8UOGtR5KbZ4V7dSNm8myHFTtVqD79n42oJEe2vkmUXQ266B2rHUdHDXJPTiXKwoZg4wAjeTkJUlgJwHeZUvpOkQfoo27C9dh8-4BRR4dHJOtwA1RDyuaVYl1tiQmBAAOcqjKf1bl9u3JLvxldIM8jura2k9oWLA3cxzx7Gr6DlIlGhD7EkyLww3n6VQIDAQABo4GMMIGJMIGGBgNVHQEEfzB9gBBOBdKqObwJh3JpHeW1T741oVcwVTFTMFEGA1UEAx5KAEcAbwBsAG8AdgBsAGUAdgAgAFQAaQBtAG8AZgBlAHkAIAAoAFQAaQBtAF8AZABlAHYAKQAgADEANQAuADAANQAuADIAMAAwADCCEBoUCocDY-WeSL1OJIjyM6owDQYJKoZIhvcNAQELBQADggEBAJeNUpwyUVqKSYGXPj6ibGfs4xxYaHf4obEJ3pgnWFblVgPahzQTutVJ5Ny-TSp0Ger8fTtu9soal35Zz9dpUE9aTYp-YWtEpaaqx5IC-OnH9Cao7ZJ_zM8fwiP9PtHNMuYCBiO24PmHF6oyB0gwcNYh0oa0YaVKJcmtHAVSH6WSzbdea3j9sdlBPVA6FeNchHCCiatesoM75IAUCvKYuBQ9JLenPvCXoKhXBDsiVb5tMKdZD8Vbvoj7b1JzKuv6NkICV99rLWW5MwfRMB-HG-BoML9E2mNJ-kqaVLFbJOZHCaNNIxejR70fY-ijexPNwvr_rI4VW01uYkdmSMlzRLExggH0MIIB8AIBATBpMFUxUzBRBgNVBAMeSgBHAG8AbABvAHYAbABlAHYAIABUAGkAbQBvAGYAZQB5ACAAKABUAGkAbQBfAGQAZQB2ACkAIAAxADUALgAwADUALgAyADAAMAAwAhAaFAqHA2Plnki9TiSI8jOqMA0GCWCGSAFlAwQCAQUAoF4wEAYKKwYBBAGCNwIBDDECMAAwGQYJKoZIhvcNAQkDMQwGCisGAQQBgjcCAQQwLwYJKoZIhvcNAQkEMSIEIBiU-ad7f9l47QV96ioO0N-tTrlArZspsH_A9t1TtmEGMA0GCSqGSIb3DQEBAQUABIIBAC8ocpjX6r77Kr4vEdo4F4PsNFZqxEaugEWpOqwjoYERAZ1QutqyrOebeU9iafvjXAC3chFsgMdpyH4NqW0_Wi1tShhpfhl-fNYatBCXaVbBFYUYuXCdpuXcYtN2nMaO3YR8aQVEKYJKB4UpLTlcho5LmxQDkYy42CZ-L795REpSW_Ts3_6Vcq7ZqBZ7nsRfhOxMOCFqb8gAKBdI8yv2XqZtJeQ258ChkkaUHyKnCWAKXlEVNJC4vhVYJWqBcQhcAdAA1lwHsnl0RklZ1httRb7a5inIH10HrJGypv2E9Zu8knCuQPbRzQvwnwu8k43zOrJnp2DlXspfAB0nxhR6s9w
messageDigest contains a hash of PKCS#7 message content which in turns contains the hash of signed data (PE, in a given case).
I want to encrypt string with the same length of character string and decryption with same length of character string using sql server. For Example:
Encryption
Input: Encrypt("002581") -- with 6 characters
Result: a&pE12 -- output with same 6 characters in encrypted form
Decryption
Input: Decrypt("a&pE12") -- with 6 characters
Result: 002581 -- output with same 6 characters in decrypted form
Short answer: there is no such secure encryption scheme.
Longer answer: any kind of encryption scheme obfuscates content of a plain text to be indistinguishable from other messages from the same message space. To do so all cipher texts produced must be of the same length (ideally) regardless of an input plain text. At least the length should be different from a length of a plain text.
So please, don't even consider such an encryption technique. It's insecure by definition.
I am doing a hacking challenge from Hack This Site in which I found a password hash and then cracked it by brute forcing possibilities. The format that my hash cracker (John the Ripper) used was something called "FreeBSD MD5". The password and hash are the following:
PW: shadow
HASH: $1$AAODv...$gXPqGkIO3Cu6dnclE/sok1
My question is, doesn't MD5 normally only have the charset 0123456789abcdef (hexadecimal)? Why is this hash suddenly including a bunch of other characters?
Screenshot:
This is a salted password hash:
$ is a field separator
1 is the type (MD5)
AAODv... is the (plaintext) salt for the hash
gXPqGkIO3Cu6dnclE/sok1 is the hash coded in base64
The salt is concatenated with the password before hashing to prevent rainbow tables: md5(salt + password)) and to verify a password, it must be prefixed with this salt prior to hashing.
Representing the hash in base64 makes it a bit shorter than by hex digits (23 vs 32 bytes).
I encrypt a UTF-8 string + current timestamp using AES 128bit CTR mode with a 4 bytes random initialization vector, which is generated by NodeJS's crypto.randomBytes().
Finally I base64 encode the whole output, using a URL-friendly base64 variant.
Question: the AES output should be unique due to timestamp + random data. But is final base64 string also guaranteed to be unique?
Thanks in advance!
Yes, Base64 is a reversible transformation, so if input is unique than output will be also unique.
If I have a string that will be encoded with Base64, Md5, or some other hash or encryption function, is there a way to at least be able to make a fair guess as to what it is?
You can try to guess but with a lot of false results. Md5 always have 32 characters, base64 have a limited set of possible characters, etc.