SAP userid password cracking tool?

[Former Member]

hi - can anyone confirm if SAP has a tool/utility they can use to crack a password - we have a situation where it is much easier for us if we could have them help us determine what a password is for an ALE user than changing it and aligning the new pwd is the many different places it is used.

i assume SAP has a tool for this, but not sure if they are willing to help customers w/ it.

i can see the hash code in usr02.bcode field for my user in question and could provide them that info...

thanks

[jurjen_heeck]

> hi - can anyone confirm if SAP has a tool/utility they can use to crack a password - we have a situation where it is much easier for us if we could have them help us determine what a password is for an ALE user than changing it and aligning the new pwd is the many different places it is used.

To avoid problems like this one have a look at trusted rfc connections. That way there is no need to store passwords.

> i assume SAP has a tool for this, but not sure if they are willing to help customers w/ it.

I doubt it and I actually hope they do not have it. How would that help customers to become sox-compliant?

Besides that hashing passwords is generally a one-way trick.

> i can see the hash code in usr02.bcode field for my user in question and could provide them that info...

Hopefully they can't do a thing with that

[Former Member]

The idea is to manage the connections by co-ordinating the passwords, both the one enetered in SU01 and the one entered in SM59.

This is much easier and more secure when you respect the cardinality of the connections, i.e. avoid MANY (sm59) to ONE (su01) connections.

Besides, in higher releases you cannot even see the SM59 hash in RFCDES anymore....

Such a publicly available tool would be predestined for misuse...

Cheers,

Julius

[Bernhard_SAP]

Hi Ben,

>

> i assume SAP has a tool for this, but not sure if they are willing to help customers w/ it.
> 

Beleave me or not:

I can confirm, that we (SAP) do not have such a tool.

Do you think, that high sensitive customers still would buy the software, if SAP could crack their passwords with a tool?

Nevertheless: any password is crackable. It is only a quesiton of which time you are willing to spend on that crack (100 years, 200 years,....).

So do not calculate with that possibility of password decryption from SAP.

b.rgds,

Bernhard

[jurjen_heeck]

>

> I can confirm, that we (SAP) do not have such a tool.

Thanks for confirming! Sigh of relief here

[Former Member]

Of course, SAP has such a tool. Not in a complete form, but the most important and hardest to write part is there. Just reflect what is necessary:

1. A dictionary. Freely available on the net.

2. The hash of the password to crack. Is in the database.

3. The seed (I assume that SAP uses a seed; previous versions didn't have a seed). Is most probably in the database as well.

4. The hashing algorithm. This is built in every SAP kernel because this is also needed to verify a password during logon and to set a password.

5. A small framework tying everything together. This is trivial and there are enough password crackers around that show somebody how to write such a framework.

Of course, trying out all password is a time consuming task that can be highly parallelized, however.

So, strictly spoken, SAP did not tie everything together. But a decent programmer at SAP has such a tool written inside a week.

[Bernhard_SAP]

>

> 4. The hashing algorithm. This is built in every SAP kernel because this is also needed to verify a password during logon and to set a password.

No, we can only encrypt, not decrypt with the hash algorithm used.

b.rgds, Bernhard

[Former Member]

I think that you have misunderstood the question...

He does not want to brute force or dictionary attack the SU01 password.

He wants to reverse the SM59 password so that he can set it in the target SU01 without "disturbing" the SM59 settings of (possibly) other systems using the same ID.

All round bad idea...

Cheers,

Julius

[Former Member]

No, we can only encrypt, not decrypt with the hash algorithm used.

Of course, otherwise it wouldn't be very useful. But there are ways around it; they are just time consuming. Please reconsider my post.

Of course, SM59 will need to store passwords with a reversible algorithm. Otherwise, it would not be able to furnish the password to the "other" server. This is just obfuscation and it should be possible to crack this (you only have to look for it long enough in the code).

[Bernhard_SAP]

Hie Sietze (I suppose that this is your first name - sorry if not),

>

> Of course, SM59 will need to store passwords with a reversible algorithm. Otherwise, it would not be able to furnish the password to the "other" server. 

we compare only the hash values during log on. So using sm59 there is no decryption for passing the password to the remote system. I don't know, where you have found the decryption coding....

b.rgds, Bernhard

[former_member1061482]

For an un-trusted RFC, the user is a background user (no dialog logon), so the password authentication seems to be taken care by the comparision of hash values (as suggested by Bernhard)..

For that matter, for a trusted RFC, where a dialog user becomes an RFC service user, it seems there isn't any password verification. Because the source system doesnot mantain any password in SM59 and the password in the destination can always be different from what the user is having in source system. At most the system would be checking if the user is locked/unlocked/validity period apart from the necessary auth objects S_RFC and S_RFCACL.

Correct me if I am wrong!

Thanks!!

[Former Member]

thanks all for a lively (much more than i expected) discussion. julius was right in my intentions...i am not trying to unearth a tool to crack passwords myself. we just have a situation w/ many SM59's using an ALEREMOTE user - and no one knows what the current password is. so if we need to create a new Source System in RSA1 for our BW system (which uses this ALEREMOTE user by default for the ALE/sm59's between systems) we either need to

