My developers named secrets and keys in KeyVault in such a way that you cannot determine what the key is for. I am torn between trying to have them follow our naming standards and just keeping an eternal document. Dislike unnecessary documentation. Wished there was a note field in key or secrets so I can add something there, but looks like there is not. Or am I missing something?
In your case, I think you could use Secret tags and Key tags in your keyvault.
Navigate to your keyvault in the portal -> Keys/Secrets -> select a key/secret -> set the Tags, then it will be like below.
Related
I am currently working my way into libfido2 and trying to figure out how to use wrapped private keys with it.
Yubico says in the FAQs that with YubiKey 5 unlimited key pairs can be used for FIDO U2F; however, for FIDO2 only space for 25 resident keys is promised.
Does "FIDO2" mean that resident keys are used and that FIDO2 cannot be used with (external) wrapped private keys?
If this is the case, does libfido2 offer any possibility to work with FIDO U2F and wrapped keys instead?
If so, how does libfido2 need to be configured to do this? How can I provide the library with the appropriate protected private key. At least in "fido2-assert" I don't see a way to do this when I want to create an assertion on the client.
(The function accepts four specific parameters description here, and the only one that I understand could bring the private key is the "credential id". But the name makes me doubt if my request is possible with this parameter).
I am grateful for any answer!
EDIT: In the meantime I found this link to some Solo Keys developer pages describing how it works on Solo Keys. It seems the private key is calculated on the fly - in this case credential id would work as seed for the calculation)
FIDO2 encompasses both WebAuthn (browser API) and CTAP2 (USB/Bluetooth/NFC APIs for externally connected authenticators). CTAP2 supports both client-side and server-side credentials, and specifies how backwards compatibility with U2F/CTAP1 authenticators works. Since you're working with libfido2, the CTAP documentation might be useful to understand what it does under the hood.
Client-side discoverable credentials (previously known as resident keys) are used for usernameless flows where no Credential IDs are specified during authentication. These keys are generated randomly and require storage space. Server-side credentials (non-resident keys) are represented as Credential IDs. What type of key is created is requested during the registration process but both FIDO2 standards default to server-side credentials if not specified. U2F only supported server-side credentials.
For external authenticators with limited storage space, server-side credentials are typically wrapped private keys encrypted by a single 'master' key stored in the authenticator. Since the entire state is stored outside of the authenticator this allows for practically infinite keys to be generated even with limited storage space. But it does mean that the Credential ID generated during registration must be stored on the server, and in order to generate an assertion it must be offered back to the authenticator later for authentication. In WebAuthn these Credential ID(s) are typically presented after the user is identified (e.g. via username and password) in the allowCredentials argument, CTAP2 calls this allowList.
With the terminology now (hopefully) clarified, yes libfido2 supports both types of credentials according to the assert example:
Asks <device> for a FIDO2 assertion corresponding to [cred_id],
which may be omitted for resident keys. The obtained assertion
is verified using <pubkey>.
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 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.
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
I have a Ruby on Rails App (v4.0.1 though I don't think that's relevant here) running on Ruby 2.0 and I allow users to OAuth into third party services to give me access to their data.
I have stored my application's Consumer Key and Consumer Secret in environment variables that are outside of source control.
After the last callback in the OAuth / OAuth2 dance, I have tokens for each of my users which can be used to access their information.
For their login credentials I use one way hashing to not have their passwords stored in my database in plain text, so I'm figuring I should do something similar with their tokens, but since I need to use those tokens to access their data, I need to be able to reproduce the plain text, so I'm trying to figure out what's the best way to do symmetric encryption.
I'm planning on storing my encryption key as an environment variable and then using something like https://gist.github.com/nono/2995118 to encrypt the tokens. Is this secure?
Have people used this https://github.com/reidmorrison/symmetric-encryption gem?
I'm trying to prevent myself from having to reinvent the wheel. Any tips?
django-allauth is no slacker of a OAuth(2) implementation. I'm looking at its socialaccount_socialtoken table now, and the tokens are all in cleartext. I think you are covered, because nobody could use the tokens if they stole them.
I ended up using the attr_encrypted gem - https://github.com/attr-encrypted/attr_encrypted
and I added my passphrase to my .env file so that it is not under version control.
Here's how you use it:
attr_encrypted :email, :key => 'a secret key'