Encrypt Data
A category in the Common Weakness Enumeration published by The MITRE Corporation.
Summary
Categories in the Common Weakness Enumeration (CWE) group entries based on some common characteristic or attribute.
Weaknesses in this category are related to the design and architecture of data confidentiality in a system. Frequently these deal with the use of encryption libraries. The weaknesses in this category could lead to a degradation of the quality data encryption if they are not addressed when designing or implementing a secure architecture.
Weaknesses
The product stores sensitive information in cleartext in a file, or on disk.
The product stores sensitive information in cleartext in the registry.
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
The product stores sensitive information in cleartext in a cookie.
The product stores sensitive information in cleartext in an executable.
The product stores sensitive information in cleartext within the GUI.
The product stores sensitive information in cleartext in memory.
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.
The product stores sensitive information without properly limiting read or write access by unauthorized actors.
The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
The product does not encrypt sensitive or critical information before storage or transmission.
The product stores a password in a configuration file that might be accessible to actors who do not know the password.
Storing a password in plaintext may result in a system compromise.
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
Nonces should be used for the present occasion and only once.
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mecha...
A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.
The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.
The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypte...
Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.
The product uses a broken or risky cryptographic algorithm or protocol.
The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attac...
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product uses a predictable salt as part of th...
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of t...
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
The product uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably...
Obscuring a password with a trivial encoding does not protect the password.
Concepts
This view organizes weaknesses according to common architectural security tactics. It is intended to assist architects in identifying potential mistakes that can be ma...
See Also
- A Catalog of Security Architecture Weaknesses.
2017 IEEE International Conference on Software Architecture (ICSA)
- Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.
2017 IEEE International Conference on Software Architecture (ICSA)
Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.