Oubliette Password Manager support #5680
Conversation
|
The password manager is pretty ancient, no wonder it doesn't appear to use a real KDF (if the code here is correct). https://sourceforge.net/projects/oubliette/ |
|
CI: Fails build |
Hi, this is the hash extractor: oubliette2john.py Yes, the plugin is not finished, I do not have much time to continue the development. I based this work on the Keepass 1.x Oubliette import tool If you need sample Oubliette password files, or any other info, I'm happy to provide. Regards. |
|
Thank you very much @davidedg!
I think it would be unreasonable to expect you to implement SIMD and OpenCL, but maybe you do have time to do at least some of the following?
Yes, we need sample files - via a PR to the https://github.com/openwall/john-samples repo, please. |
|
@exploide Please take a look at |
When you do this, perhaps also use this opportunity to reformat the source code to indent with 8-char tabs like we normally use. |
src/oubliette2john.py
Outdated
| return 0 | ||
|
|
||
| except IOError as e: | ||
| sys.stderr.write(f"{filename}: {str(e)}\n") |
There was a problem hiding this comment.
str() function is unnecessary here and will be called implicitly anyway. {e} is enough for simplification.
src/oubliette2john.py
Outdated
|
|
||
| def usage(): | ||
| sys.stderr.write("Usage: oubliette2john.py <oubliette files>\n") | ||
| sys.exit(-6) |
There was a problem hiding this comment.
exit codes are unsigned integers. Please use positive numbers here and above.
https://github.com/davidedg/john-samples/pull/1/commits
No, I just used their existing code (rather than the original Oubliette code) to understand how the hashing worked, because it was much easier.
I restored that dev environment and tried configuring without openssl, I'll try to get some time to work on these, but can't promise it'll be soon.
Tried, seems I'm unable to reproduce:
|
Looks like you forgot |
good catch, that should be fixed now.
Using VSCode, if I pick any other file and try detect the indentation from content, it picks 4-char tabs. |
integrated your suggestions, thx!
done! |
For now I excluded the format on no-openssl builds. |
|
I forgot to tell you that we normally prefix commit titles with subsystem names, so e.g. This is once again failing whitespace-errors, I guess you didn't re-run this check after making further changes:
Oh. Maybe it just doesn't know what tab width we intended.
I'm not familiar with VSCode. I guess there may be a configuration setting for tab width. |
|
@davidedg Please also add a |
There was a problem hiding this comment.
The following can be done by the maintainer just to speed up the process:
- I'm afraid this will have to be done before the merge:
$ git pull --rebase [email protected]:openwall/john.git
$ git reset --soft HEAD~10
$ git commit -m "Oubliette: Added Oubliette Password Manager Hash creator" # Or something like this
$ indent -kr -i4 -ts4 -nlp -nbbo -ncs -l119 -lc119 -bad -il0 src/oubliette_*.c
$ astyle --style=kr -t4 -U -H -p -xC119 -c -k3 -z2 src/oubliette_*.c
$ git mv src/oubliette2john.py run/
$ git commit -a --amend- Move the docs/NEWS note to the proper place (the end of the list, below b55f339)
- Set the file's execution flag .
To compare (or use as a reference):
0001-Oubliette-Added-Oubliette-Password-Manager-Hash-crea.PATCH
... or right after merge, as a separate commit. |
|
Guys, these are 3 simple files... how about:
Let me know. |
Thank you for offering this, but now that this PR isn't in too bad a shape (even CI is happy), I'd rather just squash-and-merge it (one commit) and then add a commit of my own to clean things up. I'm sure there will be other opportunities for you to contribute to our project more when your time permits. |
|
I just did the squash-and-merge thing, but unfortunately GitHub changed the way they do it since last time I used this feature. Previously, they would set the original PR's author as commit author (and GitHub as the committer, which was weird), but now they set me (the one merging the PR) as the commit author (and still GitHub as the committer, which is still weird). Luckily, the suggested commit message included |
Oh! I think I realize what may have changed - this time, I was also the one to create the PR, even if from Davide's repo. So maybe nothing changed on GitHub's end, after all. |
|
I've made some basic cleanups and corrections via subsequent commits. However, testing this against the test vectors from openwall/john-samples#31 I am only able to directly crack the simple password Oh, alternatively I am able to get it cracked by adding @magnumripper please suggest how to fix this encoding issue best, to minimize user confusion and users' wasted time on running with wrong encoding settings. Right now, by default we print |
|
I've just created #5681 for the character encoding issue - let's discuss that one in there. |
That's no worries, my name is still in the file's comments.
That's how I was testing it. Not sure if I handled everything the way is supposed to be in the source (especially for the FMT* stuff...) |
Did so. Also, I reviewed the format flags (that affects encoding) in this PR and they should be correct. |
|
FWIW, the Blowfish kind of this format is somewhat slow because it involves Blowfish key setup, which is known-slow. I guess it's reasonable to expect this to be about 65 times (as Just like for bcrypt, there isn't much opportunity to use SIMD on CPU because CPUs' SIMD gather instructions still tend to be too inefficient to provide much or any speedup over scalar code. Of course, SIMD can be used for SHA-1, but given that most time is spent in Blowfish, the overall speedup from that would be minimal (it'd make more of a difference for the IDEA kind). https://www.openwall.com/presentations/Passwords14-Energy-Efficient-Cracking/slide-07.html |
I didn't know I can create a GitHub PR from a third-party repo, but apparently I can? So doing this to record in here this unfinished work by @davidedg that I just came across "by accident". This is not ready in several ways, including that there's no
*2johntool to extract those "hashes" yet, and that the attempts at SIMD here are just stubs (better drop them from the first real PR). Also, this can probably be one format rather than two, and the source code could be formatted more similarly to ours.