1) chg the ALEREMOTE password and update all the corresponding SM59's in all the different systems

2) somehow figure out what the current password is, so we "know" what it is and can then create a new Source system connection in RSA1 and feed it the ALEREMOTE password

sounds like there is no way for us to use the latter option sadly...

thanks

[jurjen_heeck]

> we either need to

> 1) chg the ALEREMOTE password and update all the corresponding SM59's in all the different systems

> 2) somehow figure out what the current password is, so we "know" what it is and can then create a new Source system connection in RSA1 and feed it the ALEREMOTE password

>

> sounds like there is no way for us to use the latter option sadly...

1) will be your best short-term option. Please do investigate the option of 'trusted rfc' to rid your system of ale passwords completely. The problem you're facing should be a good motivation.

Jurjen

[Former Member]

BW would have been my second guess. That you are forced to have uncardinal RFC connections is in my opinion a design error in there somewhere...

My first guess had something to do with your email address which is visible in your SDN profile - you can use the option "Hide" to save it in a type of "Secure Store", which then only you can see in cleartext. (sorry for the pun

The Trusted RFC is a valid and popular solution, but you have to be very carefull in how you set it up.

Worste case everyone can logon as anybody else and per default you loose a layer of application security.... (except for DDIC and SAP*).

The thing about stuff like this (cracking passwords etc) is that anyone smart enough to find and work it out, is most likely smart enough to know that they should keep it to themselves...

Cheers,

Julius

[jurjen_heeck]

> The Trusted RFC is a valid and popular solution, but you have to be very carefull in how you set it up.

> Worste case everyone can logon as anybody else and per default you loose a layer of application security.... (except for DDIC and SAP*).

In detail: The RFC-user must have the object S_RFC_ACL with proper values in his profile on the trusting side. Luckily this is one of the objects never included in SAP_ALL.

So if you connect from system A to system B you need to have an account with identical naming on either side and must have this object in the profile on system B. Trusted RFC's can both be set up with fixed userid's and 'logon user' or 'current user' (no system in reach at the moment, don't know the exact wording). The actual rights of the rfc user on system B determine what can be done there.

The risk Julius mentiones is a bit like putting op a sticky note with the password beacuse you do not want to lose it again..... just giving everyone a 'starred-out' S_RFC_ACL on all systems and trust they do not know how to use an rfc connection.....

Jurjen

[Former Member]

> ... per default you loose a layer of application security...

> The actual rights of the rfc user on system B determine what can be done there.

That depends on how your system is configured...

There is a old thread here about that topic - the distinction between an "authentication check" and an "authorization check".

Search terms:

> In the real world, if I present my passport to somebody at an airport they are able to look at it and use it to determine my real identity, then they can decide whether I am allowed to enter the airport to board an airoplane.

=> "Somebody at the airport" should also determine which airoplane you board... (the entry points to the destinations).

Cheers,

Julius

[Bernhard_SAP]

>

> In detail: The RFC-user must have the object S_RFC_ACL with proper values in his profile on the trusting side. Luckily this is one of the objects never included in SAP_ALL.

Hi Jurjen,

just a little comment on this....

==>don't rely on that .....

Have a look at SAP note #410424 -->ADD_S_RFCACL.... I always set the switch to 'YES' to avoid problems for my sap_all users...

b.rgds, Bernhard

[Former Member]

> Have a look at SAP note #410424 -->ADD_S_RFCACL.... I always set the switch to 'YES' to avoid problems for my sap_all users...

Are your SAP_ALL "users" (a.k.a. SAP_ALL "complainers") aware than anyone on the trusted system can logon to the trusting system as them without needing nor changing the password?

Cheers,

Julius

[jurjen_heeck]

>

> I always set the switch to 'YES' to avoid problems for my sap_all users... 

Okay, I forgot the words "by default"

I never change this switch but prefer to tell the SAP_ALL users they might run in to the occasional boundary and that it's also for their safety.

Doesn't really matter because it only changes their request from "give me SAP_ALL and SAP_NEW" to "make sure I can do everything". The following discussions are all too familiar......

Nice topic!

[former_member1061482]

Last night I started thinking about this discussion, and two questions striked me. I am putting them on this forum first thing in the office:)

(1) Which table contains the hash value of the password which is mentioned in sm59-untrusted RFC?

(2)Although manual update of SAP standard tables is a bad practice. What if somebody copies the hash value of password from usr02 of destination system and updates that table (containing sm59 password) in the source system?

I would love to know what have a I overlooked!!:)

