Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

John the Ripper in the cloud

John the Ripper is an Open Source password security auditing and password recovery tool available for many operating systems. John the Ripper jumbo supports hundreds of hash and cipher types, including for: user passwords of Unix flavors (Linux, *BSD, Solaris, AIX, QNX, etc.), macOS, Windows, "web apps" (e.g., WordPress), groupware (e.g., Notes/Domino), and database servers (SQL, LDAP, etc.); network traffic captures (Windows network authentication, WiFi WPA-PSK, etc.); encrypted private keys (SSH, GnuPG, cryptocurrency wallets, etc.), filesystems and disks (macOS .dmg files and "sparse bundles", Windows BitLocker, etc.), archives (ZIP, RAR, 7z), and document files (PDF, Microsoft Office's, etc.) These are just some of the examples - there are many more.

Follow @Openwall on Twitter for new release announcements and other news

As an alternative to running John the Ripper on your own computer, you can run it in the cloud. We provide a pre-generated Amazon Machine Image (AMI) called Openwall Password Recovery and Password Security Auditing Bundle, which lets you start password recovery or a password security audit in minutes (if you've used Amazon Web Services before, or you need to sign up first).

The Bundle features Amazon Linux 2 along with John the Ripper jumbo pre-built and pre-configured with multi-GPU (via OpenCL) and multi-CPU support (with AVX-512, AVX2, and AVX acceleration, and transparent fallback when run on older CPUs lacking the latest AVX extensions). The Bundle has been tested on both GPU-enabled and CPU-only AWS instances.

Also included are sample Unix and Windows password hashes for testing and learning how to use the software, as well as sample encrypted files to let you get started on a known-password sample before going for a real password recovery attempt.

Proceed to subscribe to the Bundle and launch your first virtual machine:

Paid usage of the Bundle supports our Open Source project. In fact, this might be one of your reasons to use the Bundle as opposed to building from source on your own, especially if you manage an AWS account for an organization that benefits from our software and can afford to contribute back.

Connect to your virtual machine instance using a SSH client (on Windows, you can use PuTTY). To keep and reconnect to a running John the Ripper session across SSH disconnects/reconnects, use one of the tools screen or tmux, both of which are pre-installed in our AMI.

The default ("recommended") instance type when launching from AWS Marketplace is currently set to c6i.xlarge, which should fit in AWS default service quota for new users (more on it below).

For hash and cipher types that we include OpenCL support for, we actually recommend GPU instance type p3.2xlarge (or larger), which features NVIDIA Tesla V100 GPU(s), or GPU instance type g4dn.xlarge (or larger), which offers the smaller NVIDIA Tesla T4 GPU(s) at much lower cost than the V100's. For hash and cipher types that we only support on CPU and in special cases where CPUs are more efficient, we recommend Compute Optimized instance types c6i.32xlarge / c6i.metal (Intel Xeon, AVX-512) or c6a.48xlarge / c6a.metal (AMD EPYC, AVX2). If in doubt, give several of these a try at your specific task.

For major cost savings, you can optionally use spot instances, where you bid a maximum per hour price and are charged the current market price. A typical spot price is 2 to 3 times lower than the regular on-demand price. (This applies to AWS EC2 service fees only. The charges for our Bundle are on top of those, and are the same for spot and on-demand instances. Nevertheless, you'd typically halve your total costs by using spot instances.) When launching from AWS Marketplace, choose "Launch through EC2" instead of "Launch from Website". This gets you to a lengthy "Launch an instance" page with multiple sections. Expand "Advanced details" and check "Request Spot Instances". You can then optionally click "Customize", which lets you set "Request type" to "Persistent" and "Interruption behaviour" to "Stop", which is both useful (see below) and dangerous (may result in an unexpectedly huge bill if you don't know or forget to deactivate the persistent request later). Thus, persistent requests are not suitable for your initial experiments with the Bundle, but are something to revisit later.

Trying to launch an instance may fail, in which case the reason will generally appear at the very end of this same "Launch an instance" page - so be sure to scroll it down to the very end when you've returned to it after a failed launch.

If you're new to AWS, you'll likely find that you need to request a service quota increase before you're able to launch the large instances that we recommend, and separately to launch them as spot instances.

Another common reason is unavailability of a given instance type (within the specified maximum spot price, if applicable) in the chosen "Availability Zone". If so, under "Network settings" click "Edit" and then under "Subnet" choose one corresponding to a different "Availability Zone". If that doesn't help, you may need to choose a different region (at top right) or/and instance type or/and give up on trying to use a spot instance (use a regular on-demand instance at full price).

A spot instance may be interrupted if the market price exceeds your bid. If your request was persistent, the instance may later start back up automatically. If it was not, you can nevertheless effectively recover your instance by creating a snapshot from the terminated instance's volume, creating an AMI from the snapshot, and launching an instance from the AMI. Either way, current version of the Bundle will then automatically resume an unfinished John the Ripper job, which it does by issuing the "john --restore" command under "screen".

We don't charge for usage of the Bundle on micro sized instances. Out of those, t2.micro is eligible for AWS free tier, which provides free usage of some AWS services for the first year for new AWS users. Of course, such instances are unsuitable for serious usage of the Bundle (especially as they're so-called burstable instances, with long-term vCPU utilization limited e.g. to just 10% of one vCPU on t2.micro), but you can use them for getting acquainted with the Bundle at no or little cost, and they just might succeed in recovering the weakest passwords despite of being extremely limited performance-wise. For actual usage, we recommend at least c6i.large (which allows sustained 100% vCPU utilization).

To avoid unacceptably large charges resulting from forgotten AWS services, we recommend that you set up CloudWatch "EstimatedCharges" alarms. Please note that these need to be set up in every region that you use.

For free community support on (semi-)advanced questions or issues (if you know half the answer), please join the public john-users mailing list and post in there. For general customer support, please e-mail us at <john-cloud-support at openwall.com>.

You can browse the documentation for John the Ripper core online. Also relevant is our presentation on the history of password security.

Screenshots of a terminal window accessing an AWS p3.2xlarge instance

Basic usage instructions, and md5crypt benchmark on an NVIDIA Tesla V100 GPU on AWS as an illustration of performance to expect:
Image: Openwall Password Recovery and Password Security Auditing Bundle basic usage instructions, and md5crypt benchmark on an NVIDIA Tesla V100 GPU on AWS as an illustration of performance to expect (~27M c/s at md5crypt "Many salts", which is a very decent speed)

Demo of Apple macOS .dmg file password recovery using a GPU in the cloud:
Image: Demo of Apple macOS .dmg file password recovery using a GPU in the cloud

Quick Comment:

234122