Skip to Content

Why you should really get rid of old password hashes *NOW*

This blog is written in an effort to raise more awareness on securing your SAP infrastructure. In this case specifically on the topic of securing your SAP Password hashes. I will try and avoid being too technical…If I fail, sorry in advance

As recently announced there is a new version of OCLHashcat, version 1.20 that now supports password cracking for SAP Codeversion B and F/G. See the release notes.

Say what? And why should I care?

For the less technical people amongst us, OCLHashcat is an advanced password cracking tool that allows you to crack passwords via GPU’s (Graphical cards. This allows you to crack passwords (SAP passwords included) in a relatively fast way.

You should care about this as it is now possible to crack your SAP passwords very fast. Specifically the ones that are hashed in codeversion B or F/G. This may allow intruders to give access to your SAP systems.

So what about this codeversion B and F/G thing?

SAP passwords are stored in the database of your SAP systems in the USR02 table. They are not stored in clear text, but in a hashed format, so it cannot be read by anyone having direct access to the database tables.

This hash can be generated via different algorithms (In sap called codeversions). See for a good overview the weblog of Daniel Berlin. The most recent algorithm used is “I”, older versions are for example H, G, F, E, D, B and A. They all have their characteristics, but in general one can say that the lower the letter in the alphabet, the weaker the algorithm and the more easy (and faster) it is to crack the hash created by that algorithm.

How does this cracking work?

There are many, many ways to crack passwords, but for now we will focus on offline brute forcing passwords. In simple words; Generating password hashes for all possible passwords and compare them to the SAP extracted hashes to see if there is a match. Good to note here is that this is done OUTSIDE the SAP system, so there is no direct connection to an SAP system needed.

As said before, password cracking is an art in itself and there is a whole world to discover. I will not go into detail as there are tons of sources on the internet on password cracking. Some examples here, here or here.

Important to mention is that, with tools supporting GPU’s, the processing power is MUCH higher than it used to be with traditional CPU’s. Therefore the TIME needed to crack passwords is dramatically LOWERED and the RISK your SAP passwords might get compromised in a reasonable short time is HIGHER than it was before.

A practical example:

In my test lab I have set up a simple test environment on a rather standard desktop with a GPU card I had spare (used for bitcoin mining when that was still profitable with GPU’s). This is a rather old card I bought 2 years ago for around 200 Euros, but they can be purchased second hand for much less nowadays.

The installation of OCLHashcat is simple, install the needed GPU drivers, download OCLHashcat and you are ready to go. See for more information the website.

To demonstrate the tooling, I did two runs, one for the Bcode hashes and one for the Gcode hashes. As input I used a download from the USR02 table. The input file needs to have the hashes in the following format:


Where the username in this case is TEST, followed by a $-sign and then the hash itself. In this example I used a file with several users and hashes, each on a single line. To run the tool in brute force mode you can use this command:

# oclHashcat64.exe –m 7700 –a 3 input_bcode.txt

Where “-m 7700” stands for the Bcode algorithm (Gcode=7800), “-a 3” means a brute force attack and “input_bcode.txt” is the file with Bcode hashes. The current processing is displayed on the screen:

In the screenshot it can be seen that the tool is currently brute forcing passwords with a length of 7 characters, the ones with passwords of 1-6 characters are already tried. In this example that only took several minutes. Depending on the speed of your GPU the total range of all possible passwords for the Bcode algorithm can be brute forced in less than a week time. Important to notice is that this only brute forces the first 8 characters, so if your passwords are 10 characters you will miss the last 2 characters.

After only 24 hours of brute forcing I managed to retrieve more than 75% of the passwords, many of them were 8 characters long. The remaining part would take several days, but as I already retrieved many passwords this was not necessary.

All retrieved Bcode passwords are converted to upper-case as there is not case-sensitivity in this algorithm. However, with the use of password-rules and the Gcode password hashes you can quite easily brute force the remaining characters and case-sensitive part.

Another thing to mention is the use of parameter login/password_downwards_compatibility. Depending on the value of this parameter you can use the brute forced Bcode password to logon due to backwards compatibility.

After brute forcing the Bcodes hashes, I did a similar attempt on the Gcode hashes from my USR02 table. This is a slower algorithm as can be seen by the  SPEED of ~2100 kH per second (A factor 6 slower than the Bcodes algorithm):


Brute forcing Gcode hashes is slower than the Bcode equivalent, so in case you have access to both hashes, a hybrid attempt would be more efficient where you first brute force the 8 characters via the Bcode and brute force the remaining characters (if any) and the case-sensitive part via the Gcode.

Ok, great stuff, but how do I protect myself against this?

Some counter measures that can be taken are:

  • Regularly attempt to brute force the password hashes of your users to test how strong they are (you probably need approval for this!)
  • When making use of Single-Sign-On you can probably delete the password hashes. Delete them from tables USR02 and USH02.
  • Set parameter login/password_downwards_compatibility = 0 (this might break communication with systems older than 7.0, check carefully)
  • Use a recent password hashing algorithm, see parameter login/password_hash_algorithm
  • Delete old hashes, see ABAP report CLEANUP_PASSWORD_HASH_VALUES
  • Choose strong passwords (enforce them via policies) via the password parameters
  • Limit access to tables with password hashes like USR02, USH02


For more information see following SAP Notes and other material:

You must be Logged on to comment or reply to a post.
  • New installations should be incompatible with this, but a real pain is that SOLMAN is mostly the CUA and that only supports 7.02 maximum and if you still have a 7.00 or lower hanging around then you have to live with some risk.

    Thinking about the options, downward compatibility = 0 is the only real option against someone with very simple access in those releases.

    Thanks for the infos about the report to delete old hashes. USH* tables are dead anyway. Away with them..



  • Hi,

    has anyone played with increasing number of iteration for iSHA1 using parameter login/password_hash_algorithm? The default is 1024 iterations which seems reasonable but I would still like to see SAP implementing KDF such as bcrypt or scrypt instead of iterating standard hash function.



  • Great article and great advice.  Thanks for posting this.  I note the last countermeasure in "how to protect myself":  Limit access to tables USR02 and USH02.  From the ABAP level, assuming we aren't giving wide-open SE16 or SE38 style authorizations to those who really don't need it, are there many risks of 'general' users gaining access to these tables?  From the database level, no one other than the application service account and DBA should have any access at all, so this definitely highlights the importance of protecting that service account and limiting direct database or OS access.



    • Kindly also notice the other recommendations provided in note 1237762:

      • prevent the usage of primitive passwords by setting up suitable password rules (but don't over-react, forcing users to use passwords they cannot memorize and have to write down ...)
      • remind your users not to use the same passwords in various systems (even though you cannot prevent this, but still should give that advice)
      • read note 1458262 and set login/password_downwards_compatibility = 0 whenever possible and run report CLEANUP_PASSWORD_HASH_VALUES
      • consider to increase the number of iterations (note 991968), e.g. to 10.000

      So, even if an attacker manages to copy the password hash values, he'll then have to use brute force attacks (assuming that dictionary attacks will not succeed since primitive passwords are not used), cannot use rainbow-table attacks (due to random salting) and will be slowed down by the high number of iterations required to calculate a reference hash value.

      Regards, Wolfgang

    • Matt,  You're right, most companies do give access to SE16 et al.

      I found the only reliable way is to ensure that all roles that users get, contain a restricted S_TABU_DIS authorisation.

      Also, standard SOD practices generally dictate that security and security of security is handled by a different set of administrators to those that look after the SAP application system.  Meaning, BASIS/DBA guys should not have access to USR02 or USH02, or even un-audited DBA level access (as SYSDBA for example).  It is very difficult to police and even harder to enforce.  Especially in small companies.

      I've got a brief blog entry here:  Musings of an IT Implementor: HowTo: Hide SAP tables including USR02 on how to lock down the tables and some other posts (visible here) on how to lock down other aspects (such as remove "replace" in debug).


      • Nice blog post, Darryl, but isn't USR02 already protected by authorization group SC by default?  This same group also protects the various ADR* tables, the HRP* infotype tables, the other USR* tables, and many others, so it's not very exclusive.  I can see the motivation to give the USR tables their own separate auth group, but would that hurt any system-internal functionality?

        As for SOD practices, you're absolutely right, in a small organization it's often simply not financially feasible to have that many staff to make that many separations.  In the US, Sarbanes-Oxley laws mandate such separations for financial and IT security roles in publicly held companies (those traded on the stock exchanges, in other words), but those laws don't apply to non-public companies, nor to public sector organizations.

        • Thanks Matt.

          The original post was based on some work I did on an R/3 4.7 landscape 😥 .  I haven't checked, but like you've highlighted, later SAP releases may have included some auth groups with the USR* tables et al.
          The idea with using something high in the alphabet range like ZZ, is that it's relatively easy to exclude the auth groups using a range based exclusion.  i.e. only include auth groups A*-ZY*.  You don't need to mess about including multiple ranges like A*-SD* + SE*-Z*.

          Adding new auth groups doesn't hurt any system functionality.  They are only effective when you use them to add/exclude them through S_TABU_DIS (and other auth objects) in roles that are assigned to users.

          Creating your own auth groups is recommended if you need to customise the standard ones, instead of modifying the standard ones.

          You're also not likely to have your custom auth groups changed during an SAP upgrade, but the standard ones might do, maybe excluding additional tables that you thought should be available to the user.

          At the end of the day, it's your preference.

          I think with regards to SoX; the very recent eBay hacking case only serves to highlight that SoX (and SOD) is good for security, and this is important for safeguarding not only financial, but customer master data too.

  • I'm under the impression that unless you're using SNC to encrypt your network traffic between SAP GUI and the SAP instance, then the hash is sent in the clear i.e the hash is visible in a packet sniffer because the SAP GUI performs the hash and sends it for validation at the server when logging into SAP.
    Would be good if you could confirm this...

    • Wrong. The password is compressed using a GUI algorithm and sent accross the network to the server, which uncompresses it (so two way...) back to clear text within the login program and then 1 way hashes it and compares the hashes.

      The hashing is always on the server side.

      As the compression is reversable, SNC makes even more sence than had it really been the hash...



      • Yes, totally agree on that Julius.

        And Darryl, this SAP compression is totally public, tools like wireshark have plugins. Search google for Dennis Yurichev+SAP Diag, and you will find the information.



        • I'm going through the P_ADMSEC_731 training and I've just thought of a question...

          Scenario:  You have multiple SAP ABAP landscape, which is managed with CUA.
          Let's say that you changed the password for a user account in a CUA child system, from the CUA master.

          Does the CUA master transmit the hashed password to the CUA child system?

          Thanks again.