John the Ripper Authentication and Auditing

This is a two part assignment. In the first part, you’ll conduct a password audit using John the Ripper on a set of password hashes.  In the second part, you will create password policies for two groups. Below you will find an example policy you can use as reference and help with your own research. You can and should also use the textbook, the Internet and, most importantly, your own cleverness to create these policies. If you find any good information that you want to use as reference, use your understanding in your own words with a citation for the source. Wikipedia can be a useful spring board to legitimate sources, but Wikipedia itself is not a credible source.

The assignment is not meant to demonstrate only your password cracking ability, but to demonstrate that you know how to run a password audit and recognizing the importance of good passwords and policies.our deliverable is a professional quality paper in one PDF preferred, but Word format also accepted, that includes the following sections:

1. Minimum one page letter to Mr. Avenal that explains what you were requested to do, what you did, what you found, and the possible implications of continuing the use of current password policies

Note that Avenal is paying you and so  Your letter should be written in business style with little-to-no technical terminology

2. Two sets of password policies, one for each organizational unit as listed in the Avenal letterJustify why you suggest using password policies for each organizational unit. Note the two organizational units are very different. Should or shouldn’t they differ? You can be as technical as you like with this section Perhaps the highly sensitive information should be protected with two-factor authentication.3. A table that includes the usernames and for each, Method used to break the account (If dictionary, include the dictionary used ), and Why the password was broken (Too short, Used in a dictionary, etc) See example table below

4. The URL or location of the additional password dictionary used

5. Your john.log file. This file is located in a hidden .john directory off your user’s home directory. Full path: ~/.john/john.log . I want the full file not a screenshot or a copy/paste text, but the actual file submitted. Without this file, you will not receive credit for password audit portion of the assignment.

