API key

[u0206397]

Is an API key supposed to be secret?

Or it is just used for the REST service provider to know whose application is calling his service?

The API key can be easily retrieved/viewed when embedded in an client-side JavaScript.

 

[Rashkae]

You should never embed it in client side JS. That shows incompetent web design.

 

[u0206397]

You should never embed it in client side JS. That shows incompetent web design.

So I still need a server script to proxy the requests? Cannot directly from client browsers call REST services?

 

[davidktw]

So I still need a server script to proxy the requests? Cannot directly from client browsers call REST services?

Normally client API provides developers with both the App ID and the Secret/Key. They are meant to be used from server side, not directly from client side unless you are operating on secured client devices.

Have your client application connect to your own server side implementation to invoke the remote web services.

 

[u0206397]

Normally client API provides developers with both the App ID and the Secret/Key. They are meant to be used from server side, not directly from client side unless you are operating on secured client devices.

Have your client application connect to your own server side implementation to invoke the remote web services.

I see. Thank you. Because nowadays there are more and more people using React and Angular kind of client side framework that needs to invoke REST services, and many require the API key in the URL, or cookie. So I wonder how they handle the API keys.

 

[davidktw]

I see. Thank you. Because nowadays there are more and more people using React and Angular kind of client side framework that needs to invoke REST services, and many require the API key in the URL, or cookie. So I wonder how they handle the API keys.

The correct technique to secure the key and secret to external API services is irrelevant to what client side technology you are using. You don't store these credentials in your client side unless you have no issue sharing them with the rest of the world. You provide your own API to your own client app to access these 3rd party APIs from your server side using the provided credentials. If these credentials are means to identify you as the developing party and it is the contract between you and the 3rd party service, you don't put them insecurely on any client apps you develop.

 

[Ryuichi]

The correct technique to secure the key and secret to external API services is irrelevant to what client side technology you are using. You don't store these credentials in your client side unless you have no issue sharing them with the rest of the world. You provide your own API to your own client app to access these 3rd party APIs from your server side using the provided credentials. If these credentials are means to identify you as the developing party and it is the contract between you and the 3rd party service, you don't put them insecurely on any client apps you develop.

Good point, another question i thought of is, how can we store such sensitive details like (API Key/Secret) on the server side?

Do you happened to work with tools like HashiCorp Vault that inject the secret (for this case API Key/Secret) during run-time?

 

[davidktw]

Good point, another question i thought of is, how can we store such sensitive details like (API Key/Secret) on the server side?

Do you happened to work with tools like HashiCorp Vault that inject the secret (for this case API Key/Secret) during run-time?

Unless you are using the most recent homomorphic encryption which to date is still not a practical solution due to it's highly computational requirement, your next practical solution is to trust your infrastructure provider. Choose one that is HIPAA and/or PCI-DSS3 certified to provide the legal and technical security for at rest storage if you need such level of security. If not, host your own infrastructure yourself.

Nope I have no precedence cases working with HashiCorp Vault. Is there any reason you trust these SaSS solution more than your infra service provider ?

If you need really highly confidential and security measures, perhaps what you want is to look into HSM solutions, but my last knowledge on HSM is that it's not going to be a simple and straight forward deployment.

Generally server side storage of keys are safe enough for most general usage.

 

[Ryuichi]

Unless you are using the most recent homomorphic encryption which to date is still not a practical solution due to it's highly computational requirement, your next practical solution is to trust your infrastructure provider. Choose one that is HIPAA and/or PCI-DSS3 certified to provide the legal and technical security for at rest storage if you need such level of security. If not, host your own infrastructure yourself.

Nope I have no precedence cases working with HashiCorp Vault. Is there any reason you trust these SaSS solution more than your infra service provider ?

If you need really highly confidential and security measures, perhaps what you want is to look into HSM solutions, but my last knowledge on HSM is that it's not going to be a simple and straight forward deployment.

Generally server side storage of keys are safe enough for most general usage.

