Sponsored Content
Special Forums UNIX and Linux Applications John the Ripper application question Post 302378976 by pludi on Wednesday 9th of December 2009 08:52:49 AM
Old 12-09-2009
Short answer: No

Long answer: Let's delve into the cryptographic stuff behind UNIX passwords, GPG, and JtC.
UNIX authentication systems never save the passwords themselves in any form, not even encrypted, but instead use a hash of the password. A hash is similar to a compression function. It takes an array of bytes (say, the letters of a password) and mangles them into a fixed length array. The idea is that a small change in the original text yields a big change in the hash, and that by hashing 2 identical texts you get the same hash. If a user wants to authenticate, the password entered is hashed, and the hash is compared to the one saved.
Since hashing means you loose information, hashes will never be collision free. To prevent 2 users accidentally having the same password hash, salts were introduced. Those are random bits prepended to the password, so that even if two users has the same password, their hashes wouldn't match up.
The biggest difference between hashing and encryption functions is that hashes are very fast.

Encryption, OTOH, takes the input message (your text file) and a key (created from your password), and sends both through an encryption function like AES. Contrary to hashes, the result usually isn't shorter than the original, but it's getting transformed, and it's recoverable while hashes are not. Also, encryption schemes usually are very resilient against attacks. For example, with AES it's still impossible to recover the key in a know-plaintext attack (meaning: you have both the original text and the encrypted text, and it's still impossible to find out the key/password used as to decrypt other messages).

John the Ripper (JtR) uses the speed of hashes to its advantage. A dictionary attack is very fast, even against salted password hashes, and even faster again NTLM passwords. But it can only attack hashes, since they're pretty fixed in their parameters, while for encryption there are a lot of variables, such as key length, algorithm used, and which block mode is being used (CBC/CFB/CTR/...)
 

3 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

sudo: application install question

I need to install an application on my Sun station and need root privleges to do so. I was given sudo privileges and was told to issue the following command. bash-2.03$ sudo init 0 I've read the man pages for init and understand the purpose of that command. My questions are: 1. From the... (2 Replies)
Discussion started by: forbin24
2 Replies

2. Red Hat

John the Ripper / CRACK

Has anyone used JTR or CRACK to check if you have any weak passwords on your Red Hat Servers? If so can I ask some basic questions? Or would this question be better pitched in another area of the Forum, if so please suggest where, if anyone is willing to help me in this forum please let me know... (1 Reply)
Discussion started by: stevej123
1 Replies

3. Cybersecurity

John the ripper

Hi evryone, I have problem the john program. It works correctly but I can not make unshadow command because I have removed the file /usr/bin/john by mistake # cd ../run # ./john /root/shadow Loaded 2 password hashes with 2 different salts (FreeBSD MD5 ) letmein (root) letmein ... (5 Replies)
Discussion started by: bander2009
5 Replies
SMBPASSWD(5)															      SMBPASSWD(5)

NAME
smbpasswd - The Samba encrypted password file SYNOPSIS
smbpasswd DESCRIPTION
This tool is part of the Samba suite. smbpasswd is the Samba encrypted password file. It contains the username, Unix user id and the SMB hashed passwords of the user, as well as account flag information and the time the password was last changed. This file format has been evolving with Samba and has had several dif- ferent formats in the past. FILE FORMAT
The format of the smbpasswd file used by Samba 2.2 is very similar to the familiar Unix passwd(5) file. It is an ASCII file containing one line for each user. Each field within each line is separated from the next by a colon. Any entry beginning with '#' is ignored. The smb- passwd file contains the following information for each user: name This is the user name. It must be a name that already exists in the standard UNIX passwd file. uid This is the UNIX uid. It must match the uid field for the same user entry in the standard UNIX passwd file. If this does not match then Samba will refuse to recognize this smbpasswd file entry as being valid for a user. Lanman Password Hash This is the LANMAN hash of the user's password, encoded as 32 hex digits. The LANMAN hash is created by DES encrypting a well known string with the user's password as the DES key. This is the same password used by Windows 95/98 machines. Note that this password hash is regarded as weak as it is vulnerable to dictionary attacks and if two users choose the same password this entry will be identical (i.e. the password is not "salted" as the UNIX password is). If the user has a null password this field will contain the characters "NO PASSWORD" as the start of the hex string. If the hex string is equal to 32 'X' characters then the user's account is marked as disabled and the user will not be able to log onto the Samba server. WARNING !! Note that, due to the challenge-response nature of the SMB/CIFS authentication protocol, anyone with a knowledge of this password hash will be able to impersonate the user on the network. For this reason these hashes are known as plain text equivalents and must NOT be made available to anyone but the root user. To protect these passwords the smbpasswd file is placed in a directory with read and traverse access only to the root user and the smbpasswd file itself must be set to be read/write only by root, with no other access. NT Password Hash This is the Windows NT hash of the user's password, encoded as 32 hex digits. The Windows NT hash is created by taking the user's password as represented in 16-bit, little-endian UNICODE and then applying the MD4 (internet rfc1321) hashing algorithm to it. This password hash is considered more secure than the LANMAN Password Hash as it preserves the case of the password and uses a much higher quality hashing algorithm. However, it is still the case that if two users choose the same password this entry will be iden- tical (i.e. the password is not "salted" as the UNIX password is). WARNING !!. Note that, due to the challenge-response nature of the SMB/CIFS authentication protocol, anyone with a knowledge of this password hash will be able to impersonate the user on the network. For this reason these hashes are known as plain text equivalents and must NOT be made available to anyone but the root user. To protect these passwords the smbpasswd file is placed in a directory with read and traverse access only to the root user and the smbpasswd file itself must be set to be read/write only by root, with no other access. Account Flags This section contains flags that describe the attributes of the users account. In the Samba 2.2 release this field is bracketed by '[' and ']' characters and is always 13 characters in length (including the '[' and ']' characters). The contents of this field may be any of the characters. o U - This means this is a "User" account, i.e. an ordinary user. Only User and Workstation Trust accounts are currently supported in the smbpasswd file. o N - This means the account has no password (the passwords in the fields LANMAN Password Hash and NT Password Hash are ignored). Note that this will only allow users to log on with no password if the null passwords parameter is set in the smb.conf(5) config file. o D - This means the account is disabled and no SMB/CIFS logins will be allowed for this user. o W - This means this account is a "Workstation Trust" account. This kind of account is used in the Samba PDC code stream to allow Windows NT Workstations and Servers to join a Domain hosted by a Samba PDC. Other flags may be added as the code is extended in future. The rest of this field space is filled in with spaces. Last Change Time This field consists of the time the account was last modified. It consists of the characters 'LCT-' (standing for "Last Change Time") followed by a numeric encoding of the UNIX time in seconds since the epoch (1970) that the last change was made. All other colon separated fields are ignored at this time. VERSION
This man page is correct for version 2.2 of the Samba suite. SEE ALSO
smbpasswd(8) samba(7) and the Internet RFC1321 for details on the MD4 algorithm. AUTHOR
The original Samba software and related utilities were created by Andrew Tridgell. Samba is now developed by the Samba Team as an Open Source project similar to the way the Linux kernel is developed. The original Samba man pages were written by Karl Auer. The man page sources were converted to YODL format (another excellent piece of Open Source software, available at ftp://ftp.icce.rug.nl/pub/unix/ <URL:ftp://ftp.icce.rug.nl/pub/unix/>) and updated for the Samba 2.0 release by Jeremy Allison. The conversion to DocBook for Samba 2.2 was done by Gerald Carter 19 November 2002 SMBPASSWD(5)
All times are GMT -4. The time now is 11:10 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy