SAPGUI 7.10 Transmission of password in clear text

[Former Member]

I have been trying to ascertain if the password when logging on to a SAP system is sent in clear text over the wire. There is documentation relating to salt and SHA-1 hashing of the password however it is not clear if this is used when stored. Is there any documentation which provides clarity for this with regards to version 7.10 of SAPGUI.

[Former Member]

Depends on your connection. when you use SSL the encriptions is based on that! Same goes for SNC.

Go to SAP Course ADM960 and learn how it works

[jurjen_heeck]

>

> Go to SAP Course ADM960 and learn how it works

Auke, I think you're cutting corners here. I followed that course, even passed C_TADMSEC_04 but still think it is a valuable question which deserves an answer (and I do not have it). Looking at yours, am I right in thinking that the GUI will transmit the password in plain text so one will have to protect the connection/communication between the PC and the SAP system to avoid it being sniffed?

[tim_alsop]

Jurjen,

No, password is not transferred in clear text, but it is certainly not very strong protection. I don't think SAP will tell us how exactly they try to protect the password because if anybody is concerned about thsi they are told to use SNC to solve their issues.

I was even told by somebody a few years ago that SAP GUI just "encodes" the password so that it is not obviously clear in network traces. This is not strong security, so if strong security is requried then SNC is the answer.

Thanks,

Tim

[jurjen_heeck]

>

> I was even told by somebody a few years ago that SAP GUI just "encodes" the password so that it is not obviously clear in network traces.

That was what I wanted to know. Thanks!

[Former Member]

I feel that you are missing the point, it is possible to wrapper this using additional technology for example using saprouter install and then tunnelling via SNC to another saprouter to encrypt the transmission, but who whats to install SAP router on every workstation.

If I were using the Web SAPGUI I'd understand the reference to SSL.

I am trying to acertain the level of risk associated with the logon process for Windows SAPGUI version 7.10 and I would doubt that a public course could answer this question and I feel it might just be a tad basic for me.

[Former Member]

This is my concern it is not clearly documented so I would advise caution with regards to the statement that the password was encoded as I believe this is something that version pre 6.4 did and this has changed. Though you can see I am having difficulty clarifying this.

[tim_alsop]

George,

I agree with the reference to the course, but I think you are not understanding how SNC would be used in this scenario. I know that SAP Router supports SNC, but I am not discussing this - SAP Router is not the only software from SAP that uses SNC, but might be the only software you are familar with ?

