Are there any ways we can hide (encrypt) the USERNAME and PASSWORD in our REST API?

[SplunkDash]

Hello,

Are there any ways we can hide (encrypt) the USERNAME and PASSWORD in our REST API> The main reason of that our client doesn't disclose the username and password. Any help or recommendation would be highly appreciated. Thank you so much.

[PickleRick]

What do you mean by "in our REST API"? Do you need to mask/filter some part of your events?

[SplunkDash]

Hello,

Thank you so much for your quick response, truly appreciate it.

Client provides us the password to be used in REST API to access to their location, they don't want to disclose that password to us.... wanted to use/provide encrypted form of the password. How we would implement that encrypted form of password into our REST API.

[PickleRick · Accepted solution]

This is a typical security misconseption.

If there is any form of "encrypted" or however transformed form of the secret which can be used straight it effectively becomes a plaintext secret because you can use it.

Unless you use some complicated authentication mechanism like Kerberos or Oauth, you must have some form of secret to provide when logging in.

So short answer - as long as the authentication process uses some form of secret-based authentication (like service name/token or user/password), you can't authenticate yourself without providing the secret during transaction.

[PickleRick]

After giving it some more thought I think I know where this idea came from.

There are several mechanisms where you can configure authentication based on data suppliedby client, which is not the "direct" credentials used by client to authenticate - for example configuring salted password hash supplied by user (when you don't know the password itself but configure your server to accept a password which hashes to configured value) or authentication using user's private key (when the public key is placed on the server).

But the idea that client would not need to know the credentials to authenticate is the same idea mistakenly "transposed backwards". And it's often cited by people who can't properly limit access per authenticated client (or even differentiate ckients) so they're afraid of losing control of access to their environment. Unfortunately the whole premise of this idea is wrong

[SplunkDash]

Hello @PickleRick ,

Thank you so much once again, truly appreciate your support in these efforts. I think the options we are discussing here are mostly properties of REST API or the public/private keys (or cryptographic/simply hash function) rather than the properties of SPLUNK itself. We should be able to use those options to encrypt our keys/passcode. Yes, I agree with you that there might not be any magic or inbuild option within SPLUNK that can hide key/password in questions. Please share your thoughts....Thank you so much.

[PickleRick]

REST API on its own has nothing to do with authentication.

There are several ways to authenticate client with REST but most of them either use plain-text authentication data (usually sent over encrypted HTTPS channel) like HTTP Basic Auth or use token generated after a call to some form of authenticating REST endpoint. But still usually authentication data for this call is more or less in plain form.

Theoreticaly, you could authenticate and authorize user calling REST endpoint (or any other HTTP request) by client HTTPS certificate. And there are many uses where people do that. I'm not sure that in your case:

1) your client can authenticate based on certificate

2) your software used to connect to client (is it something splunk-related or are we talking completely off-topic? :-)) can use client certificate to connect to server.

[SplunkDash]

@PickleRick ,

Thank you so much again. Actually, REST API in question..... I meant end point what you mentioned....... other part of REST API end point data encryption public key/private key, I think beyond the scope of this discussion. But, I understood what you meant. Thank you so much again, appreciated.