Assignment 1
CIS4360
Password Auditing and Policies
Palindrome Security, Inc
575 Tattarrattat Drive
Oktahatko, FL 32423
Dear Security Experts,
Recently, I attended a seminar where a consultant from your company discussed the
importance of using good passwords and the threats which can occur when good policies are not in
place. After the recent success of our Project Icarus that increased company productivity 1000% mainly
due to the increased interconnectivity of our computer systems, I believe our previous security policies
need to be replaced. I am writing you to request the creation of two password policies for two different
branches of our company: Sales and IT
The Sales branch has direct interactions with clients and potential clients and as such, they have
mostly full access to our clients records such as points of contact, phone numbers, addresses, products
and services used, etc, but not direct access to their financial information. Our IT is a small three-person
department, but has potential access to anything across all our divisions. The education backgrounds for
these employees range from high school to baccalaureates and our Sales department has received basic
computer training from IT.
As your consultant mentioned in their presentation, I understand that across the board policies
may not always the best solution, and so I am requesting that you create a policy for each unit along
with an explanation so that we can better inform our employees not just of changes we’re making, but
also why and their importance. Some good and bad examples to accompany this would be ideal.
Additionally, my IT administrator gave me a file with hashes when I asked him for files needed
for a password audit as mentioned during your presentation. I asked for passwords for the audit, but I
hope you can use these hashes in their place.
Sincerely,
Richmond Avenal
Second-In-Command
Reynholm Industries
Password Policy
Created by or for the SANS Institute. Feel free to modify or use for your organization. If you have a
policy to contribute, please send e-mail to stephen@sans.edu
1.0 Overview
Passwords are an important aspect of computer security. A poorly chosen password may result in
unauthorized access and/or exploitation of ‘s resources. All users, including contractors
and vendors with access to systems, are responsible for taking the appropriate steps, as
outlined below, to select and secure their passwords.
2.0 Purpose
The purpose of this policy is to establish a standard for creation of strong passwords, the protection of those
passwords, and the frequency of change.
3.0 Scope
The scope of this policy includes all personnel who have or are responsible for an account (or any form of
access that supports or requires a password) on any system that resides at any facility,
has access to the network, or stores any non-public information.
4.0 Policy
4.1 General
• All system-level passwords (e.g., root, enable, Windows Administrator, application administration
accounts, etc.) must be changed on at least a quarterly basis.
• All production system-level passwords must be part of the InfoSec administered global password
management database.
• All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every
six months.
• User accounts that have system-level privileges granted through group memberships or programs
such as “sudo” must have a unique password from all other accounts held by that user.
• Where SNMP is used, the community strings must be defined as something other than the
standard defaults of “public,” “private” and “system” and must be different from the passwords
used to log in interactively. A keyed hash must be used where available (e.g., SNMPv2).
• All user-level and system-level passwords must conform to the guidelines described below.
4.2 Guidelines
A. General Password Construction Guidelines
All users at should be aware of how to select strong passwords.
Strong passwords have the following characteristics:
• Contain at least three of the five following character classes:
o Lower case characters
o Upper case characters
o Numbers
o Punctuation
o “Special” characters (e.g. @#$%^&*()_+|~-=\`{}[]:”;’/ etc)
• Contain at least fifteen alphanumeric characters.
Weak passwords have the following characteristics:
• The password contains less than fifteen characters
• The password is a word found in a dictionary (English or foreign)
• The password is a common usage word such as:
o Names of family, pets, friends, co-workers, fantasy characters, etc.
o Computer terms and names, commands, sites, companies, hardware, software.
o The words “”, “sanjose”, “sanfran” or any derivation.
o Birthdays and other personal information such as addresses and phone numbers.
o Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
o Any of the above spelled backwards.
o Any of the above preceded or followed by a digit (e.g., secret1, 1secret)
Try to create passwords that can be easily remembered. One way to do this is create a password based on a
song title, affirmation, or other phrase. For example, the phrase might be: “This May Be One Way To
Remember” and the password could be: “TmB1w2R!” or “Tmb1W>r~” or some other variation.
(NOTE: Do not use either of these examples as passwords!)
B. Password Protection Standards
• Always use different passwords for accounts from other non- access (e.g., personal ISP account, option trading, benefits, etc.).
• Always use different passwords for various access needs whenever possible.
For example, select one password for systems that use directory services (i.e. LDAP, Active
Directory, etc.) for authentication and another for locally authenticated access.
• Do not share passwords with anyone, including administrative assistants or
secretaries. All passwords are to be treated as sensitive, confidential
information.
• Passwords should never be written down or stored on-line without encryption.
• Do not reveal a password in email, chat, or other electronic communication.
• Do not speak about a password in front of others.
• Do not hint at the format of a password (e.g., “my family name”)
• Do not reveal a password on questionnaires or security forms
• If someone demands a password, refer them to this document and direct them to the Information
Security Department.
• Always decline the use of the “Remember Password” feature of applications (e.g., Eudora,
OutLook, Netscape Messenger).
If an account or password compromise is suspected, report the incident to the Information Security
Department.
C. Application Development Standards
Application developers must ensure their programs contain the following security precautions.
Applications:
• Shall support authentication of individual users, not groups.
• Shall not store passwords in clear text or in any easily reversible form.
• Shall provide for some sort of role management, such that one user can take over the functions of
another without having to know the other’s password.
• Shall support TACACS+ , RADIUS and/or X.509 with LDAP security retrieval wherever
possible.
D. Use of Passwords and Passphrases for Remote Access Users
Access to the Networks via remote access is to be controlled using either a one-time
password authentication or a public/private key system with a strong passphrase.
E. Passphrases
Passphrases are generally used for public/private key authentication. A public/private key system defines a
mathematical relationship between the public key that is known by all, and the private key, that is known
only to the user. Without the passphrase to “unlock” the private key, the user cannot gain access.
Passphrases are not the same as passwords. A passphrase is a longer version of a password and is,
therefore, more secure. A passphrase is typically composed of multiple words. Because of this, a
passphrase is more secure against “dictionary attacks.”
A good passphrase is relatively long and contains a combination of upper and lowercase letters and
numeric and punctuation characters. An example of a good passphrase:
“The*?#>*@TrafficOnThe101Was*&#!#ThisMorning”
All of the rules above that apply to passwords apply to passphrases.
5.0 Enforcement
Any employee found to have violated this policy may be subject to disciplinary action, up to and including
termination of employment. Password cracking or guessing may be performed on a periodic or random
basis by the Information Security Department or its delegates. If a password is guessed or cracked during
these excersises, the user/owner will be required to change it.
6.0 Terms and Definitions
Term
Definition
Application Administration Account
Any account that is for the administration of an application
(e.g., Oracle database administrator, ISSU administrator).
7.0 Revision History
•
Author – Date