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.
Weak Encryption: Stream Cipher
Abstract
As criptografias de fluxo são perigosas para usar quando os dados criptografados são armazenados no disco, ou se a chave for usada mais de uma vez.
Explanation
As criptografias de fluxo são vulneráveis a ataques "key re-use", também chamados de ataques "two-time". Esse tipo de vulnerabilidade ocorre quando você usa a mesma chave mais de uma vez, porque é trivial fazer XOR nas duas cadeias de texto criptografado e anular a chave, o que deixa apenas o texto simples no qual se fez XOR. Devido à forma como a linguagem humana é organizada, geralmente é trivial recuperar as duas mensagens originais.
A fim de parar os ataques mencionados anteriormente, é necessário utilizar um novo vetor de inicialização (IV), portanto, as criptografias de fluxo não são adequadas para armazenar dados criptografados, podendo significar que:
1) o setor de disco é usado como o IV:
Isso não é seguro porque exige a reutilização do mesmo IV todas as vezes que os dados armazenados requerem modificação.
2) usar um sistema complicado para mapear novos IVs para os setores do disco:
É difícil de manter. Tal abordagem requer que os IVs sejam atualizados continuamente, não podem ser legíveis pelos usuários e exige que o texto criptografado consuma mais espaço em disco que o texto original não criptografado.
Considerando esses dois pontos, é uma desvantagem usar criptografias de fluxo em vez de criptografias de bloco para armazenar dados criptografados. Outro problema com criptografias de fluxo é que elas não fornecem qualquer autenticação e, portanto, são vulneráveis a ataques "bit-flipping". Algumas criptografias de bloco, como "CTR" são vulneráveis a esses mesmos ataques, porque funcionam de forma semelhante às criptografias de fluxo.
Exemplo 1: Este código cria uma criptografia de fluxo que é usada para criptografar dados com um IV constante e armazená-los em disco:
No
A fim de parar os ataques mencionados anteriormente, é necessário utilizar um novo vetor de inicialização (IV), portanto, as criptografias de fluxo não são adequadas para armazenar dados criptografados, podendo significar que:
1) o setor de disco é usado como o IV:
Isso não é seguro porque exige a reutilização do mesmo IV todas as vezes que os dados armazenados requerem modificação.
2) usar um sistema complicado para mapear novos IVs para os setores do disco:
É difícil de manter. Tal abordagem requer que os IVs sejam atualizados continuamente, não podem ser legíveis pelos usuários e exige que o texto criptografado consuma mais espaço em disco que o texto original não criptografado.
Considerando esses dois pontos, é uma desvantagem usar criptografias de fluxo em vez de criptografias de bloco para armazenar dados criptografados. Outro problema com criptografias de fluxo é que elas não fornecem qualquer autenticação e, portanto, são vulneráveis a ataques "bit-flipping". Algumas criptografias de bloco, como "CTR" são vulneráveis a esses mesmos ataques, porque funcionam de forma semelhante às criptografias de fluxo.
Exemplo 1: Este código cria uma criptografia de fluxo que é usada para criptografar dados com um IV constante e armazená-los em disco:
import (
"crypto/aes"
"crypto/cipher"
"os"
)
...
iv = b'1234567890123456'
CTRstream = cipher.NewCTR(block, iv)
CTRstream.XORKeyStream(plaintext, ciphertext)
...
f := os.Create("data.enc")
f.Write(ciphertext)
f.Close()
No
Example 1, visto que oiv é definido como um vetor de inicialização constante, ele está suscetível a ataques de reutilização.References
[1] Disk Encryption Theory Wikipedia
[2] Clemens Fruhwirth New Methods in Hard Disk Encryption
[3] Standards Mapping - Common Weakness Enumeration CWE ID 327
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 327
[32] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 327
[33] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 327
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.semantic.golang.weak_encryption_stream_cipher
Abstract
As criptografias de fluxo são perigosas para uso com dados armazenados, ou se a chave é usada mais de uma vez.
Explanation
As criptografias de fluxo são vulneráveis a ataques "key re-use", também chamados de ataques "two-time". Isso significa que se a mesma chave for usada mais de uma vez, será trivial fazer XOR nas duas strings de texto criptografado e anular a chave, deixando apenas o texto simples no qual se fez XOR. Devido à forma como a linguagem humana é organizada, geralmente é trivial voltar às duas mensagens originais.
Como se exige a utilização de um novo vetor de inicialização (IV) a fim de parar os ataques mencionados anteriormente, as criptografias de fluxo não são adequadas para armazenar dados codificados, uma vez que isso significaria:
1) utilizar o setor de disco como IV:
Isso não é seguro, uma vez que exigiria a reutilização do mesmo IV a cada vez que os dados armazenados precisarem de modificação.
2) ter um sistema complicado que mapeia novos IVs para os setores do disco:
Isso é difícil de manter, uma vez que exige atualizações constantes, não deve ser legível pelo usuário, e exige ao texto criptografado consumir muito mais espaço em disco do que o texto original não criptografado.
Esses dois pontos tornam desvantajoso o uso de criptografias de fluxo em vez de criptografias de bloco para armazenar dados criptografados. Outro problema com criptografias de fluxo é que elas não fornecem nenhuma autenticação e, portanto, são vulneráveis a ataques "bit-flipping". Algumas criptografias de bloco, como "CTR" são vulneráveis a esses mesmos ataques, porque funcionam de forma semelhante às criptografias de fluxo.
Exemplo 1: O código a seguir cria uma criptografia de fluxo que é usada para criptografar dados com um IV constante e armazená-los em disco:
Como se exige a utilização de um novo vetor de inicialização (IV) a fim de parar os ataques mencionados anteriormente, as criptografias de fluxo não são adequadas para armazenar dados codificados, uma vez que isso significaria:
1) utilizar o setor de disco como IV:
Isso não é seguro, uma vez que exigiria a reutilização do mesmo IV a cada vez que os dados armazenados precisarem de modificação.
2) ter um sistema complicado que mapeia novos IVs para os setores do disco:
Isso é difícil de manter, uma vez que exige atualizações constantes, não deve ser legível pelo usuário, e exige ao texto criptografado consumir muito mais espaço em disco do que o texto original não criptografado.
Esses dois pontos tornam desvantajoso o uso de criptografias de fluxo em vez de criptografias de bloco para armazenar dados criptografados. Outro problema com criptografias de fluxo é que elas não fornecem nenhuma autenticação e, portanto, são vulneráveis a ataques "bit-flipping". Algumas criptografias de bloco, como "CTR" são vulneráveis a esses mesmos ataques, porque funcionam de forma semelhante às criptografias de fluxo.
Exemplo 1: O código a seguir cria uma criptografia de fluxo que é usada para criptografar dados com um IV constante e armazená-los em disco:
...
const cipher = crypto.createCipheriv("AES-256-CTR", key, 'iv')
const ciphertext = cipher.update(plaintext, 'utf8');
cipher.final();
fs.writeFile('my_encrypted_data', ciphertext, function (err) {
...
});
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 327
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[3] Standards Mapping - FIPS200 MP
[4] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 327
[30] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 327
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 327
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.structural.javascript.weak_encryption_stream_cipher
Abstract
As criptografias de fluxo são perigosas para usar caso os dados criptografados forem armazenado no disco, ou se a chave for usada mais de uma vez.
Explanation
As criptografias de fluxo são vulneráveis a ataques "key re-use", também chamados de ataques "two-time pad". Isto significa que se a mesma chave for usada mais de uma vez, será trivial para fazer XOR nas duas cadeias de texto criptografado e anular a chave, deixando apenas o texto simples no qual se fez XOR. Devido à forma como a linguagem humana é organizada, geralmente é trivial voltar às duas mensagens originais.
Como se exige a utilização de um novo vetor de inicialização (IV) a fim de parar os ataques mencionados anteriormente, as criptografias de fluxo não são adequadas para armazenar dados codificados, uma vez que isso significaria:
1) utilizar o setor de disco como IV:
Isso não é seguro, uma vez que exigiria a reutilização do mesmo IV a cada vez que os dados armazenados precisarem de modificação.
2) ter um sistema complicado que mapeia novos IVs para os setores do disco:
Isso é difícil de manter, uma vez que exige atualizações constantes, não deve ser legível pelo usuário, e exige ao texto criptografado consumir muito mais espaço em disco do que o texto original não criptografado.
Esses dois pontos tornam desvantajoso o uso de criptografias de fluxo em vez de criptografias de bloco para armazenar dados criptografados. Outro problema com criptografias de fluxo é que elas não fornecem nenhuma autenticação e, portanto, são vulneráveis a ataques "bit-flipping". Algumas criptografias de bloco, como "CTR" são vulneráveis a esses mesmos ataques, porque funcionam de forma semelhante às criptografias de fluxo.
Exemplo 1: O código a seguir cria uma criptografia de fluxo que é usada para criptografar dados com um IV constante e armazená-los em disco:
No
Como se exige a utilização de um novo vetor de inicialização (IV) a fim de parar os ataques mencionados anteriormente, as criptografias de fluxo não são adequadas para armazenar dados codificados, uma vez que isso significaria:
1) utilizar o setor de disco como IV:
Isso não é seguro, uma vez que exigiria a reutilização do mesmo IV a cada vez que os dados armazenados precisarem de modificação.
2) ter um sistema complicado que mapeia novos IVs para os setores do disco:
Isso é difícil de manter, uma vez que exige atualizações constantes, não deve ser legível pelo usuário, e exige ao texto criptografado consumir muito mais espaço em disco do que o texto original não criptografado.
Esses dois pontos tornam desvantajoso o uso de criptografias de fluxo em vez de criptografias de bloco para armazenar dados criptografados. Outro problema com criptografias de fluxo é que elas não fornecem nenhuma autenticação e, portanto, são vulneráveis a ataques "bit-flipping". Algumas criptografias de bloco, como "CTR" são vulneráveis a esses mesmos ataques, porque funcionam de forma semelhante às criptografias de fluxo.
Exemplo 1: O código a seguir cria uma criptografia de fluxo que é usada para criptografar dados com um IV constante e armazená-los em disco:
from Crypto.Cipher import AES
from Crypto import Random
...
key = Random.new().read(AES.block_size)
iv = b'1234567890123456'
cipher = AES.new(key, AES.MODE_CTR, iv, counter)
...
encrypted = cipher.encrypt(data)
f = open("data.enc", "wb")
f.write(encrypted)
f.close()
...
No
Example 1, uma vez que oiv seja definido como um vetor de inicialização constante, ele estará suscetível a ataques de reutilização.References
[1] Disk Encryption Theory Wikipedia
[2] Clemens Fruhwirth New Methods in Hard Disk Encryption
[3] Standards Mapping - Common Weakness Enumeration CWE ID 327
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 327
[32] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 327
[33] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 327
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.semantic.python.weak_encryption_stream_cipher
Abstract
As criptografias de fluxo são perigosas para usar com dados armazenados, ou se a chave for usada mais de uma vez.
Explanation
As criptografias de fluxo são vulneráveis a ataques "key re-use", também chamados de ataques "two-time pad". Isto significa que se a mesma chave for usada mais de uma vez, será trivial para fazer XOR nas duas cadeias de texto criptografado e anular a chave, deixando apenas o texto simples no qual se fez XOR. Devido à forma como a linguagem humana é organizada, geralmente é trivial voltar às duas mensagens originais.
Como se exige a utilização de um novo vetor de inicialização (IV) a fim de parar os ataques mencionados anteriormente, as criptografias de fluxo não são adequadas para armazenar dados codificados, uma vez que isso significaria:
1) utilizar o setor de disco como IV:
Isso não é seguro, uma vez que exigiria a reutilização do mesmo IV a cada vez que os dados armazenados precisarem de modificação.
2) ter um sistema complicado que mapeia novos IVs para os setores do disco:
Isso é difícil de manter, uma vez que exige atualizações constantes, não deve ser legível pelo usuário, e exige ao texto criptografado consumir muito mais espaço em disco do que o texto original não criptografado.
Esses dois pontos tornam desvantajoso o uso de criptografias de fluxo em vez de criptografias de bloco para armazenar dados criptografados. Outro problema com criptografias de fluxo é que elas não fornecem nenhuma autenticação e, portanto, são vulneráveis a ataques "bit-flipping". Algumas criptografias de bloco, como "CTR" são vulneráveis a esses mesmos ataques, porque funcionam de forma semelhante às criptografias de fluxo.
Exemplo 1: O código a seguir cria uma criptografia de fluxo que é usada para criptografar dados com um IV constante e armazená-los em disco:
No
Como se exige a utilização de um novo vetor de inicialização (IV) a fim de parar os ataques mencionados anteriormente, as criptografias de fluxo não são adequadas para armazenar dados codificados, uma vez que isso significaria:
1) utilizar o setor de disco como IV:
Isso não é seguro, uma vez que exigiria a reutilização do mesmo IV a cada vez que os dados armazenados precisarem de modificação.
2) ter um sistema complicado que mapeia novos IVs para os setores do disco:
Isso é difícil de manter, uma vez que exige atualizações constantes, não deve ser legível pelo usuário, e exige ao texto criptografado consumir muito mais espaço em disco do que o texto original não criptografado.
Esses dois pontos tornam desvantajoso o uso de criptografias de fluxo em vez de criptografias de bloco para armazenar dados criptografados. Outro problema com criptografias de fluxo é que elas não fornecem nenhuma autenticação e, portanto, são vulneráveis a ataques "bit-flipping". Algumas criptografias de bloco, como "CTR" são vulneráveis a esses mesmos ataques, porque funcionam de forma semelhante às criptografias de fluxo.
Exemplo 1: O código a seguir cria uma criptografia de fluxo que é usada para criptografar dados com um IV constante e armazená-los em disco:
require 'openssl'
...
cipher = OpenSSL::Cipher.new('AES-256-CTR')
cipher.encrypt
cipher.iv='iv'
...
encrypted = cipher.update(data) + cipher.final
File.open('my_encrypted_data', 'w') do |file|
file.write(encrypted)
end
No
Example 1, uma vez que oOpenSSL::Cipher#iv= seja definido como um vetor de inicialização constante, ele estará suscetível a ataques de reutilização.References
[1] Disk Encryption Theory Wikipedia
[2] Clemens Fruhwirth New Methods in Hard Disk Encryption
[3] Standards Mapping - Common Weakness Enumeration CWE ID 327
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 327
[32] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 327
[33] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 327
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.structural.ruby.weak_encryption_stream_cipher