This extension is created, sponsored and maintained by www.e-net.info¶
This is a wiki page! Please edit and help improving it!¶
Test backend user password strength.
The caretaker password cracker is an extension for the caretaker. It fetches backend user passwords from caretaker instances and feeds them to John the Ripper processes who tries to crack the passwords. If a password was successfully cracked, the corresponding caretaker test of the affected instance is marked as failure. This can be used to ensure a basic strength of your customers backend login passwords.
Fiddling with customer passwords and cracking them might be a problem for your customer. You may want to ask legal for possible consequences.
Furthermore, the caretaker server instance will have a list of caretaker nodes with its backend users and its hashes. Keep an eye on security measures for this CMS instance, some ideas: own server, do not mix ext:caretaker with other CMS things, https only, only reachable from own networks, ...
If john is unable to crack a password hash in reasonable time, it does not mean that the password is "good" or "safe". A professional attacker can very well specialize for this task better than you and crack the hash even if you don't. He could for example throw more CPU hardware at the problem or could crack the hashes in GPU (john provides GPU functionality for some of the TYPO3 CMS hash types, feel free to document the options here if you manage to get this to work).
Features¶The following hash types can be cracked if everything is correctly set up:
- Simple md5 (no saltedpasswords installed)
- blowfish (saltedpasswords)
- phpass (saltedpasswords)
- salted-md5 (saltedpasswords)
ext:saltedpasswords comes with a scheduler task that "upgrades" simple md5 passwords to other hash types. Those "converted" passwords are prefixed with a "M" in the database. They are transferred to "usual" hashes upon next login of a converted user. Those "M" prefixed hashes can currently not be cracked by the extension.
- You should have a working caretaker running, you should be able to manage it and understand its concept
- You need to compile john the ripper. You need more than simple administrator knowledge on unix systems and you might need to debug your way through the application to get it to work.
- You need a new "data fetcher" on the "client" caretaker installations, so you will need to patch and roll out a modified caretaker_instance extension.
- You might be faced with incompatibilities and other woes and should feel lucky hacking things.
- First, there is a data fetcher class within ext:caretaker_instance. This runs on the caretaker client nodes, fetches all backend user rows from the instance and sends them to the master caretaker instance.
- The master caretaker instance stuffs all "active" backend user records to an own table together with an information from which node the data was fetched. It also checks for passwords marked as "cracked" in the database table and lets the according instance tests fail.
- The test marks in the core registry if passwords changed and if new users are found. In this case the password hash lists for john need to be recreated and the john processes must be restarted.
- A scheduler task regularly checks the "changed" flag, creates text files for john the ripper with user-node and hash and starts / stops john processes (one process per hash type). The task also checks for cracked passwords and marks them as insecure in the database table.
We currently only know of one caretaker server instance where this extension is in used. It should run on different versions, maybe with small changes.
Current version matrix in production:
- TYPO3 CMS 4.5
- ext:caretaker 0.3.1
- ext:caretaker_instance 0.3.5 (with slight, non-related modifications)
- john: john-1.7.9-jumbo-7 (this is be important, other packages don't support all hashes or need some different parameters)
Alternatives to that:
- ext:caretaker 0.4.1
- ext:caretaker_instance 0.4.1 (hint: apply patch manually!)
- john: john-1.7.8-1 from the debian repositories. Comes only (is that confirmed?!) with supports for (salted) md5 passwords, but works just as fine.
Things to do on client nodes¶
- Patch caretaker_instance with the delivered patch file to get the "data fetcher" class up and running.
Things to do on server node¶
- Install ext:caretaker_password_cracker
- Create directory "john" next to your document root (this is where john configuration and password lists are stored)
- Create sub directories "passwordLists", "sessions" and "wordlists" within john directory. Those directories need to be writable by the executing web server user!
- Download john-1.7.9-jumbo-7.tar.gz within john directory from http://www.openwall.com/john/, unpack, link "john" to "john-1.7.9-jumbo-7"
- Compile john in src/ directory (eg. with linux-x86-sse2i). Executables will then be found in run/ directory
- Adapt absolute path in $johnExecutable in Classes/Task/JohnAdapter.php (or create a patch to put this path into the task via additional field provider)
- Run the test for some client node and verify that the database table on the server node is filled with rows. The test itself only fetches the user data from the client nodes.
- Execute the task "John password cracker adapter" and verify that one john process is started per different hash method (maximum 4 for 4 hash types)
- Add the task as regular scheduler task and make it run once in a while, eg. some minutes after the caretaker tests where executed
- To cope with different hash lists at once, john needs the session parameter when called. The php class takes care of that.
- The john processes typically run all the time and finish only if all passwords were cracked (which typically does not happen).
- The running processes are only stopped and restarted if a new password occurs (the test recognizes this and adds a hint to the CMS core registry that the processes need to be restarted). The reason for not re-starting the processes every couple of minutes is that john starts from scratch if the password lists changed. So: Long running processes are good, they shouldn't be started and stopped too often.
- If debugging the system because something is wrong, take a look at the registry entries (table tx_registry - rows namespaced with the extension name). They can be safely removed to force a reload of the password lists.
- It also helps to execute the "exec" command on the shell (as the executing shell-user) to see if john is happy with format an such.
- The cracked passwords are not transferred back to the TYPO3 table, they are only marked as cracked, but the real plaintext password is not stored in the CMS again.
- To manage the john processes, the PID of a forked process is also stored in the registry. During testing, or if you killed those processes manually you may just remove the according registry entries. The task will then just restart the processes on next run.
- The php extension code is pretty straight forward. It should be easy to understand and debug - take a look.
If you manage to get this setup working (it might be not trivial if doing for the first time), please give feedback and help improving this extension, the documentation.
Test parameters¶To verify the correct behavior, here is a list of hashes that should be cracked successfully. You could add those passwords to some test (!) node and see if the test turns red after a while.
- acbd18db4cc2f85cedef654fccc4a4d8 (simple md5)
- $1$1V4Gdrpv$888bdBWrA843R6FoMlIzg/ (salted md5)
- $2a$07$6t0QrwroUKs5HTctbscxJ.6piwW03QOmmVYfcJ/ULE1SbAYXbowry (blowfish)
- $P$CTailGzwJzhBK28Glt6mJZ7E2dNIlq/ (phpass)
- It would be cool if the system could also break the "M" prefixed hash types. For the md5(md5(password) . salt) method this is doable but currently requires a (not yet done) patch for john.
- It would also be nice if the system could fetch and crack the InstallToolPassword hashes.