Reino: Security Features
Segurança de software não é o mesmo que software de segurança. Aqui, estamos interessados em tópicos como autenticação, controle de acesso, confidencialidade, criptografia e gestão de privilégios.
Key Management: Empty PBE Password
Abstract
O uso de uma chave gerada por uma função de derivação de chave baseada em senha que recebeu um valor vazio em seu argumento de senha pode comprometer a segurança do sistema de uma maneira difícil de remediar.
Explanation
Nunca é uma boa ideia passar um valor vazio como argumento de senha para uma PBKDF (função de derivação de chave baseada em senha) criptográfica. Nesse cenário, a chave derivada se baseará exclusivamente no salt fornecido (tornando-o significativamente mais fraco), e a correção do problema será extremamente difícil. Depois que o código ofensivo está em produção, a senha vazia geralmente não pode ser alterada sem a aplicação de patches no software. Se uma conta protegida por uma chave derivada baseada em uma senha vazia for comprometida, os proprietários do sistema poderão ser forçados a escolher entre segurança e disponibilidade.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("", salt,100000);
...
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.dotnet.key_management_empty_pbe_password
Abstract
Uma senha vazia é usada para gerar uma chave a partir de uma PBKDF (função de derivação de chave baseada em senha). Fornecer uma senha vazia a uma PBKDF compromete a segurança do sistema de uma maneira difícil de remediar.
Explanation
Nunca é uma boa ideia passar um valor vazio como argumento de senha para uma PBKDF (função de derivação de chave baseada em senha) criptográfica. Nesse cenário, a chave derivada se baseará exclusivamente no salt fornecido (tornando-o significativamente mais fraco), e a correção do problema será extremamente difícil. Depois que o código ofensivo está em produção, a senha vazia geralmente não pode ser alterada sem a aplicação de patches no software. Se uma conta protegida por uma chave derivada baseada em uma senha vazia for comprometida, os proprietários do sistema poderão ser forçados a escolher entre segurança e disponibilidade.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword("");
...
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_empty_pbe_password
Abstract
Fornecer uma senha vazia a uma PBKDF compromete a segurança do sistema de uma maneira difícil de remediar.
Explanation
Nunca é uma boa ideia passar um valor vazio como argumento de senha para uma PBKDF (função de derivação de chave baseada em senha) criptográfica. Nesse cenário, a chave derivada é baseada principalmente no salt fornecido (tornando-o significativamente mais fraco), e a correção do problema será extremamente difícil. Depois que o código ofensivo está em produção, a senha vazia geralmente não pode ser alterada sem a aplicação de patches no software. Se uma conta protegida por uma chave derivada baseada em uma senha vazia for comprometida, os proprietários do sistema poderão ser forçados a escolher entre segurança e disponibilidade.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha vazio. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
const pbkdfPassword = "";
crypto.pbkdf2(
pbkdfPassword,
salt,
numIterations,
keyLen,
hashAlg,
function (err, derivedKey) { ... }
)
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha vazio. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_empty_pbe_password
Abstract
Uma senha vazia é usada para gerar uma chave a partir de uma PBKDF (função de derivação de chave baseada em senha). Fornecer uma senha vazia a uma PBKDF compromete a segurança do sistema de uma maneira difícil de remediar.
Explanation
Nunca é uma boa ideia passar um valor vazio como argumento de senha para uma PBKDF (função de derivação de chave baseada em senha) criptográfica. Nesse cenário, a chave derivada se baseará exclusivamente no salt fornecido (tornando-o significativamente mais fraco), e a correção do problema será extremamente difícil. Depois que o código ofensivo está em produção, a senha vazia geralmente não pode ser alterada sem a aplicação de patches no software. Se uma conta protegida por uma chave derivada baseada em uma senha vazia for comprometida, os proprietários do sistema poderão ser forçados a escolher entre segurança e disponibilidade.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 2: Algumas APIs de nível inferior podem exigir que se passe do tamanho de certos argumentos, bem como dos valores dos argumentos, de tal forma que uma função possa ler o valor do argumento como um número de bytes consecutivos começando no local do argumento na memória. O código a seguir transmite zero como o argumento de tamanho da senha a uma PBKDF criptográfica:
Nesse cenário, mesmo que a
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
...
CCKeyDerivationPBKDF(kCCPBKDF2,
"",
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 2: Algumas APIs de nível inferior podem exigir que se passe do tamanho de certos argumentos, bem como dos valores dos argumentos, de tal forma que uma função possa ler o valor do argumento como um número de bytes consecutivos começando no local do argumento na memória. O código a seguir transmite zero como o argumento de tamanho da senha a uma PBKDF criptográfica:
...
CCKeyDerivationPBKDF(kCCPBKDF2,
password,
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...
Nesse cenário, mesmo que a
password contenha um valor de senha forte e gerenciado de maneira adequada, passar o tamanho como zero resultará em um valor vazio, null, ou em um valor de senha inesperadamente fraco.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_empty_pbe_password
Abstract
Uma senha vazia é usada para gerar uma chave a partir de uma PBKDF (função de derivação de chave baseada em senha). Fornecer uma senha vazia a uma PBKDF compromete a segurança do sistema de uma maneira difícil de remediar.
Explanation
Nunca é uma boa ideia passar um valor vazio como argumento de senha para uma PBKDF (função de derivação de chave baseada em senha) criptográfica. Nesse cenário, a chave derivada se baseará exclusivamente no salt fornecido (tornando-o significativamente mais fraco), e a correção do problema será extremamente difícil. Depois que o código ofensivo está em produção, a senha vazia geralmente não pode ser alterada sem a aplicação de patches no software. Se uma conta protegida por uma chave derivada baseada em uma senha vazia for comprometida, os proprietários do sistema poderão ser forçados a escolher entre segurança e disponibilidade.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
Qualquer pessoa com acesso ao código pode determinar que ele gera uma ou mais chaves criptográficas com base em um argumento de senha vazio. Além disso, qualquer pessoa com técnicas básicas de cracking pode obter acesso com sucesso a quaisquer recursos protegidos pelas chaves ofensivas. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "");
...
Qualquer pessoa com acesso ao código pode determinar que ele gera uma ou mais chaves criptográficas com base em um argumento de senha vazio. Além disso, qualquer pessoa com técnicas básicas de cracking pode obter acesso com sucesso a quaisquer recursos protegidos pelas chaves ofensivas. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_empty_pbe_password
Abstract
Uma senha vazia é usada para gerar uma chave a partir de uma PBKDF (função de derivação de chave baseada em senha). Fornecer uma senha vazia a uma PBKDF compromete a segurança do sistema de uma maneira difícil de remediar.
Explanation
Nunca é uma boa ideia passar um valor vazio como argumento de senha para uma PBKDF (função de derivação de chave baseada em senha) criptográfica. Nesse cenário, a chave derivada se baseará exclusivamente no salt fornecido (tornando-o significativamente mais fraco), e a correção do problema será extremamente difícil. Depois que o código ofensivo está em produção, a senha vazia geralmente não pode ser alterada sem a aplicação de patches no software. Se uma conta protegida por uma chave derivada baseada em uma senha vazia for comprometida, os proprietários do sistema poderão ser forçados a escolher entre segurança e disponibilidade.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', '', salt, 100000)
...
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_empty_pbe_password
Abstract
Uma senha vazia é usada para gerar uma chave a partir de uma PBKDF (função de derivação de chave baseada em senha). Fornecer uma senha vazia a uma PBKDF compromete a segurança do sistema de uma maneira difícil de remediar.
Explanation
Nunca é uma boa ideia passar um valor vazio como argumento de senha para uma PBKDF (função de derivação de chave baseada em senha) criptográfica. Nesse cenário, a chave derivada se baseará exclusivamente no salt fornecido (tornando-o significativamente mais fraco), e a correção do problema será extremamente difícil. Depois que o código ofensivo está em produção, a senha vazia geralmente não pode ser alterada sem a aplicação de patches no software. Se uma conta protegida por uma chave derivada baseada em uma senha vazia for comprometida, os proprietários do sistema poderão ser forçados a escolher entre segurança e disponibilidade.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
...
key = OpenSSL::PKCS5::pbkdf2_hmac('', salt, 100000, 256, 'SHA256')
...
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_empty_pbe_password
Abstract
Uma senha vazia é usada para gerar uma chave a partir de uma PBKDF (função de derivação de chave baseada em senha). Fornecer uma senha vazia a uma PBKDF compromete a segurança do sistema de uma maneira difícil de remediar.
Explanation
Nunca é uma boa ideia passar um valor vazio como argumento de senha para uma PBKDF (função de derivação de chave baseada em senha) criptográfica. Nesse cenário, a chave derivada se baseará exclusivamente no salt fornecido (tornando-o significativamente mais fraco), e a correção do problema será extremamente difícil. Depois que o código ofensivo está em produção, a senha vazia geralmente não pode ser alterada sem a aplicação de patches no software. Se uma conta protegida por uma chave derivada baseada em uma senha vazia for comprometida, os proprietários do sistema poderão ser forçados a escolher entre segurança e disponibilidade.
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 2: Algumas APIs de nível inferior podem exigir que se passe do tamanho de certos argumentos, bem como dos valores dos argumentos, de tal forma que uma função possa ler o valor do argumento como um número de bytes consecutivos começando no local do argumento na memória. O código a seguir transmite zero como o argumento de tamanho da senha a uma PBKDF criptográfica:
Nesse cenário, mesmo que a
Exemplo 1: O código a seguir transmite uma string vazia como argumento de senha para uma PBKDF criptográfica:
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"",
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...
Qualquer pessoa com acesso ao código será capaz de determinar que ele gere uma ou mais chaves criptográficas com base em um argumento de senha inserida em código fixo. Mas, pior do que isso, qualquer pessoa com as técnicas mais básicas de cracking terá muito mais chances de obter acesso a todos os recursos protegidos pelas chaves transgressoras. Se um invasor também tiver acesso ao valor de sal usado para gerar qualquer uma das chaves com base em uma senha vazia, o cracking dessas chaves se tornará um processo simples. A partir do momento em que o programa for distribuído, provavelmente não será mais possível alterar a senha vazia, a não ser que um patch seja aplicado a esse programa. Um funcionário com acesso a essas informações pode usá-las para invadir o sistema. Mesmo que os invasores só tivessem acesso ao executável do aplicativo, eles poderiam extrair evidências do uso de uma senha vazia.
Exemplo 2: Algumas APIs de nível inferior podem exigir que se passe do tamanho de certos argumentos, bem como dos valores dos argumentos, de tal forma que uma função possa ler o valor do argumento como um número de bytes consecutivos começando no local do argumento na memória. O código a seguir transmite zero como o argumento de tamanho da senha a uma PBKDF criptográfica:
...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...
Nesse cenário, mesmo que a
password contenha um valor de senha forte e gerenciado de maneira adequada, passar o tamanho como zero resultará em um valor vazio, null, ou em um valor de senha inesperadamente fraco.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 321
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 IA
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[13] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[14] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_empty_pbe_password