[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BAY107-F19A501F60C6E4DBE2B619CFD470@phx.gbl>
Date: Sun, 11 Dec 2005 16:48:01 +0100
From: "Frank Dittrich" <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: MSSQL/SAP hashes?
Simon Marechal wrote:
>Jeroen wrote:
>>Also, there seems to be a SAP plugin for john.
[...]
>If there is one, it's not public. AFAIK the algorithm has not been
>disclosed. (But i thought the oracle algorithm had not been too, so i
>might be wrong).
The algorithm(s) are not public.
Nevertheless, it's possible to find out how SAP password hashes are
implemented.
Actually, there are 3 different hash algorithms for SAP R/3.
When SAP R/3 has been released in 1992, only one algorithm has been
implemented (CODVN A, now depreciated due to many flaws in the
design and implementation.)
Around 1994 or 1995, CODVN A has been replaced by CODVN B, so that
CODVN A is only used for passwords which haven't been changed for
about 10 years.
As a reaction to my first article regarding SAP password security,
published in August, 2003,
http://www.it-audit.de/assets/artikel/eigen/SAP-Passwort.pdf,
SAP created a slightly changed version, called CODVN D.
CODVN B is still the default. To use CODVN D for newly created
passwords, a recent SAP kernel and adjusting the SAP profile
parameter login/password_charset is required.
(Though I don't recommend switching to CODVN D.)
I mentioned a patch to John the Ripper which enables cracking
SAP passwords for CODVN B and D in my second article, published
in Octover, 2004:
http://www.it-audit.de/assets/artikel/eigen/SAP_Passwort_Update.pdf
Unfortunately, both articles are in German.
I didn't have the time to translate them into English, and I'm
afraid babelfish doesn't produce useful results.
I'm also not sure how much of what I wrote in those articles is
on topic in this mailing list.
If there is common interest for the contents of those articles,
I might summarize them in English - at least those parts which
could be on topic here.
If you have additional questions, feel free to contact me directly.
I'm, however, not going to publish the patch or mention details
about the algorithms being used.
(I'd like to contribute work to John the Ripper, because I
appreatiate the work done by Solar Designer and others, but I think
publishing the patch wouldn't be a good idea.
The reason is that it's very hard, if not impossible, to protect
SAP password hashes against unauthorized access.
That's why, publishing the algorithm IMO would have a disastrous
effect on the security of SAP systems, instead of increasing the
security by allowing the admin to discover weak passwords.)
Another somewhat off-topic remark:
SAP password security is just a minor issue.
I just picked this topic because it's relatively easy to cover.
There are many other problems regarding the security of SAP
system landscapes.
(I have yet to see a production system which doesn't allow an
arbitrary number of sufficiently skilled users to execute arbitrary
code, install any back door they like, ... - in most cases even
without the risk of being discovered.)
Someone important must have disliked the second article, so that it
seems to have disappeared from Google's and some other search engines'
index.
About a year ago, the article appeared among the first few hits
when using a sensible search term.
But today, it's impossible to find the article when searching Google,
and hard enough to find it on some other search engines.
Finally, some information regarding the performance on a linux
system with an AMD Athlon(TM) XP 2100+ processor.
I compiled the patched john 1.6.39 with -march=athlon-xp,
and started it in single user mode with nice -19:
Benchmarking: Traditional DES [64/64 BS MMX]... DONE
Many salts: 648051 c/s real, 648051 c/s virtual
Only one salt: 595622 c/s real, 595622 c/s virtual
Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE
Many salts: 21606 c/s real, 21606 c/s virtual
Only one salt: 21235 c/s real, 21235 c/s virtual
Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw: 5104 c/s real, 5104 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw: 300 c/s real, 300 c/s virtual
Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE
Short: 128512 c/s real, 128512 c/s virtual
Long: 451840 c/s real, 451840 c/s virtual
Benchmarking: NT LM DES [64/64 BS MMX]... DONE
Raw: 5675K c/s real, 5675K c/s virtual
Benchmarking: SAP R/3 codvn B [B-v0.4]... DONE
Many salts: 1683K c/s real, 1683K c/s virtual
Only one salt: 1495K c/s real, 1495K c/s virtual
Benchmarking: SAP R/3 codvn D [D-v0.4]... DONE
Many salts: 1738K c/s real, 1738K c/s virtual
Only one salt: 1415K c/s real, 1415K c/s virtual
(The patch just "works for me", i.e., since I don't have other
hardware, it doesn't support big-endian architectures,
doesn't make use of sse, uses MAX_KEYS_PER_CRYPT 1 ...
I doubt that performace can be increased significantly,
but minor tweaks are still possible.)
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.
