# Identifying the exact encryption procedure by database hash

I was asked to develop an external user administration for a legacy system so that it could be integrated into company processes. This system is mostly written in Python, but also uses unmanaged DLLs. There is no sufficient documentation about the system, also no source code.

Now I face the following problem: In order to successfully create a new user externally, I first have to reproduce the exact encryption process of the user passwords. These are stored in an Oracle 12g database in two columns: "PWDHASH" and "PWDSALT", whereby the columns have the format RAW.

By looking at the responsible Crypto-DLL in a text editor, I could at least find out that the passwords are encrypted by BCrypt with $$2^5$$ rounds. The output should be accordingly in the format $2y$12\$kr.ZczvVffAPjAhqlm9gCeXg52ML0bDHZ7ohELafqbur9VYb6hf5S.

Now the highlight - in the database there is only a hexadecimal string for the password hash (48 characters), also for the salt (32 characters). These are built like this:

[PWDHASH: 71CB599837172944B13CB650E3E60468619AF5BECC80C867; PWDSALT: F6DDABC4B7BBD433F5FF6B9BD634AFC0]

Now the question: How can I find out what happened between the encryption with BCrypt and the final values found in the database? Is Oracle's own encryption possibly still used here (RAW column format)? Is there a way to get this information without source code?

• I feel this question might be better suited for Reverse Engineering. Here on crypto, it's likely to be considered a off-topic "request to identify or decode some code". (Also, there's the fact that there's really not much anyone can say without actually reverse engineering the DLL, or at least having access to it for experimentation. All you've given us is what might as well be a bunch of random hex digits. At least the folks over at reverse engineering might be able to give you tips on how to analyze the DLL.) – Ilmari Karonen Jun 13 at 11:20
• First of all thank you very much for your answer and apologize for the delayed response. In the meantime I was able to find out from the previous developer, that an " own " algorithm is used here (rather a combination, as already guessed) and they won't give me its details. Now I have tried the application IDA (Interactive Disassembler) a little without being an expert in it, and now I try to integrate the original DLL simply into my project. Thanks for the hint with Reverse Engineering, I will - as soon as I have all information - contact them with a thread. Best regards – SiG Jun 17 at 6:57