In the Kubernetes docs there is a bootstrap token which is used for Nodes TLS bootstrapping.
Wherever it is mentioned there is always the same value of 07401b.f395accd246ae52d. I haven't found much details on if that numeric sequence have some special meaning and should be precisely the same for every bootstrapped Node.
Or is that just a randomly generated magic number?
That sequence carries no special meaning. The bootstrap token is entirely random. I suspect the times that specific sequence is mentioned in documentation, it's coming from or directly copied from the same source.
Bootstrap Tokens take the form of abcdef.0123456789abcdef. More
formally, they must match the regular expression
[a-z0-9]{6}.[a-z0-9]{16}.
The first part of the token is the “Token ID” and is considered public
information. It is used when referring to a token without leaking the
secret part used for authentication. The second part is the “Token
Secret” and should only be shared with trusted parties.
https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/#token-format
If you want to test this, play around with kubeadm's token create. This will generate random tokens you can use to bootstrap nodes.
kubeadm token create
Synopsis This command will create a bootstrap
token for you. You can specify the usages for this token, the “time to
live” and an optional human friendly description.
The [token] is the actual token to write. This should be a securely
generated random token of the form “[a-z0-9]{6}.[a-z0-9]{16}“. If no
[token] is given, kubeadm will generate a random token instead.
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token/#cmd-token-create
Related
I'm trying to use the jwt-1.0 feature in Open Liberty.
The JwtBuilder API is pretty nice and allows to set expiration, sign, encrypt and build a token programmatically (and everything else needed).
JwtBuilder.create().expirationTime(expTime).signWith(signAlg, privateKey).encryptWith(keyMgmtAlg, keyMgmtKey, contentEncAlg).buildJwt().compact();
But the JwtConsuer API seems pretty lame and only allows to read a token without validation at all.
JwtConsumer.create().createJwt(token);
Signature validation and decryption should be configured through the application server configuration (via "jwtConsumer" and "keystore" entries) but it's not possible programmatically.
I should accommodate with this but other validations like expiration date are not possible.
Do I miss something?
You're correct in that the JwtConsumer API does not provide a programmatic way to set specific validation requirements. However the JWT will still be validated when createJwt() is called.
The JwtConsumer API's create() and create(String consumerConfigId) methods tie the JwtConsumer object to a <jwtConsumer> element in the server configuration that specifies the validation requirements. The configuration settings for that element can be viewed here: https://openliberty.io/docs/22.0.0.4/reference/config/jwtConsumer.html.
The JwtConsumer.create() method will use the default <jwtConsumer> configuration that is provided automatically by the runtime, which simply looks like this:
<jwtConsumer id="defaultJwtConsumer" />
Similarly, the JwtConsumer.create(String consumerConfigId) would use the configuration with the corresponding ID. So JwtConsumer.create("myJwtConsumer") would use the corresponding "myJwtConsumer" configuration in the server.xml. That could look something like this:
<jwtConsumer id="myJwtConsumer"
issuer="https://example.com"
audiences="Luke, Leia, Han"
signatureAlgorithm="RS256"
jwkEnabled="true"
jwkEndpointUrl="https://..."
/>
You'd put whatever validation settings you want in that configuration. Then when you call JwtConsumer.createJwt(token), the runtime will perform several validation checks against the JWT. That includes checking the issuer, audiences, iat and exp times, the nbf claim, and of course the signature of the token.
To expand on the answer, if a clockSkew is not specified, then a default value of 5 minutes is used. On the other hand, setting clockSkew="0m" will in effect disable the clock skew.
I am using Azure key vault for creating and storing my Secp256k1 keys. I am also using the sign API for getting my input string signed. I am working on a Secp256K1 blockchain network.These are steps I follow to get the signature in Golang.
Converting my Hex string into Byte[]
Sha256 of this Byte[]
RawURL encoding of this Sha.
b64.RawURLEncoding.EncodeToString(sha)
Sending this to Key vault for signature.
Decoding the response using RawURLEncoding.
b64.RawURLEncoding.DecodeString(*keyOpsResp.Result)
Doing Hex of the []Byte array returned from 5th Step.
Sending the signature to the blockchain.
The problem I am facing is that signature is invalid sometimes. As in 2/5 times it works and other times signature verification fails.
I am thinking there is some special chars or padding thing that I am missing.
How can I resolve this?
PS: Azure uses non-deterministic signatures where as chains usually use deterministic signs. I did some reading and found out that for verification it does not matter both could be verified successfully. Let me know if I am wrong.
• Since you are using base64 encode RawURL for encoding purposes, you can check whether the following parts are included in the token request for the keyvault signature validation. They are as follows: -
aud (audience): The resource of the token. Notice that this is https://vault.azure.net. This token will NOT work for any resource that does not explicitly match this value, such as graph.
iat (issued at): The number of ticks since the start of the epoch when the token was issued.
nbf (not before): The number of ticks since the start of the epoch when this token becomes valid.
exp (expiration): The number of ticks since the start of the epoch when this token expires.
appid (application ID): The GUID for the application ID making this request.
tid (tenant ID): The GUID for the tenant ID of the principal making this request. It is important that all the values be properly identified in the token for the request to work
• Also, please check the size of the block that is dependent on the target key and the algorithm to be used for validation of signature. In that, please check the ‘decryptParameters’, ‘algorithm’ and ‘ciphertext’ parameter for the returns that are displayed after the decrypt operation during signature validation.
Please find the below links for more details: -
https://learn.microsoft.com/en-us/java/api/com.azure.security.keyvault.keys.cryptography.cryptographyasyncclient.decrypt?view=azure-java-stable
I'm in context of managing an openId jws, and I'm not sure about how to verify the aud claim.
In details, suppose that I've an application id myapp.site.com and I receive an aud which value is myapp.site.com|*|ANY. I've not found specifications about this format, but reading the aud specification into https://openid.net/specs/openid-connect-core-1_0.html#IDToken I've supposed to explode the string myapp.site.com|*|ANY using the "pipe" as separator, and then verify if this array contains the aspected client id (ie myapp.site.com).
My question is: whatabout the * and ANY? there's some specifications about this format? where can I retrieve informations?
Thanks in advance,
Sim.
That looks like a custom thing that is not a standard that I have seen anywhere else, so I guess its up to you to parse it as it is. At the same time the purpose of the audience is for the receiver of a token to be sure the token is aimed for it and not someone else. So its a security risk to accept any token even if the signature is valid.
Are mojolicious session tokens created in a "standard" way (in a generic sense), or is this up to the individual application? If it is the former, then what is the format?
What I saw so far is a base64 encoded JSON fragment (which by itself is syntactically incomplete), followed by "---", followed by a random looking 40-digit hex-string.
I'm especially interested in the random looking token. Is it randomly generated, or is it the encoding/encryption of something?
Mojolicious session have base64 string (in the begin, first part) and sign (in the end, second part) which separated by "---".
Sign is main part of session which prevent from changes.
So, make a test:
Add to session some value. Make request which get this value in the session.
Get session and transform first part of them (make base64_decode and change value then make base64_encode and put it before "--" in cookies).
Make query to server with new cookie/session. Your new data must be invalid in session.
So, sign it is IMPORTANT part of session.
Read source code to learn more about it
Read this to know how to set secret key for sign cookies
I searched on Google and StackOverflow to find a answer to my question but I can't find one.
I'd like to store the access_token to my database for offline access and I'd like to be sure to specify the correct length of my column.
I can't even find if it's just a number or a mix between number and strings.
I work at Facebook and I can give a definitive answer about this.
Please don't put a maximum size on the storage for an access token. We expect that they will both grow and shrink over time as we add and remove data and change how they are encoded.
We did give guidance in one place about it being 255 characters. I've updated the blog post that had that information and updated our new access token docs to include a note about sizes:
https://developers.facebook.com/docs/facebook-login/access-tokens/
Sorry for the confusion.
With Facebook's recent move to encrypted access tokens, the length of the access token can be up to 255 characters. If you're storing the access token in your database, the column should be able to accommodate at least varchar(255). Here's an excerpt from Facebook's Developer blog from October 4, 2011:
"With the Encrypted Access Token migration enabled, the format of the access token has changed. The new access token format is completely opaque and you should not take any dependency on the format in your code. A varchar(255) field will be sufficient to store the new tokens."
Full blog post here: https://developers.facebook.com/blog/post/572
This answer is no longer correct, and I can't find a corrected value in FB's docs. We have been receiving access tokens that are longer than 255 characters. We're moving from VARCHAR to a SMALLTEXT instead to try to future-proof things.
From section 1.4 of The OAuth 2.0 Authorization Protocol (draft-ietf-oauth-v2-22)
Access tokens can have different formats, structures, and methods
of utilization (e.g. cryptographic properties) based on the
resource server security requirements. Access token attributes and
the methods used to access protected resources are beyond the scope
of this specification and are defined by companion specifications.
I looked for the "companion specifications" but didn't find anything relevant and in section 11.2.2 it states
o Parameter name: access_token
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]
Which seems to indicate that the access_token parameter is defined within this spec. Which I guess the parameter is but the actual access token isn't fully fleshed out.
Update:
The latest version of this writing of the specification (draft-ietf-oauth-v2-31) includes an appendix that defines better what to expect from the access_token parameter
A.12. "access_token" Syntax
The "access_token" element is defined in Section 4.2.2 and
Section 5.1:
access-token = 1*VSCHAR
So essentially what this means is that the access_token should be at least 1 character long but there is no limit on how long defined in this specification.
Note they define VSCHAR = %x20-7E
Facebook access token can be longer than 255 characters. I had a lot of errors like ActiveRecord::StatementInvalid: PG::StringDataRightTruncation: ERROR: value too long for type character varying(255) where the value was facebook access token. Do not use string type column because its length is limited. You can use text type column to store tokens.
Recently, our app has been seeing them longer than 100 characters. I'm still looking for documentation so I can figure out a 'safe' field size for them.
I'll update the answer from the time spend.
From the OAuth2 documentation,
The access token string size is left undefined by this specification. The client should avoid making assumptions about value sizes. The authorization server should document the size of any value it issues.
(Section 4.2.2 of this document)
Note: Facebook is using OAuth2, as mentionned on this page.
So now, no informations seems to be available on the developers portail of Facebook about the length of the OAuth token. Yahoo seems to use a 400 bit long token, so it's best to assume that a TEXT column in MySQL is safer than a varchar.