> From: Ronish Mehta [mailto:sf_mail_sbmat_private] > Sent: Thursday, July 31, 2003 1:20 AM > > Application does not allow to put smaller passwords > > Password0 - D5FBB0C7C20D9CE79D3B837BD6FB3505 > Password3 - D5FBB0C7C20D9CE7B872B3A0BD587B8D These appear to confirm various speculations that the app uses a 64-bit block algorithm of some sort, but aside from that they don't help much. (Note that they also indicate that the algorithm doesn't use salt, which suggests that the author wasn't very knowledgable about security matters, which is in your favor.) Your original note contained one password of 7 characters ("QUALITY") and one of 8 ("Cr@ckM3!"). How short a password will the application allow? If I were serious about analyzing this algorithm (which I'm not; it doesn't appear to be trivial, and anything harder is definitely not in my job description), I'd probably generate several hashes using the shortest password the application would accept; first a pair where only the first character varied, then a pair where only the second character varied, and so forth. I'd also try things like varying the case of one character to make sure the algorithm doesn't fold case. But that's just to get started. Analyzing an unknown algorithm from plaintext / ciphertext pairs is a lot of work. In some cases the analyst gets lucky: the algorithm is weak and a bit of poking around combined with a guess or two reveals enough that the rest can be figured out without too much work. But often even the specifics of weak algorithms are hard to deduce from this kind of black-box inspection. It can be done - doing it is a major industry, in fact - but in general it's not easy. > I posted > this because i need to make a password audit for weak > passwords, I have full access to the database this is > how i get access to the hashes! So you're trying to mount an offline dictionary attack. (Whatever its motives, authorized or not, from the system's viewpoint it's an attack.) The fact that the algorithm apparently isn't salted is useful; it reduces your dictionary storage requirement (there's only one possible hash for every password). > We do not have access to the source code, so i can;t > figure out the algorithm Since you have the binary, it'd almost certainly be easier to reverse-engineer it from that, than deduce it by looking at plaintext and hash pairs (even with the advantage of chosen plaintexts). Debug the app when it's creating hashes. Figure out where that happens. Disassemble the relevant code. Analyze it. In fact, once you've disassembled the relevant code, you can probably reimplement it in a quick hash generator without understanding exactly what it does. So long as it takes plaintext and grinds out the correct hash, you're good to go. Filter your dictionary of weak passwords through it and you've got a dictionary of weak password hashes. -- Michael Wojcik Principal Software Systems Developer, Micro Focus
This archive was generated by hypermail 2b30 : Thu Jul 31 2003 - 12:47:44 PDT