Security Key store into constant file is secure or suggest any alternate solution? - ios

I am using AWS services to post my images and SNS services for push notification in it.
To post images on the AWS server I have the secret key & access key with me currently I am using that key from the Constant file which is a very simple and easy way to access any defined key.
#define AWS_AccessKey #"###############"
#define AWS_SecretKey #"####################"
But what my question is
is this key secure from others?
is anyone can get easily from Constant file? if YES how ?
Also, I have one more key of my encrypted database of SQLCypher so that key is also stored in my Constant file.
#define DB_KEY #"####################"
What is the best way to store our important keys? and where?
Thanks in advance.

Since the app runs on ec2 a more secure way would be to use an IAM Role attached to the instance. See: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
That way you wont have to store the AWS keys anywhere. For your SQLCypher key you could use the user data script to pass the key to your ec2 instance at first boot and store it there, so you wont have to store that in the code at least.
Generally such config is best kept in the environment.

As suggested, the best way to use AWS services from EC2 without needing long-term credentials is to assign an IAM Role to the instance (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html).
If security is critical for you, I suggest to store the SQLCypher key in AWS KMS. KMS can then be accessed by your EC2 instance using its IAM Role.

As I have investigated more in the above secret key store concern I found my solution as mention below.
Reference question to AWS for security key link: https://forums.aws.amazon.com/thread.jspa?threadID=63089
As per the above link, AWS suggests that we need to implement TVM (Token Vending Machine) based service calling to give special rights to user to upload data on S3 or upload data on S3 with a particular bucket.
TVM is a kind of token service that gives user Token valid for 12 hours to 36 hours (max) to communicate with the server.
if Token expires it will again call the service and get a new token from AWS.
The temporary credentials provided by AWS Security Token Service consist of four components:
Access key
ID Secret
access key
Session token
Expiration time
The source for the TVMs is available at GitHub for both the Anonymous TVM and the Identity TVM. By this example, we can get how to get TVM and how to use it to communicate with the server.
Anonymous TVM: https://github.com/amazonwebservices/aws-tvm-anonymous
Identity TVM: https://github.com/amazonwebservices/aws-tvm-identity
Hope this will help others who all struggling with the same security issue for storing secret key.
Full Link for AWS secret key storing: https://aws.amazon.com/articles/Mobile/4611615499399490

Related

How to secure vault_token when using envconsul

To manage the secret- I am planning to use ENVCONSUL.
As part of the envconsul setup, I have to pass VAULT_TOKEN. Now during deployment, I can pass the VAULT_TOKEN as a parameter(as suggested by hashicorp).
However- how can I keep accessing this VAULT_TOKEN securely for normal app stop/start? Because at that time, there won't be any other tool to pass that environment variable.
There are a number of ways to securely store the token:
If you use a password manager (bitwarden, lastpass, dashlane, etc) then you could store it there
write it on a piece of paper and keep that safe
don't keep the token at all - instead configure another authentication engine, and log in with that each time you need a token
store it in an encrypted file on your hard disk. In this case you still have to securely store the encryption key or password somewhere (might be more memorable though)
memorise the token (only joking)

Returning client secret in plain text from GET registration request

I was going through the OpenID Connect Dynamic Client Registration specification. Section 4.3 lists the response for a client read request in which the client secret is displayed in plain text.
While obviously the secret needs to be returned in plain text when registering the client, having to return it in plain text on read requests later implies that the secret value itself needs to be stored (likely encrypted) instead of the salted hash of the client secret.
Since client id and secret are basically the same as username/password, I'm wondering why is the spec requiring to return a secret in plain text in this response, basically going against best practices in password storage?
Passwords are a special kind of secret which are often memorized by users. Since users often re-use passwords, it is important not only to hash the passwords (to protect against reversing it), but also to salt it (to prevent rainbow tables from being used). Secrets such as the client_secret are usually generated from a random source and used only once. Someone who gains access from the database can therefore steal the secret, and impersonate the client, but it won't have value elsewhere.
The client secret needs to be available when a client is configured. If you are for example provisioning multiple instances of a service, you might want to dynamically obtain the client configuration including the secret when you are deploying the application.
To recap, there is a different risk model, the secret is assumed to be random and used only once, whereas passwords are often reused. The secret is supposed to contain enough entropy to protect against a brute force attack, passwords are often shorter or from a dictionary.
There is also a use case for making the secret available many times without needing to change already provisioned clients.

