問題描述

我已經開始使用 JJWT 來處理我的服務器應用程序上的 JWT.

I have started to work with JJWT to handle JWT on my server application.

我的 JWT 機密將存儲在 resources 文件夾中，我將使用 Properties 類加載該機密.

My JWT secret will be stored at resources folder and I will load the secret with Properties class.

JJWT 提供了三種對 JWT 進行簽名的方法，一種使用 byte[]，其他使用String，其他使用Key:

The JJWT provides three methods to sign the JWT, one uses byte[], other uses String and the other uses Key:

JwtBuilder signWith(SignatureAlgorithm var1, byte[] var2);

JwtBuilder signWith(SignatureAlgorithm var1, String var2);

JwtBuilder signWith(SignatureAlgorithm var1, Key var2);

問題:關于安全、字符集和其他方面，我應該使用哪一個有什么建議?

The question: Regarding security, charset and other things, there are any recommendations of which one I should use?

暫時，我支持 String，因為 Properties 返回一個 String.

For while, I stand with String, since Properties return a String.

推薦答案

在 JJWT >= 0.10.0 的情況下，signWith(SignatureAlgorithm var1, String var2) 已被棄用，因為它們之間存在混淆字符串和 Base64 編碼的字符串:

With JJWT >= 0.10.0, signWith(SignatureAlgorithm var1, String var2) has been deprecated because of the confusion between raw strings and Base64-encoded strings:

/**
 * Signs the constructed JWT using the specified algorithm with the specified key, producing a JWS.
 *
 * <p>This is a convenience method: the string argument is first BASE64-decoded to a byte array and this resulting
 * byte array is used to invoke {@link #signWith(SignatureAlgorithm, byte[])}.</p>
 *
 * <h4>Deprecation Notice: Deprecated as of 0.10.0, will be removed in the 1.0 release.</h4>
 *
 * <p>This method has been deprecated because the {@code key} argument for this method can be confusing: keys for
 * cryptographic operations are always binary (byte arrays), and many people were confused as to how bytes were
 * obtained from the String argument.</p>
 *
 * <p>This method always expected a String argument that was effectively the same as the result of the following
 * (pseudocode):</p>
 *
 * <p>{@code String base64EncodedSecretKey = base64Encode(secretKeyBytes);}</p>
 *
 * <p>However, a non-trivial number of JJWT users were confused by the method signature and attempted to
 * use raw password strings as the key argument - for example {@code signWith(HS256, myPassword)} - which is
 * almost always incorrect for cryptographic hashes and can produce erroneous or insecure results.</p>
 *
 * <p>See this
 * <a href="https://stackoverflow.com/questions/40252903/static-secret-as-byte-key-or-string/40274325#40274325">
 * StackOverflow answer</a> explaining why raw (non-base64-encoded) strings are almost always incorrect for
 * signature operations.</p>
 *
 * <p>To perform the correct logic with base64EncodedSecretKey strings with JJWT >= 0.10.0, you may do this:
 * <pre><code>
 * byte[] keyBytes = {@link Decoders Decoders}.{@link Decoders#BASE64 BASE64}.{@link Decoder#decode(Object) decode(base64EncodedSecretKey)};
 * Key key = {@link Keys Keys}.{@link Keys#hmacShaKeyFor(byte[]) hmacShaKeyFor(keyBytes)};
 * jwtBuilder.signWith(key); //or {@link #signWith(Key, SignatureAlgorithm)}
 * </code></pre>
 * </p>
 *
 * <p>This method will be removed in the 1.0 release.</p>
 *
 * @param alg                    the JWS algorithm to use to digitally sign the JWT, thereby producing a JWS.
 * @param base64EncodedSecretKey the BASE64-encoded algorithm-specific signing key to use to digitally sign the
 *                               JWT.
 * @return the builder for method chaining.
 * @throws InvalidKeyException if the Key is insufficient or explicitly disallowed by the JWT specification as
 *                             described by {@link SignatureAlgorithm#forSigningKey(Key)}.
 * @deprecated as of 0.10.0: use {@link #signWith(Key)} or {@link #signWith(Key, SignatureAlgorithm)} instead.  This
 * method will be removed in the 1.0 release.
 */
JwtBuilder signWith(SignatureAlgorithm alg, String base64EncodedSecretKey);

此方法要求字符串參數是 Base64 編碼的密鑰字節數組.它不假設一個通用字符串，例如用戶密碼，作為簽名密鑰.JJWT 采用 Base64 編碼，因為如果您指定的字符串密碼不是 Base64 編碼的，那么您可能使用了格式不正確或弱的密鑰.

