0

So, this online discussion function use decoded account names in every post, along with that they call "logging data", an example of this can be:

Loggin data: 10878
Encoded account info: U2FsdGVkX19bCgrkbEjt4gDrFKNANCce

Now, the first part of the string when run through a base64 decoder ("U2FsdGVkX1") is just the string "Salted__" and the rest is what appears to be something binary.

So the account string changes for each input by the user, and what I am trying to do is to decode this string in order to determine if the value after "Salted__" is the same, and knowing that this is something that the owners of the software can do, I must assume that the "loggin data" is some sort of salt for the resulting binary data.

So, my question is - is there any way for me (or you) to figure out just how the binary data is encoded and how to decode it? And again - it can be decoded, as long as you know how. :)

This data does not (to my knowledge) contain any personal information and may at most contained the login name or the login ID of the user, so I am not trying to expose any personal information. Only determine whether someone is posting with multiple "nicks" from the same account.

marked as duplicate by Anders, Neil Smithline, Matthew, Rory Alsop May 30 '16 at 21:56

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 3
    The binary part does not necessarily encoded data: it may just as well be a random binary value, only used to look up, for example, some record in a database. In other words: there is no way to find out, from the information you gave us. – Jacco May 26 '16 at 20:25
  • Probably not since that would require a new layer of logging which is unlikely I this scenario. I would assume that the decoded value would be the same – Sandman May 26 '16 at 21:14
  • Even if there are some info in that binary data, it is impossible for us to know how it is encoded. – Anders May 26 '16 at 21:50
2

The prefix Salted__ almost certainly means this either is the output of the openssl enc command or something designed to be compatible with it. There are many other password-based derivation, hashing, or encryption schemes that use salt, but none use this particular very simple format.

The salt is in the ciphertext, just after the prefix Salted__, so the 'loggin data' is not the salt; from the information you present, it's impossible to tell what if anything it is. Since the salt is random for each encryption, encrypting the same data (possibly the login or account you are looking for) multiple times will produce an entirely different encryption each time and these cannot be linked except by decrypting.

In order to decrypt this, you need to know, find out, or guess:

  • the cipher/mode used -- it clearly is either stream or 8-byte block and most likely the latter. If you can de-base64 numerous ciphertexts and any have lengths that are not a multiple of 8 it is definitely a stream cipher (RC4) or mode (CFB, OFB, CTR); if all are a multiple of 8 it is extremely likely a block mode (CBC or usually-bad-ECB) of TDES or maybe another 8-byte block cipher. Worst case there are a few dozen possibilities to try, a hurdle but not insurmountable.

  • the derivation hash -- almost certainly the default MD5; few people even know there are options

  • the password used -- if the system is properly designed and operated, this password should be secured so you can't get it, and strong enough you can't guess it in less than say a million or billion years. That said, the openssl enc PBKDF is weak, so if the password is actually known to a person (or persons) rather than on something like a smartcard or USB stick it is probably feasible to brute-force it if you have enough time and CPU power.

  • Well, what I did was run a PHP foreach openssl_get_ciper_methods() which will give me a list of all cipher methods the openssl function in PHP supports, and then I try to decrypt it with each, using the "logging-data" as salt. The reason I think the logging data is instrumental to the decryption is because I'm 99% sure there is no external logging, and the only way for admins to know who posted what is to use the information contained in each post. – Sandman May 27 '16 at 17:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.