Is there a possibility to automate the rotation of Azure storage SAS token using PoweShell

I'm using Azure storage, for accessing it , I'm using SAS token.
I would like to know if there is a way to automate the regeneration of a new SAS token after the old one has expired.
I know there is a possibility to automatically regenerate Storage keys by using a key Vault to manage the storage account, but is this also possible for SAS tokens?
the following link explain how to rotate key automatically but I could not find anything about SAS token:
https://learn.microsoft.com/en-us/azure/key-vault/key-vault-ovw-storage-keys
in addition I found this link which explain about SAS definition, can someone clarify what is it?
https://learn.microsoft.com/en-us/powershell/module/azurerm.keyvault/set-azurekeyvaultmanagedstoragesasdefinition?view=azurermps-6.13.0
, can it help me ?
There is an azure powershell cmdlet New-AzureStorageAccountSASToken used to create an account-level SAS token.
$context = New-AzureStorageContext -StorageAccountName account_name -StorageAccountKey account_key
#you can modify the code below as per your need, like expire time, resourceType etc.
New-AzureStorageAccountSASToken -Service blob,file,table,queue -ResourceType service,container,object -Permission "racwdlup" -Context $context
The result:

Jenkins Set User API Token from file instead of generating in UI

Is there a way to set the API token of a user manually? In the UI it has a button "Change API Token" which generates the token. Instead I want to set it.
Our old jenkins server crashed and we have to create a new one. Lot of teams are using a remote trigger call similar to below one. Change in the API token impacts all these teams as they have to update their code.
curl -X POST -H "$CRUMB" "http://automation:ef*****************************d#jenkins-url.com/job/log_deployment/buildWithParameters?token=B6472A215********************
The API token in UI is 32 char long. Upon checking the file in jenkins/users//config.xml there is this property jenkins.security.ApiTokenProperty. Seems like it is possible to set this, need some direction please.
<jenkins.security.ApiTokenProperty>
<apiToken>{AQAAABAAAAAwOROgeIy1vAUUOtGIYud+70TXY0pS/pKTe7nLeO8Xtd2BDgXW1RlZ6pL9+bvDrbwHh2xBnebPJAUS3OQt8f/toQ==}</apiToken>
</jenkins.security.ApiTokenProperty>
Thanks!
Update: More info from
https://issues.jenkins-ci.org/browse/JENKINS-32776
User
passwords are stored as salted hashes (SHA-256 or bcrypt); whereas API tokens
are encrypted using an AES-128 ECB-mode block cipher, using a static key shared
among all users.
You cannot set a given token explicitly since Jenkins only stores the hash of a token.
You can, however, copy the hashed value, thus effectively copying a token.
To do this between different masters with different global encryption keys, you need to decrypt the hash of the first master and use that for setting the hash on the second master. It's probably easiest to do that in groovy.

Simperium read-only API Key allows writing to cloud

I expected when initiating the simperium instance with the read-only key that I created that my application could read from the cloud storage but not write to it. I'm still able to write when using a read-only key. Is this a bug or am I doing something wrong?
Simperium doesn't offer a readonly API key. Instead, it has the 'Default' and 'Admin' keys.
The difference between them is:
Default key is used to generate tokens for user access
Admin key can be used by your own backend, and would allow you to sync data for multiple users.
You can read more about it here (Section: 'Access Tokens and API Keys').

Resources