Hmmz i am looking more towards the application-side rather than infra. I seen cases (thankfully it meant for academic projects) of putting secrets (API Key, DB password) in their code configuration, so i thought if there any practice where these secrets are injected during run-time or build.

 

[davidktw]

Hmmz i am looking more towards the application-side rather than infra. I seen cases (thankfully it meant for academic projects) of putting secrets (API Key, DB password) in their code configuration, so i thought if there any practice where these secrets are injected during run-time or build.

If you meant during deployment or building process, then you simply just provide them as properties file during your building processing. Ansible, for example, provides encrypted vaults for the properties. So you can store your keys and secrets in these encrypted vaults. Even if you will to check in the codes into GitHub, they are still pretty much safe.

If you wanted these keys to be provided during runtime, you are just transferring one set of credentials for another. When you application server starts up, it will need to established a confidential network stream from the application server to the keys repository. Your application server will need to host a set of credentials to retrieve in-memory keys from the key repo. Then your application basically just startup by using the in-memory key.

What are you protecting against ? If you are feeling unsafe to store your application key and secret in the server filesystem, then what about the client keys meant to access the keys repo ? Same thing right ?

At the end of the day, you will need to trust your infra provider, which you may use encrypted filesystem or disk block, but you still need a certain level of trust. Hope you see the picture of security. Who are you protecting against ?

 

[Ryuichi]

If you meant during deployment or building process, then you simply just provide them as properties file during your building processing. Ansible, for example, provides encrypted vaults for the properties. So you can store your keys and secrets in these encrypted vaults. Even if you will to check in the codes into GitHub, they are still pretty much safe.

If you wanted these keys to be provided during runtime, you are just transferring one set of credentials for another. When you application server starts up, it will need to established a confidential network stream from the application server to the keys repository. Your application server will need to host a set of credentials to retrieve in-memory keys from the key repo. Then your application basically just startup by using the in-memory key.

What are you protecting against ? If you are feeling unsafe to store your application key and secret in the server filesystem, then what about the client keys meant to access the keys repo ? Same thing right ?

At the end of the day, you will need to trust your infra provider, which you may use encrypted filesystem or disk block, but you still need a certain level of trust. Hope you see the picture of security. Who are you protecting against ?

Well, first of all is the audit requirements , and secondly i just feel uncomfortable looking at the secrets stored in a property files.

Regarding the client keys to access key repo, i believe there are implementation based on a token with a TTL, thus probably alleviate the risk of having a permanent client keys?

Anyway i try integrating Vault with Jenkins, and will share my findings if it works as expected.

 

[davidktw]

Well, first of all is the audit requirements

So what are your audit requirements ? If your audit requirements require the use of a hardware vault like HSM, then by all means go for it.

and secondly i just feel uncomfortable looking at the secrets stored in a property files.

Be scientific here. We are not on a discussion of guts feelings. If you can agree that someone can hack thru your AES256 encrypted vault, then no security is safe If you don't want to check in your keys, then provide them manually everything you need to build, or store it in your CI system, or maybe even your LDAP system and secure them

Regarding the client keys to access key repo, i believe there are implementation based on a token with a TTL, thus probably alleviate the risk of having a permanent client keys?

TTL ? TTL is not relevant here. You need to store your client keys in the client that is accessing the key repo.

 

[Ryuichi]

So what are your audit requirements ? If your audit requirements require the use of a hardware vault like HSM, then by all means go for it.



Be scientific here. We are not on a discussion of guts feelings. If you can agree that someone can hack thru your AES256 encrypted vault, then no security is safe If you don't want to check in your keys, then provide them manually everything you need to build, or store it in your CI system, or maybe even your LDAP system and secure them



TTL ? TTL is not relevant here. You need to store your client keys in the client that is accessing the key repo.

I think TTL is relevant for my use case, probably if we have an opportunity to discuss it face to face, maybe i can articulate my scenario to you better.

Hah, how i wish i can tell that to the security people.

 

[shadey]

Hmmz i am looking more towards the application-side rather than infra. I seen cases (thankfully it meant for academic projects) of putting secrets (API Key, DB password) in their code configuration, so i thought if there any practice where these secrets are injected during run-time or build.

