2

I have a SSHA256 hashed password. Below is the plaintext and hashed password for it.

PlainText -p@ssw0rd
Encrypted -{SSHA256}LGkJJV6e7wPDKEr3BKSg0K0XDllewz9tvSNSaslDmIfPFmyuI5blUK/QsTXjvgFKLlMQm1jPC7K7z/KaD4zoHQ==

How can I extract salt from this password. The salt is 32 bytes long. And using SHA-256 algorithm to generate hash. This hash password is authenticated by IAM like okta also. Is there a way I can extract salt for this.

3 Answers 3

5

This is LDAP SSHA256, known to hashcat as mode 1411, and cracks successfully as such:

$ cat ssha256.hash
{SSHA256}LGkJJV6e7wPDKEr3BKSg0K0XDllewz9tvSNSaslDmIfPFmyuI5blUK/QsTXjvgFKLlMQm1jPC7K7z/KaD4zoHQ==

$ cat ssha256.list 
p@ssw0rd

$ hashcat ssha256.hash ssha256.list

[...]

{SSHA256}LGkJJV6e7wPDKEr3BKSg0K0XDllewz9tvSNSaslDmIfPFmyuI5blUK/QsTXjvgFKLlMQm1jPC7K7z/KaD4zoHQ==:p@ssw0rd
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 1411 (SSHA-256(Base64), LDAP {SSHA256})
Hash.Target......: {SSHA256}LGkJJV6e7wPDKEr3BKSg0K0XDllewz9tvSNSaslDmI...zoHQ==

From looking at the hashcat feature request and the associated code, it looks like the first 32 bytes are the hash, and all remaining bytes are the salt. So in your case, this happens to be exactly half and half - but strictly speaking, a compliant implementation that can handle arbitrary salt lengths would grab the first 32 bytes as the hash, and then grab all remaining bytes as the salt.

Depending on what form you need to work with it, it's decoded just as CBHacking describes - "un-base64" it first, then separate the results out into the two sections. You can then take the password (well, the hex, to illustrate appending):

$ echo -n p@ssw0rd | xxd -p
7040737377307264

... and then append the salt, and sha256 the binary form of the result (converted from hex back to binary here with xxd -p -r), yielding your hash:

$ echo -n 7040737377307264cf166cae2396e550afd0b135e3be014a2e53109b58cf0bb2bbcff29a0f8ce81d | xxd -p -r | sha256sum
2c6909255e9eef03c3284af704a4a0d0ad170e595ec33f6dbd23526ac9439887

... which, when your salt is appended, converted back to binary, and then base64'd, produces your original string:

$ echo -n 2c6909255e9eef03c3284af704a4a0d0ad170e595ec33f6dbd23526ac9439887cf166cae2396e550afd0b135e3be014a2e53109b58cf0bb2bbcff29a0f8ce81d | xxd -p -r | base64
LGkJJV6e7wPDKEr3BKSg0K0XDllewz9tvSNSaslDmIfPFmyuI5blUK/QsTXjvgFKLlMQm1jPC7K7z/KaD4zoHQ==
2

The "encrypted" (hashing is not encryption) text given is 64 bytes long (after base64 decode). This is exactly the length of a 32-byte salt plus a SHA-256 digest (also 32 bytes). Therefore, it's very likely that the base64-decoded data contains the salt in one half, and the digest in the other. Which is which can be determined experimentally, though unless you know the construction used for salting before hashing, it might take more than two tries.

For convenience, the hex values of the first and second half of your "encrypted" text are: 2c6909255e9eef03c3284af704a4a0d0ad170e595ec33f6dbd23526ac9439887 cf166cae2396e550afd0b135e3be014a2e53109b58cf0bb2bbcff29a0f8ce81d

Figuring out what construction - method of combining password and salt, plus method of hashing them - was used is up to you. It doesn't look to be any of the really obvious "H(salt | password)" or "H(password | salt)" options. Are you sure it's not an HMAC, KDF, or actual encryption?

1
  • Yes, I am sure on that. They mentioned this password is salted sha256 generated. Also, this is somehow getting validated by different IAM like Okta,ForgeRock. I am figuring out how I can generate this same hash.First by extracting salt and then adding to the password and then using MessageDigest class to generate it. However before proceeding with this, I am yet to to figure out the salt bytes. Commented Feb 3, 2022 at 7:06
1

I don't think there really is extraction with hashes, only collisions considering the it's function. For example Md5 and SHA1.

Since you know the password, and you know 32 bytes of string is the salt, you approach would be brute force. But this is where SHA256 fails, it's a really fast hashing algorithm and one of the reasons why argon2id is suggested which is resistant to multiple CPU and GPU bound speeds.

If you know what encoding scheme was used, it will help narrow down your list to check with. There are some great stackoverflow answers on how to calculate the list.

For example, if you have a Nvidia GTX 3090, you can expect around 121 MH/s hash rate, thats 121 million per second, approximately. For a 95 ASCII characters set, and for 8 character password, it'll be 95^8 possibilities. So with this example, it'll be a list of 6.6342043128906 x 10^15. So it's not peanuts, but it depends on how motivated you are.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .