[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Jul 2011 23:10:50 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: Charset options
Hi Maximilian,
Am 05.07.2011 19:48, schrieb Maximilian Melcher:
> Im doing a pentest with some SAP hashes (sapB, not case-sensitive) -
Did the "Betriebsrat" agree?
Which SAP basis release (SY-SAPRL)?
Why does the system still generate CODVN B passwords instead of CODVN E
passwords
or just CODVN F or CODVN H passwords, depending on the SAP basis release
and system
configuration?
(CODVN G means the system computes and stores both the CODVN B and the
CODVN F
hashes, CODVN I means, the system computes and stores both the CODVN B and
the CODVN H hashes.)
Probably your customer should adjust some of the login/*password*
profile parameters
to a more secure setting.
Depending on the SAP basis release, I would suggest using either CODVN E
(with password
length 8) or CODVN H (available for SAP-basis-releases > 7.0 (I think,
from 7.02 on),
but not CODVN F.
CODVN F (cracked by john using sapg) allows case sensitive passwords
with a lentgth
of up to 40 characters, and allows to use all (even non-ascii) printable
characters,
but users can still pick easy to crack passwords, because the algorithm
is relatively fast.
CODVN E and CODVN H (with default iteration count) are much slower, and
harder to crack.
If the SAP basis release is >= 7.0, and SAP stores CODVN F or CODVN H
hashes in
addition to the CODVN B hashes (this depends on the
login/password_downwards_compatibility
profile parameter setting), I wouldn't filter candidates according to
policy.
In this case, the reason is similar to the reason I provided for LM
hashes in my last reply.
The digits and special characters could be located at an offset > 8, so
that the password
matching the CODVN B hash doesn't meet the policy requirements, while
the real password does.
You could filter passwords starting with '?' or '!' (or make sure your
.chr file will generate those
passwords at the end of thekey space (by excluding all passwords
starting with '!' or '?' before
generating the .chr file).
Unfortunately, you can't even be sure it is correct to skip passwords
shorter than 8 characters.
A user might have picked the password "Secret# 1"
It meets your policy.
It is 9 characters long, contains letters, a digit and a special
character (plus the space).
If you convert it to a CODVN B password, it becomes "SECRET# ", with a
trailing space.
Unfortunately, trailing spaces are3 ignored by SAP, so john would have
to calculate the hash
for "SECRET#", not for "SECRET# ".
You might filter passwords with a trailing space, though.
Alternatively, you fix the sapb implementation, so that "SECRET# " will
be converted to
"SECRET#" before computing the hash.
Then you can limit your search to password length 8, assuming nearly all
passwords will
be of a length >= 8 characters.
Do you just have the hashes of current passwords, or hashes of
previously used passwords?
How old are the oldest hashes?
May be the current password policy was not in place when these hashes
were created.
These profile parameters didn't exist in older releases:
login/password_letters
login/password_specials
login/password_digits
Just login/min_password_lng existed in earlier releases (with a default
of 3, later increased to 6).
Trying to crack older passwords causes little overhead and might provide
information about
possible currently used passwords.
The explanation for these and other related profile parameters can be
found searching
SAP's online help at http://help.sap.com/ or searching for SAP notes on the
SAP service market place, https://service.sap.com/notes/ (requires
authorization).
Regards,
Frank
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