[Former Member]

It depends on which release you are on....

They are different hashing mechanisms, so the USR02 hash does not "fit into" the RFCDES hash parameter => useless.

Additionally, each time you save the password in SM59, a different hash is formed for the same password.... => so copy&paste does not work at the table level either.

However, all of this is irrelevant in higher releases. The hashes are saved in the "Secure Store Area"...

Cheers,

Julius

[former_member1061482]

Hi Julius,

Thanks for clarifying!

[Former Member]

@Bernhard: Yes, Sietze is my first name.

Is there any documentation regarding the way SM59 stores/handles passwords? The way you describe things is even less secure. Now, the hash becomes the password and that is stored in clear text in the database!

For me, the problem is most easily solvewd by using SNC. Then you don't have any passwords at all and the communication is encrypted as well.

[Former Member]

Hi Sietze,

> The way you describe things is even less secure. Now, the hash becomes the password and that is stored in clear text in the database!

I think you misread what was meant.

The SM59 hash is decrypted source system specifically, then compressed and sent to the target system, where it is decompressed and presented to the rfc login screen together with the user ID, the client and the language, where it is then hashed again (but using the SU011-way hashing mechanism) and the 2 hashes in the target are compared only (never the password).

Cheers,

Julius

[WolfgangJanzen]

>

> Of course, SAP has such a tool.
> ...
> So, strictly spoken, SAP did not tie everything together. But a decent programmer at SAP has such a tool written inside a week.

Sorry, but I'm supposed to know it better ...

Even if you have access to the source code (as I certainly do) you will not be able to invert the hash function used to calculate the password hash value. All you could do is to perform a brute-force or dictionary attack.

