mirror of https://github.com/golang-jwt/jwt.git
Deployed c88a5c5 with MkDocs version 1.4.2 (9.1.5)
This commit is contained in:
parent
956963fdf2
commit
2d7797bacc
File diff suppressed because one or more lines are too long
BIN
sitemap.xml.gz
BIN
sitemap.xml.gz
Binary file not shown.
|
@ -401,6 +401,13 @@
|
||||||
Signing Methods and Key Types
|
Signing Methods and Key Types
|
||||||
</a>
|
</a>
|
||||||
|
|
||||||
|
</li>
|
||||||
|
|
||||||
|
<li class="md-nav__item">
|
||||||
|
<a href="#frequently-asked-questions" class="md-nav__link">
|
||||||
|
Frequently Asked Questions
|
||||||
|
</a>
|
||||||
|
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
</ul>
|
</ul>
|
||||||
|
@ -489,6 +496,7 @@
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
</table>
|
</table>
|
||||||
|
<h2 id="frequently-asked-questions">Frequently Asked Questions</h2>
|
||||||
<p><strong>Why is the HMAC signing method not accepting <code>string</code> as a key type?</strong></p>
|
<p><strong>Why is the HMAC signing method not accepting <code>string</code> as a key type?</strong></p>
|
||||||
<p>We often get asked why the HMAC signing method only supports <code>[]byte</code> and not <code>string</code>. This is intentionally and there are different reasons for doing so. First, we aim to use the key type that the underlying cryptographic operation in the Go library uses (this also applies to the other signing methods). In case of HMAC, this is <a href="https://pkg.go.dev/crypto/hmac#New"><code>hmac.New</code></a> and it uses <code>[]byte</code> as the type to represent a key.</p>
|
<p>We often get asked why the HMAC signing method only supports <code>[]byte</code> and not <code>string</code>. This is intentionally and there are different reasons for doing so. First, we aim to use the key type that the underlying cryptographic operation in the Go library uses (this also applies to the other signing methods). In case of HMAC, this is <a href="https://pkg.go.dev/crypto/hmac#New"><code>hmac.New</code></a> and it uses <code>[]byte</code> as the type to represent a key.</p>
|
||||||
<p>Second, using <code>string</code> as a key type to represent a symmetric key can lead to unwanted situations. It gives the impression that this is something 'human readable' (like a password), but it is not. A symmetric key should contain as much entropy as possible and therefore include characters from the whole character set (even 'unreadable' ones) and ideally be generated by a cryptographic random source, such as <a href="https://pkg.go.dev/crypto/rand#Read"><code>rand.Read</code></a>. Signing tokens with a cryptographically weak key will compromise the security of the tokens and in effect everything that depends on it, e.g., user authentication.</p>
|
<p>Second, using <code>string</code> as a key type to represent a symmetric key can lead to unwanted situations. It gives the impression that this is something 'human readable' (like a password), but it is not. A symmetric key should contain as much entropy as possible and therefore include characters from the whole character set (even 'unreadable' ones) and ideally be generated by a cryptographic random source, such as <a href="https://pkg.go.dev/crypto/rand#Read"><code>rand.Read</code></a>. Signing tokens with a cryptographically weak key will compromise the security of the tokens and in effect everything that depends on it, e.g., user authentication.</p>
|
||||||
|
|
Loading…
Reference in New Issue