I am refering to the fact you can install a library on each workstation such as that shown in example at [this site|http://www.cybersafe.com/d2] and install an SNC library on each SAP systems, then you can use SNC to authenticate the user when they logon to SAP system and no need to use SAP Router.

Yes, for webgui SSL might help, but you can also stop passwords being transmitted for webgui and SSL is then not required to avoid password transmission.

Thanks,

TIm

[tim_alsop]

>

> This is my concern it is not clearly documented so I would advise caution with regards to the statement that the password was encoded as I believe this is something that version pre 6.4 did and this has changed. Though you can see I am having difficulty clarifying this.

I think you will unlikely get more info on this than you have already found, unless you were to get SAP engineers to provide you with more details on exactly how the code works - I think SAP will not provide that level of detail. Especially since they provide a solution, which is SNC !

[Former Member]

I can see the difficulty with this, I am not looking for a solution which encrypts the password in flight which there are various from SAP and third parties. Just trying to clarity that the password is not clear text or encoded in flight for the logon process.

I have been careful with the terms encoding and hash on the basis that encoding allows provides a function where the data can be recovered in its original form, where as a hash is one way. BASE64 is an encoding, whilst MD5/SHA-1 is a hash and deemed "secure".

[tim_alsop]

George,

Thankyou for clarifying your need.

Clearly from the information you have found the password is hashed using either MD5 or SHA-1 depending on which version of SAP software you are using.

It should also be clear that the password is never transmitted in clear, only hashed.

I am sorry that I introduced the word 'encoding' into this discussion, but this is what I was told many years ago - maybe old SAP software used different method, but modern releases seem to be using MD5 or SHA-1, which as you say is one-way.

So, with above in mind, I am not clear if you have any other questions, or if you still need to clarify something ? If you are satisfied then I suggest you mark this thread as answered and award points, but if you feel something needs to be clearer let us know.

Thanks again,

Tim

[tim_alsop]

>

> I am not looking for a solution which encrypts the password in flight which there are various from SAP and third parties.

The solutions you refer (e.g. those that use SNC) to DO NOT encrypt password in flight. Instead, the products use GSS-API so that a GSS Token is sent across network, and decrypted by the SAP server using a secret key. After decryption, the token contains the externally authenticated identity of the user at workstation. So, the server does not need a password, so password is not sent to server.

[WolfgangJanzen]

>

> It should also be clear that the password is never transmitted in clear, only hashed.

Sorry to interfere, Tim, but this is wrong.

When the password is transmitted (from the client to the server) it must be possible to retrieve the cleartext password at the server side - however hash functions are so-called one-way functions.

While being transmitted, it could (and should!) be encrypted. This can only be achieved by using SNC and when using the proper QoP (Quality-of-Protection) level (here: "confidentiality"); notice: not all SNC products might support that QoP (e.g. the NTLM wrapper provided by SAP does definitely not provide it).

At the server side the password is stored as hash value - and when validating the password the same password hash algorithm (which is denoted in the user master record) is used to calculate a hash value which is then compared with the hash value stored in the user master record. The comparison is not performed on the cleartext level - actually the server is unable to retrieve the cleartext password from the user master record (which is a major security feature).

All that is documented in [SAP Note 2467|https://service.sap.com/sap/support/notes/2467], [SAP Note 66687|https://service.sap.com/sap/support/notes/66687] and [SAP Note 1023437|https://service.sap.com/sap/support/notes/1023437].

[tim_alsop]

>

> >

> > It should also be clear that the password is never transmitted in clear, only hashed.

>

> Sorry to interfere, Tim, but this is wrong.

I always appreciate your help, and there is no need to say sorry for helping. Anyway, why is above statement wrong ? Are you suggesting that the password is in fact transmitted in the clear ? Surely not ?

> When the password is transmitted (from the client to the server) it must be possible to retrieve the cleartext password at the server side - however hash functions are so-called one-way functions.

Why does server need cleartext password ? Surely the server compares the hash received from SAP GUI client and compares with hash in database, and if they match it knows the password entered is correct. Isn't this how it works ? Or, are you suggesting that cleartext password is sent by SAP GUI during logon and not hashed ?

> While being transmitted, it could (and should!) be encrypted. This can only be achieved by using SNC and when using the proper QoP (Quality-of-Protection) level (here: "confidentiality"); notice: not all SNC products might support that QoP (e.g. the NTLM wrapper provided by SAP does definitely not provide it).

What ? Are you suggesting that when SNC is enabled, passwords are then transmitted encrypted ? This is very strange because when SNC is enabled, there are no password transmitted, instead SAP GUI uses GSS-API to setup a security context with the SAP server using its SNC name, and the GSS-API standard dictates that the user has already authenticated before GSS-API can be used. e.g. user authenticates, and then the GSS-API library is able to establish a security context using credentials from the already authenticated user, and this context is used to construct a GSS token, that is sent to server to be accepted - So, at no time is a password sent across network when using SNC, but you suggest that a password is sent and SNC is used to encrypt the password - this is wrong, I am afraid.

> At the server side the password is stored as hash value - and when validating the password the same password hash algorithm (which is denoted in the user master record) is used to calculate a hash value which is then compared with the hash value stored in the user master record. The comparison is not performed on the cleartext level - actually the server is unable to retrieve the cleartext password from the user master record (which is a major security feature).

Yes, exactly. This is what I said above, but you said that a disagreed with me when I said that the password is never transmitted in the clear. See top of this reply to your post. So, can you tell us how the password is encrypted ? Surely it is just hashed by SAP GUI so that it can be sent to server and server compares the hash against hash in db, and there is no need to send any encrypted or other form of the password to the server ?

Thanks,

Tim

[WolfgangJanzen]

>

> Are you suggesting that the password is in fact transmitted in the clear ? Surely not ?

No, I'm not suggesting this, of course.

But I just want to emphasize that neither the password nor any other data is encrypted while being transmitted (unless using SNC with a proper QoP level, respectively using SSL for http) - although it's not really plaintext. When talking of encryption I'm referring to cryptography - and as you definetly know, cryptographic software is (unfortenately) subject of export control. For this reason we cannot simply ship it with the product.

> Why does server need cleartext password ? Surely the server compares the hash received from SAP GUI client ...

No, the client cannot calculate the password hash - only the server can. Otherwise the client could simply sent the hash value which is stored in the user master record (after somehow getting hold of it). As I've mentioned previously: you cannot retrieve the cleartext password out of the password hash value - so, if you only have the hash value you'll not be able to logon to the server. You need to know the cleartext password, present it to the server which will then calculate the password hash value and compare it with the one stored in the user master record.

Well, using SNC, there is actually no need to send any passwords over the network connection - since the authentication (at the server) is then no longer password-based. As you definetly (but others maybe not) know, SNC offers 3 different QoP levels:

- authentication

- authentication + data integrity

- authentication + data integrity + data encryption

So, even with the lowest Quality-of-Protection level SNC already provides the SSO capability (making passwords obsolete).

Cheers, Wolfgang

[tim_alsop]

>

> >

> > Are you suggesting that the password is in fact transmitted in the clear ? Surely not ?

>

> No, I'm not suggesting this, of course.

ok good. I think we are clear on this now - I thought you were suggesting it was, because when I said it wasn't you commented on it, and said I was wrong ... I think I must have taken your comment too literally.

> No, the client cannot calculate the password hash - only the server can. Otherwise the client could simply sent the hash value which is stored in the user master record (after somehow getting hold of it).

Hmm. I guess I had overlooked that - thanks. It is my fault for responding to SDN posts late at night after having a few drinks My brain was not functioning 100%

>As I've mentioned previously: you cannot retrieve the cleartext password out of the password hash value - so, if you only have the hash value you'll not be able to logon to the server. You need to know the cleartext password, present it to the server which will then calculate the password hash value and compare it with the one stored in the user master record.

ok, so back to the question that this thread concernes - how is password transmitted. We have so far established that the password needs to be sent. We know it is not sent in clear and we know it is not sent encrypted. So, can you explain how password is sent by SAP GUI to server ?

> Well, using SNC, there is actually no need to send any passwords over the network connection - since the authentication (at the server) is then no longer password-based. As you definetly (but others maybe not) know, SNC offers 3 different QoP levels:

>

> - authentication

> - authentication + data integrity

> - authentication + data integrity + data encryption

>

> So, even with the lowest Quality-of-Protection level SNC already provides the SSO capability (making passwords obsolete).

Yes, this is correct. I also mentioned this (perhaps not in so much detail as yourself) earlier in this thread.

[WolfgangJanzen]

>

> ok, so back to the question that this thread concernes - how is password transmitted. We have so far established that the password needs to be sent. We know it is not sent in clear and we know it is not sent encrypted. So, can you explain how password is sent by SAP GUI to server ?

Actually, this should simply not happen.

If you establish a SNC-enabled SAPGUI connection then SNC is used for user authentication - the SAPGUI logon screen will not provide any input field for passwords.

Well, passwords are not the only data which is worth to be protected ... - so, using SNC with the highest QoP ("confidentiality") will ensure that the entire communication (including all application data, such as payroll data, etc.) will be protected by encrypting the data which is transmitted.

[tim_alsop]

>

> >

> Actually, this should simply not happen.

> If you establish a SNC-enabled SAPGUI connection then SNC is used for user authentication - the SAPGUI logon screen will not provide any input field for passwords.

I think you are not clear on the question being discussed in this thread. George is not using SNC. The only reason why SNC is mentioned in this thread, is that when SNC is used there is no password transmission, so it is a way to address the concerns he has about password transmission.

Clearly the password is transmitted when a user logs on without SNC, and George just wants to know how this password is protected. So far, we have established that it is not encrypted and not sent in the clear, so how is it protected ?

I believe George is looking at this from a risk point of view, so if he can understand how off-the-shelf SAP GUI sends passwords he can perhaps justify using an SNC product to improve the security, or perhaps he might be satisfied with the security of the password without SNC and continue using SAP GUI as-is.

[Former Member]

My understanding of this is: the server has an algorithm, which is not the same one as the hash mechanism. When you logon with a password, the SAP GUI logon screen for that server compresses the password using the algorithm and sends is down the wire to the server. The server has the corresponding algorithm to decompress the string into a form which makes it internally available to the server to be hashed using the same hashing mechanism used by SU01 when setting the password. If the hashes are the same, the logon is successfull and the server attaches a GUI session if it is a GUI capable user.

This means that neither the hash, nor the hashing mechanism, needs to be sent accross the wire, nor the plain text password.

Of course, this does not mean that someone cannot find the decompression algorithm... that is why it is protected and reacts badly if the program which protects it is changed... a change which is required to display the algorithm.

So it is neither encryption, hashing nor plaintext which goes accross the network... it is a trick, which kicks out and locks the ID if you try to find it, and prevents ALL logons if you try to change it.

My best guess,

Julius

[tim_alsop]

Julius,

Thankyou for explaining. The fact that "the password is compressed" by SAP GUI and sent to server is what George wanted to get confirmed, but whilst getting to this we got a bit "sidetracked" discussing other related issues, such as hash algorithms, SNC etc. All very relavent, but not answering the question asked by George.

George, do you have any more questions or feedback ?

Take care,

Tim

[Former Member]

Hi Tim,

Yes, I also think that the hashing and other topics confused the question.

I can however not confirm this, as you implied above, as I am no authority on the topic and only contributed based on some things which I read, heard and observed.

As Wolfgang has indicated, which is probably as authoritative on this topic as it will get at SDN, not sending the password in whatever form is the alternative.

Have a nice weekend,

Julius

[WolfgangJanzen]

>

> ... the SAP GUI logon screen for that server compresses the password using the algorithm and sends is down the wire to the server. The server has the corresponding algorithm to decompress the string into a form which makes it internally available to the server to be hashed using the same hashing mechanism used by SU01 when setting the password. If the hashes are the same, the logon is successfull and the server attaches a GUI session if it is a GUI capable user.

That explaination comes close to what is implemented.

Yes, the so-called DIAG protocol (used by SAPGUI to communicate with an ABAP server) offers the capability to compress data (same as actually also http allows data compression). That does not only apply to passwords but in general to all Dynpro fields. Actually, SAPGUI is not treating password fields somewhat special - they are just ordinary "hidden input" fields (i.e. what you type-in shall not become visible, comparable to HTML FORM fields of type password, which actually can also be used for other purposes; notice: that only has an impact on the visibility (at the browser) but no impact on the data transmission (with regards to data encryption)).

Yes, call it "data compression" - and it should be clear that it's neither plaintext nor encrypted data.

Cheers, Wolfgang

PS: this is no official statement - I'm only expressing my personal opinion

[Former Member]

Guys,

Thank you all for your valuable contribution to my question and in summary the opinion is:

The SAPGUI Client encodes/compresses the password before passing it on to the server

The server decodes/decompresses the password, runs a SHA-1 hash with salt and compares the result with the master record.

I have awarded points as required.

[tim_alsop]

George,

I think you will find that any SAP customer who uses SAP GUI and is concerned about network security will be told by SAP, or SAP consultants to consider implementing SNC. The standard SAP GUI network security is "not good", and this is why SAP developed the SNC interfaces. With SNC authentication/security, and SAP GUI, the GSS-API standard is used so that a cryptographic security context is established, and this context is used by the SAP server, to determine the user who authenticated at the workstation. I am not sure how familiar you are with these standards, so to avoid confusing you - the main point is that passwords are not transmitted in any form, not even encrypted passwords when SNC is used with SAP GUI.

In addition to providing improved authentication (e.g. no passwords are transmitted, authentication is mutual), with SNC you can also enable data integrity, and encrypt the network communications, but these are optional. If you encrypt the communications then application data is not sent over network. At moment (without SNC) people can use products such as Ethereal or Wireshark (which are freely available on internet) and can capture traffic sent between SAP GUI and a SAP system and look at data as well as passwords ...

Thanks,

Tim

[Former Member]

Thanks,

I found this yesterday which has prompted my question:

This section provides a general overview of logon and password security in the ABAP System. To increase the security of the passwords, they are encrypted, and are only stored and transferred as hash values.

After SAP NetWeaver 6.40, the password hash algorithm will be changed from MD5 to SHA-1. This means that more secure hash values, which are not backward-compatible, and which make reverse engineering attacks difficult, can be generated. By default, new systems generate two hash values: a backward-compatible value and a new value. However, you can configure the system so that only the new hash value, which is not backward-compatible, is generated. You can set the degree of backward compatibility with the profile parameter login/password_downwards_compatibility.

The system can determine the type (new or old) of the current user password at any time. During logon, the system calculates the password hash based on the entered data and in accordance with the information from the user master record (see the hash procedure used) and compares the hash values. The system decides itself which part of the entered password is evaluated.

● If the user master record shows that the user’s password was encrypted with the old password hash algorithm, the system only evaluates the first eight characters and converts these to upper-case

● If the user master record shows that the user’s password is encrypted with the new password hash algorithm, the system evaluates all characters as they were entered (up to 40 characters, with no conversion to upper-case).

The new functions do not initially have any consequences after the upgrade; the operation of the system and password queries continue to run as usual. The passwords of the new type gradually replace the passwords of the old type.

If your security requirements mean that you need to use exclusively the non-backward compatible passwords of the new type, this affects the following elements:

● Communication frameworks (RFC, ICF) that transfer or store the passwords

● Central User Administration, which distributes the password hash values

If you are using non-backward compatible passwords, communication with older systems (where the older system calls the newer system) and the shared use of a Central User Administration that consists of old and new systems are no longer possible in principle (see SAP Note 792850).

I am aware various solution for the encryption of data transmissions and single sign on solutions which don't require userid/password combos. The statement above clearly states stored and transferred however I am unable to clarify the statement. I have also found documentation with regards the use of salt in terms of SHA-1 but its seems that there is no documentation on the actual logon process that I can find.

[tim_alsop]

>

> I am aware various solution for the encryption of data transmissions and single sign on solutions which don't require userid/password combos. The statement above clearly states stored and transferred however I am unable to clarify the statement. I have also found documentation with regards the use of salt in terms of SHA-1 but its seems that there is no documentation on the actual logon process that I can find.

Regarding above, the information you have found is useful. As it explains the password hash is used, but the hash algorithm changed from MD5 to SHA-1 (which is considered stronger). So, in summary there the password which is stored in SAP system and transmitted when a user logs on is hashed so that it cannot be read easily if somebody gets this information from a network trace. The idea of the hash is that it will be easy to create a hash from a known password, but not easy to determine the password if you know the hash value used. This is what I meant by "encoding" in my last msg.

Also, just wanted to be 100% clear, that SNC will not need to encrypt communications to stop passwords from being transmitted, since a security context is transmitted and no password (not even encrypted password) is ever transmitted.

Thanks,

Tim

[Former Member]

Hello George,

To my knowledge, there is a pinch of salt in the hash, some pepper in the compression and a drop of poison in the decompression.

If somebody wanted to abuse this (if possible), they would have to make a lot of noise on the server... (keyword: "monitoring" - which is recommendable anyway, also with SNC, SSO, 3rd party products...).

Cheers,

Julius