import { LicenseInfo } from '#mui/x-data-grid-pro';
LicenseInfo.setLicenseKey(
'x0jTPl0USVkVZV0SsMjM1kDNyADM5cjM2ETPZJVSQhVRsIDN0YTM6IVREJ1T0b9586ef25c9853decfa7709eee27a1e',
);
Should the key be a secret?
No, the license key does not need to be a secret. The only thing asked is not to proactively share your key to others.
http://mui.com/components/data-grid/getting-started/#security
Related
I'm following this guide to update Github's dependabot secrets using their newly released API.
There's a part that says I need to encrypt my secret value using a public key
...
const key = "base64-encoded-public-key";
const value = "plain-text-secret";
// Convert the message and key to Uint8Array's (Buffer implements that interface)
const messageBytes = Buffer.from(value);
const keyBytes = Buffer.from(key, 'base64');
...
My question is, where does this public key come from? I don't recall setting up any keys when configuring dependabot for my repo.
Looking through the dependabot API docs I realized there's also an endpoint to get your repository's public key which gives you the public key to be used. I missed it initially.
How to create a valid key for azurite storage explorer, when I give some random alpha numeric values, it's failing saying not a valid base64 value
can you provide some more details on the scenario you are trying to address?
The storage emulator will default to the standard dev account key see:
https://github.com/Azure/Azurite#storage-accounts
If you want to use a different key, you need to replace the account key with a valid base64 string, found in the constants.ts files, one per API.
You can see how it is done in the code :
export const EMULATOR_ACCOUNT_KEY_STR =
"Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==";
export const EMULATOR_ACCOUNT_KEY = Buffer.from(
EMULATOR_ACCOUNT_KEY_STR,
"base64"
);
Is it possible with any secret engine to have a "single use" password?
I have a command that generates an rsa keypair for users, and would like them to retrieve their private key. I can obviously print it out, or write to file etc, but thought it would be nice if it was stored in a "single use" place in vault? Then the user could retrieve it via the UI, and know that no-one else has viewed it. If someone else viewed it they would need to regenerate.
Basically can we have a vault key that can only be read once?
You can create a policy that only has access to that secret, for example
# policy: rsa
path "secret/rsa" {
capabilities = ["read"]
}
and then create a wrapped token for that policy, for example
$ vault token create -policy=rsa -num_uses=1 -wrap-ttl=120
Key Value
--- -----
wrapping_token: s.9QFJ8mRxGJD0e7kFfFIbdpDM
wrapping_accessor: S0zKNUr2ENbnCtj0YyriO31b
wrapping_token_ttl: 2m
wrapping_token_creation_time: 2019-12-17 09:45:42.537057 -0800 PST
wrapping_token_creation_path: auth/token/create
wrapped_accessor: VmBKXoc19ZLZlHGl0nQCvV6r
This will generate a wrapped token.
You can give that to your end user and they can unwrap it with
VAULT_TOKEN="s.3Kf3Xfn58Asr3bSDkRXATHrw" vault unwrap
which will generate a token.
With that token, the user will be able to login to vault and retrieve the rsa creds only once since the token will be invalid afterwards.
You can now guarantee that the creds have only been used from the target user as the wrapped token can be unwrapped only once.
Note: you might need to adjust num_uses when you create the token if your end user goes through the UI as the UI might use the token to perform more than one actions.
more info
In my form it showing my policy and x-amz-credential, x-amz-alorithm, x-amz-signature, my bucket, etc...
data-form-data = "{"key":"/uploads/temporary/<some random numbers/letters>/${filename}",
"success_action_status":"201",
"acl":"public-read",
"Content-Type":"image/jpeg",
"policy":"<bunch of random numbers/letters",
"x-amz-credential":"<your-access-key-id>/<date>/<aws-region>/<aws-service>/aws4_request",
"x-amz-algorithm":"<some random numbers/lettering>",
"x-amz-date":"<some random numbers/letters>",
"x-amz-signature":"<some random numbers/letters>"}"
data-url="https://<bucket-name>.s3.amazonaws.com"
data-hose="<bucket-name>.s3.amazonaws.com
Yes, that's fine. It's designed not to expose sensitive data, and this data isn't sensitive.
Your AWS Access Key Secret is the only value that is secret and must not be revealed. (There's also a sensitive intermediate value called the signing key that's generated from the secret, which you won't see unless you wrote your own V4 request signing code). The signature is derived from the signing key and other request parameters; the signing key is service and region specific and is derived from the secret and used in your code, then discarded... and both of these values are generated using in a one-way process that makes it computationally infeasible to reverse-engineer.
I'm reading PKCS 11 documentation, and I can not understand cleary, what does CKA_SENSITIVE attribute of a key means.
And more common: where can I read attributes description?
Quote from PKCS#11 spec v2.20:
If the CKA_SENSITIVEattribute is CK_TRUE, or if the CKA_EXTRACTABLE
attribute is CK_FALSE, then certain attributesof the secret key cannot be revealed in
plaintext outside the token. Which attributes these are is specified for each type of secret
key in the attribute table in the section describing that type of key
In general this means that the actual value of the secret key is not exposed. It depends on the key which attributes make up the value. For secret keys it is generally CKA_VALUE, for private RSA keys this would be CKA_PRIVATE_EXPONENT and the Chinese Remainder Theorem parameters - if those are part of the key.
I found out that if CKA_SENSITIVE = FALSE, then the clear value of the key (for secret keys) can be retrieved by the C_GetAttributeValue function, while you cannot retrieve the value itself if CKA_SENSITIVE = TRUE.