This method expects the string argument to be a Base64-encoded secret key byte array. It does not assume a general string, like a user password for example, as the signing key. JJWT assumes Base64 encoding because if you're specifying a string password that is not Base64-encoded, you're probably using a poorly formed or weak key.

JWT JWA 規范要求 HMAC 簽名密鑰的長度等于或大于簽名字節數組長度.

The JWT JWA specification REQUIRES that HMAC signing keys have lengths equal to or greater than the signature byte array length.

這意味著:

| If you're signing with: | your key (byte array) length MUST be: |
| ----------------------- | ------------------------------------- |
| HMAC SHA 256            | >= 256 bits (32 bytes)                |
| HMAC SHA 384            | >= 384 bits (48 bytes)                |
| HMAC SHA 512            | >= 512 bits (64 bytes)                |

許多在線 JWT 網站和工具只是犯了這個明顯的錯誤——它們讓您認為您可以輸入或使用任何舊字符串并且您很好.有些人甚至使用 secret 這個詞預先填充密鑰(顯然是個壞主意，甚至不符合規范，因為它太短了！).

Many online JWT sites and tools just just get this plain wrong - they allow you to think that you could type in or use any old string and you're good. Some go as far as even pre-populating the key with the word secret (clearly a bad idea and not even spec-compliant because it's too short!).

為了幫助您簡化事情，JJWT 提供了一個實用程序來幫助您生成足夠的安全隨機密鑰，以通過 io.jsonwebtoken.security.Keys 類的 secretKeyFor 進行符合規范的簽名 方法.例如:

To help simplify things for you, JJWT provides a utility to help you generate sufficient secure-random keys suitable for spec-compliant signing via the io.jsonwebtoken.security.Keys class's secretKeyFor method. For example:

//creates a spec-compliant secure-random key:
SecretKey key = Keys.secretKeyFor(SignatureAlgorithm.HS256); //or HS384 or HS512

如果你想將生成的密鑰存儲為字符串，你可以推測它是 Base64 編碼:

If you wanted to store the generated key as a String, you could presumably Base64 encode it:

String base64Key = Encoders.BASE64.encode(key.getEncoded());

但請注意:生成的 base64Key 字符串不被認為可以安全地顯示給任何人.Base64 編碼不是加密 - 該值仍然需要保密.如何執行此操作取決于您(加密等).

But note: the resulting base64Key string is not considered safe to show to anyone. Base64 encoding is not encryption - the value still needs to be kept secret. How you do this is up to you (encrypt it, etc).

現在，當需要創建 JWS 時，您可以傳入該 base64Key 值，JJWT 知道首先對其進行 base64 解碼以獲取實際字節，然后用于計算簽名:

Now, when it is time to create a JWS, you could pass in that base64Key value, and JJWT knows to base64 decode it first to get the real bytes, which are then used to compute the signature:

Jwts.builder()
    //...
    .signWith(SignatureAlgorithm.HS512, base64Key)
    .compact();

雖然您可以這樣做，但由于原始字符串和 base64 編碼字符串之間的歧義，不建議按照 JavaDoc 中的上述棄用通知.

And while you could do this, it is not recommended per the above deprecation notice in the JavaDoc due to the ambiguity between raw strings and base64-encoded strings.

因此，建議使用 JWT 構建器的 signWith(Key) 或 signWith(Key, SignatureAlgorithm) 方法來保證類型安全 鍵參數.例如:

As a result, it is recommended to use either the JWT builder's signWith(Key) or signWith(Key, SignatureAlgorithm) methods which guarantee a type-safe Key argument. For example:

  Jwts.builder()
    //...
    .signWith(key) // or signWith(key, preferredSignatureAlgorithm)
    .compact();

signWith(Key) 建議讓 JJWT 根據您提供的密鑰的強度找出可能的最強算法.signWith(Key,SignatureAlgorithm) 允許您指定所需的算法，如果您不想要最強的算法.

signWith(Key) is recommended to let JJWT figure out the strongest algorithm possible based on the strength of your supplied key. signWith(Key,SignatureAlgorithm) allows you to specify a desired algorithm if you don't want the strongest possible one.

這兩種方法都會拒絕任何不符合最低 RFC 要求的 Key.

Both methods will reject any Key that doesn't meet the minimum RFC requirements.

這篇關于靜態機密作為字節 []、密鑰還是字符串?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！