Store sensitive credentials for https connections?

[Wieprecht_Steff]

Hi!

In order to get an access token for further rest-api calls I need to call the rest-api of a non SAP Cloud System with this payload:

It requires me to send the client_secret in the payload:

lv_json_payload =
{
   "grant_type":"client_credentials",
   "scope":
        "userId":"api_user",
        "companyId":"The_Deep_Tomato_Marketing_Company",       

        "userType":"admin",
        "resourceType":"public_api",
   "client_id":"The_Deep_Tomato_Marketing_Company",
   "client_secret":"XXXXXXXXXXXXXXX"
}

In my eyes this is basically a password, because the service does not require basic authentication.

But how do I store that securely? In the code; no, in a secured customizing table; no? ... any ideas?

Does anyone have a secure solution for this scenario and the credentials I need to store in order to use it?

Best Regards and Thanks,

Steffen

[mvoros]

Hi,

Secure store is what you are looking for. Check report SECSTORE01 as an example.

Cheers

[Wieprecht_Steff]

Hi Martin,

thanks! have you used it before?

I saw that one can create a secure key that can only be read by a specified program. If I use that, wouldn't everyone who has debugging authorizations in the system be able to get that key out of the specified program?

Best Regards,

Steffen

[mvoros]

Hi Steffen,

I think your threat model is too strict. Yes, a user with access to debugger (read-only is enough) will be able to put a break point after your programs reads data from secure store and see it. But that's why you restrict access to debugger in production. I can't imagine any technical implementation when a user with sufficient debugging authorization can't recover a key. The only way to solve this is to push this out of ECC. You could do this in PI and hence there won't be need to store secret in ECC (I assume here that we are talking about ECC). but you would have same problem in PI. It would be a bit easier because you usually don't have regular users in PI but these regular users usually don't have access to debugger either. And if you want to protect against malicious developer then you have same problem.

For example ABAP AS uses secure store to store predefined password of SICF services. Again, this is sufficient to prevent users with regular access to retrieve passwords but it does not stop developer with debugger.

Martin

[Wieprecht_Steff]

Hi Martin,

Why not put the reading and sending of the secret into a macro? As far as I know one cannot debug those, not even with system debugging. If one creates the key only with reading rights for the class that exclusively handles the secret... - it would be secure, right?

Best Regards,

Steffen

[mvoros]

Oh yeah, good old macro trick. I think that there is a workaround for this but I am not sure. You could try to crash program and check variables in ST22. Anyway, it came to me that you can set up a trace for HTTP connections in SMICM that captures payloads. Hence all this protection won't prevent a malicious user from setting a trace and reading secret from a trace log.

It's really hard to protect against user with sufficient authorization and skills. You can accept the risk or move this whole thing into environment where you have more control (e.g. a simple Java app that gets a JSON document, updates it with secret and forward it to recipient of the message).

Cheers

[MichaelShea]

I talked to the developer for secure store and there is a workaround for the macro trick. It is a matter of where you set your breakpoint apparently. (Can you tell, I am not a developer?) According to him, secure store is not meant to protect you from someone who has debugging access in the system.

If you really want to be safe, rebuild your rest service as a SOA web service and use the WSSEC protocols. Rest was designed to be easy, not secure. This is why we have workarounds such as secure store in the database or filesystem.

[mvoros]

Hi Michael,

I agree that secure store can't protect against an attacker with sufficient authorization. But I strongly disagree with advice to re-build it with using WS. I assume that Steffen is calling a 3rd party API so he can't do anything about it. But the reason why I don't agree is that in this case WS are not more secure. REST based service can be as secure as WS. If WS uses username/password authentication then you have to hide it somewhere. In case of ABAP AS it would be secure store. So you have exactly same problem. For authentication based on public crypto you have to store private key somewhere. The problem here is that it's hard to hide something from a user who has sufficient authorization to switch to debugger.

Cheers

[MichaelShea]

You are correct. I was trying to be somewhat tongue-in-check, but it did not come over very well. Thank you for the correction, Martin.

[Wieprecht_Steff]

Hi Michael,

I don't have control over the service that is offered to me. It's the only available interface to the third party software that needs to be integrated.

Best Regards,

Steffen

[mvoros]

What a sick joke to propose WS as a replacement for REST based service. Also Fiori guys did not get memo. Just kidding.

Cheers

[Former Member]

REST is not for going concerns then it seems.

2nd hand car dealers, insurance salesmen and fly-by-night SAP consultants and non-ABAP developers should fair well with it for a while then.

Personally I find it more ugly that you are forced to use the secure store instead of other more secure authentication mechanisms.

You can prevent the attaching of the debugger via user type SYSTEM, some system parameters to control the debugger and even deactivate the external debugger at rdisp level regardless of authorization (escalation).

There are infact quite a lot of options there, but if the service is designed to have a lot of functional access and you get the PWD then 9 / 10 time you can do anything you want to using protocols which are permitted.

Anyway... this is the security forum so easy way does not score points on it's own... 

Cheers,

Julius