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==