I use the BeyondTrust Passwordsafe with their API calls in my application. It retrieves the DB password at run time and automatically rotates it after. Can also rotate it on a schedule for high volume apps or where the db session needs to stay open.

 

[davidktw]

I think TTL is relevant for my use case, probably if we have an opportunity to discuss it face to face, maybe i can articulate my scenario to you better.

Hah, how i wish i can tell that to the security people.

Feel free to explain, why you feel TTL helps to lower the risk of exposure? Perhaps you also should add, how do you think you are securely accessing the 3rd party repo to download your operating keys for your server side software?

 

[Ryuichi]

I mean TTL not necessary lower the risk of exposure, but at least, lower the risk of unauthorizes user getting hold of the particular token, as token have to be renew after a period of time after the lease expired. It is configurable, and on edge case, it can be done that every request required a new token.

I could be wrong, but that my very vague initial understanding of how it works for accessing any secret repos using HTTP API calls.

 

[davidktw]

I mean TTL not necessary lower the risk of exposure, but at least, lower the risk of unauthorizes user getting hold of the particular token, as token have to be renew after a period of time after the lease expired. It is configurable, and on edge case, it can be done that every request required a new token.

I could be wrong, but that my very vague initial understanding of how it works for accessing any secret repos using HTTP API calls.

Lets consider who are possible perpetrators.

1) MITM attack
2) Infiltrated hacking
3) Infra service provider

1) Solved with proper SSL conduit. This requires server(client side wrt key repo service) to store the credential of the key repo in the server. This portion is *normally* lifetime credentials
2) Someone whom can hack into your server to retrieve the credentials crossing RBAC/MAC/DAC most likely will be able to get your credentials to your key repo service.
3) Someone whom can get hold on your unencrypted storage at REST will be able to perform (2) easily

Initially your concern is you feel it is unsafe to store your secret in the server, and you feel you will lower your risk if your key is only stored in memory fetched across another service, but it is not any safer since one whom can get into your system would be capable of the same level of damage.

If you want to ensure your credentials are safe, then you should reinforce your entry to your servers.

Some concepts
1) Proper IDS to detect possible breach
2) Proper handling of secrets
3) Encryption of block devices storing credentials
4) Employ much stricter process and access control such as AppArmor, SELinux.
5) Control access to your service via secured bastion host
6) Restrict network access for administration.
7) Rotate your keys periodically.

If one can get access to your service using directly or indirectly obtained credentials, that's all it matters. The keys are not the most important issue here. It's what damages one can do with the obtained access and privileges.

 

[BlackCube]

So what are your audit requirements ? If your audit requirements require the use of a hardware vault like HSM, then by all means go for it.

Be scientific here. We are not on a discussion of guts feelings. If you can agree that someone can hack thru your AES256 encrypted vault, then no security is safe


TTL ? TTL is not relevant here. You need to store your client keys in the client that is accessing the key repo.

Eh. I'm a little unclear here.

Does TS mean storing the secret key in app.properties in plaintext or ciphertext?

If stored in ciphertext, you need to decrypt it which u also needs a key to decrypt it right which makes no sense? Or am I missing a point here?

If plaintext then you need to protect your server such that no unauthorised user is supposed to access the server/file through proper control?

 

[davidktw]

Eh. I'm a little unclear here.

Does TS mean storing the secret key in app.properties in plaintext or ciphertext?

If stored in ciphertext, you need to decrypt it which u also needs a key to decrypt it right which makes no sense? Or am I missing a point here?

If plaintext then you need to protect your server such that no unauthorised user is supposed to access the server/file through proper control?

Seriously I don't know what is TS concern too. It is pretty normal to store keys and credentials on server end since these entities are normally privileged, audited and hardened. Further security can be made to encrypt block devices at rest, and using RBAC to secure access to the credentials or properties files. Employ of external keys storage is normally not necessary unless you have to comply to certain security compliance like PCI-DSS or HIPAA etc...