You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Benoit Tellier (Jira)" <se...@james.apache.org> on 2022/10/12 09:59:00 UTC
[jira] [Updated] (JAMES-3834) PBKDF2WithHmacSHA1: Use of a broken or risky cryptographic algorithm
[ https://issues.apache.org/jira/browse/JAMES-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Tellier updated JAMES-3834:
----------------------------------
Description:
h3. What?
Cryptographic algorithm `PBKDF2WithHmacSHA1` is weak and should not be used.
Using broken or weak cryptographic algorithms can leave data vulnerable to being decrypted.
Many cryptographic algorithms provided by cryptography libraries are known to be weak, or flawed. Using such an algorithm means that an attacker may be able to easily decrypt the encrypted data.
Recommendation
**Recommendation**
Ensure that you use a strong, modern cryptographic algorithm. Use at least AES-128 or RSA-2048. Do not use the ECB encryption mode since it is vulnerable to replay and other attacks.
(Found via Github code scans...)
h3. Fix
For blob AES :
-> Defaults to usage of PBKDF2WithHmacSHA512
-> Allow people to configure other algorithms, including PBKDF2WithHmacSHA1
-> No migration strategy for people having already encrypted data (stick to PBKDF2WithHmacSHA1)
For user hashing:
-> add a new user password hashing algorithm based on PBKDF2WithHmacSHA512
-> Make it the default one
-> Hashing "on the fly" migration already present...
was:
h3. What?
Cryptographic algorithm `PBKDF2WithHmacSHA1` is weak and should not be used.
Using broken or weak cryptographic algorithms can leave data vulnerable to being decrypted.
Many cryptographic algorithms provided by cryptography libraries are known to be weak, or flawed. Using such an algorithm means that an attacker may be able to easily decrypt the encrypted data.
Recommendation
**Recommendation**
Ensure that you use a strong, modern cryptographic algorithm. Use at least AES-128 or RSA-2048. Do not use the ECB encryption mode since it is vulnerable to replay and other attacks.
(Found via Github code scans...)
h3. Fix
For blob AES :
-> Defaults to usage of PBKDF2WithHmacSHA512
-> Allow people to configure other algorithms, including PBKDF2WithHmacSHA1
-> No migration strategy for people having already encrypted data (stick to PBKDF2WithHmacSHA1)
For user hashing:
-> add a new user password hashing algorithm based on PBKDF2WithHmacSHA1
-> Make it the default one
-> Hashing "on the fly" migration already present...
> PBKDF2WithHmacSHA1: Use of a broken or risky cryptographic algorithm
> ---------------------------------------------------------------------
>
> Key: JAMES-3834
> URL: https://issues.apache.org/jira/browse/JAMES-3834
> Project: James Server
> Issue Type: New Feature
> Components: Blob, UsersStore & UsersRepository
> Reporter: Benoit Tellier
> Priority: Major
> Labels: security
>
> h3. What?
> Cryptographic algorithm `PBKDF2WithHmacSHA1` is weak and should not be used.
> Using broken or weak cryptographic algorithms can leave data vulnerable to being decrypted.
> Many cryptographic algorithms provided by cryptography libraries are known to be weak, or flawed. Using such an algorithm means that an attacker may be able to easily decrypt the encrypted data.
> Recommendation
> **Recommendation**
> Ensure that you use a strong, modern cryptographic algorithm. Use at least AES-128 or RSA-2048. Do not use the ECB encryption mode since it is vulnerable to replay and other attacks.
> (Found via Github code scans...)
> h3. Fix
> For blob AES :
> -> Defaults to usage of PBKDF2WithHmacSHA512
> -> Allow people to configure other algorithms, including PBKDF2WithHmacSHA1
> -> No migration strategy for people having already encrypted data (stick to PBKDF2WithHmacSHA1)
> For user hashing:
> -> add a new user password hashing algorithm based on PBKDF2WithHmacSHA512
> -> Make it the default one
> -> Hashing "on the fly" migration already present...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org