Well, we ourselves had this situation once before - where it did effect us (migrating [Pandesic |http://en.wikipedia.org/wiki/Pandesic]customers to ABAP systems). The answer was: no, it's not possible (All what would be possible is to intercept a validated password (as cleartext data) and then perform the migration, creating a new ABAP account with that password - provided the password complies with the ABAP password rules).

[Former Member]

Hi Wolfgang,

I am not saying that access to the source is enough to develop a function that reverses the hashing of the password. The only thing that I am saying that access to the one way function will allow you to build a tool that tries out all candidate passwords in order to find the real password.

Another way to get the one way function would be to locate it in the SAP kernel and use the function in binary form. An attacker would use this route. A SAP employee would use the source and compile the function himself.

Regarding SM59 I will need to dig a little bit more. The way you guys are describing it; it just feels very insecure.

Two links:

[http://en.wikipedia.org/wiki/Password_cracking]

[http://en.wikipedia.org/wiki/Cain_(Software)]

It is certainly possible and feasible to add a SAP module to CAIN. Perhaps somebody even did. In the security field, accomplishments are not always acknowledged. This is especially true for people with bad intentions.

Edited by: Sietze Roorda on Sep 11, 2008 1:44 PM. Links added.

[Former Member]

>

> It is certainly possible and feasible to add a SAP module to CAIN. Perhaps somebody even did. In the security field, accomplishments are not always acknowledged. This is especially true for people with bad intentions.

There is are patches for John The Ripper but as far as I know they are not "in the wild" (fortunately).

[Former Member]

>

> Regarding SM59 I will need to dig a little bit more.
> 

Just incase you were wanting to dig around in SM59, please take note that the syntax is...

CALL FUNCTION function_module DESTINATION destination...

...and not...

CALL FUNCTION function_module WHILE CALLING TRANSACTION 'SM59' IN REVERSE MODE using BDCDATA...

Both ways you will have to take loooooots of water and fresh camels with you when you set out on this task...

Good luck,

Julius

[Former Member]

Julius,

thank you very much for your information ;). The comments posted here regarding SM59 are rather intriguing, so we'll see where it ends up.

But I don't mind getting help from you, especially as you seemed to have travelled that road already .

[Former Member]

You're looking in the wrong places already (SM59 and me)...

Cheers and enjoy the weekend,

Julius

[WolfgangJanzen]

>

> Hi Wolfgang,
> 
> I am not saying that access to the source is enough to develop a function that reverses the hashing of the password. The only thing that I am saying that access to the one way function will allow you to build a tool that tries out all candidate passwords in order to find the real password.

Yes, that's called "Brute Force" (or "Dictionary Attack" if you focus on frequently used weak passwords).

That's always possible - the only countermeasure is to slown-down such trial approaches (e.g. by iterated hash calculation). In addition, salted hash algorithms should be used (to prevent pre-calculation, keyword: "rainbow table").

Please take a look on [SAP Note 1237762|https://service.sap.com/sap/support/notes/1237762], as well.

>

> Regarding SM59 I will need to dig a little bit more. The way you guys are describing it; it just feels very insecure.

Passwords which you have entered in SM59 (Destinations) are not stored as hash values but encrypted. As of NetWeaver 7.0 the so-called "Secure Store" (ABAP Transaction SECSTORE) is used (3DES encryption). In older releases a proprietary algorithm is used to encrypt the password.

[Former Member]

This message was moderated.

[mvoros]

Hi Wolfgang,

is SAP planning to introduce Bcrypt as a replacement for traditional hash functions such as SHA-1? Advantage is that it's slow because of introducing work factor. Not like generic hashing functions that are optimized for speed.

I just realized that I replied to 4 years old answer. My question is still relevant but not sure why this thread got updated.

Cheers

Edited by: Martin Voros on Feb 8, 2012 10:06 PM

[WolfgangJanzen]

As documented in [SAP Note 991968|https://service.sap.com/sap/support/notes/991968] there's a new generic password hash algorithm approach (available for all ABAP systems as of 7.02; see also [SAP Note 1458262|https://service.sap.com/sap/support/notes/1458262] on "recommended settings for password hash algorithms" for older systems).

The generic password hash algorithm is currently supporting (iterated) random-salted SHA-1 hashes.

If requested, other hash algorithms could be supported, as well. [Bcrypt|http://en.wikipedia.org/wiki/Bcrypt] (Blowfish) is currently not amongst the supported algorithms; legal aspects would need to be clarified before implementing Blowfish. On relatively short notice, SHA-256 could be offered, though.

Slow calculation might not be a disadvantage - actually SHA-1 is too fast, thus the hash calculation is iterated (preserving the password entropy) as countermeasure against brute-force / dictionary attacks.

The number of iterations, the size of the random part (bits) and the hash algorithm name can be configured for the generic password hash algorithm. Actually, increasing the iteration count and the random size is more effective than choosing a different hash algorithm. But as written above: if (for whatever reason) one feels more comfortable with a distinctive algorithm, he should submit a feature request. We'll check the feasibility to fulfill the request.

[WolfgangJanzen]

>

> we have a situation where it is much easier for us if we could have them help us determine what a password is for an ALE user than changing it and aligning the new pwd is the many different places it is used.

Well, this is the key problem:

if you use the same UID/PWD for many communication scenarios you need to synchronize any changes.

The best strategy is to avoid this:

- either use alternative authentication mechanism (such as "RFC Trusted System")

- or use dedicated UID/PWD combinations for each communication scenario