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.