CWE-317: Cleartext Storage of Sensitive Information in GUI
The product stores sensitive information in cleartext within the GUI.
Browse cwe for c with official CWE context and Glexia analysis.
Search And Filters
Showing 50 of 857 CWE records · Page 6 of 18.
The product stores sensitive information in cleartext within the GUI.
The product stores sensitive information in cleartext in an executable.
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
The product uses a hard-coded, unchangeable cryptographic key.
The product performs a key exchange with an actor without verifying the identity of that actor.
Nonces should be used for the present occasion and only once.
The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
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 broken or risky cryptographic algorithm or protocol.
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 determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
The product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
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.
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.
The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.
The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.
The product uses a scheme that generates numbers or identifiers that are more predictable than required.
A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.
An exact value or random number can be precisely predicted by observing previous values.
The product's random number generator produces a series of values which, when observed, can be used to infer a relatively small range of possibilities for the next value that could be generated.
The product uses a constant value, name, or reference, but this value can (or should) vary across different environments.
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
The product does not properly verify that the source of data or communication is valid.
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack.
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
The product performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.
The product does not properly distinguish between different types of elements in a way that leads to insecure behavior.
The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.
The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
The product's user interface does not warn the user before undertaking an unsafe action on behalf of that user. This makes it easier for attackers to trick users into inflicting damage to their system.
The user interface provides a warning to a user regarding dangerous or sensitive operations, but the warning is not noticeable enough to warrant attention.
The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.
The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.
Security based on event locations are insecure and can be spoofed.
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
The product checks the status of a file or directory before accessing it, which produces a race condition in which the file can be replaced with a link before the access is performed, causing the product to access the wrong file.
The product uses a signal handler that introduces a race condition.
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.
A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product's behavior during the switch.
The product divides a value by zero.
The product does not check the revocation status of a certificate after its initial revocation check, which can cause the product to perform privileged actions even after the certificate is revoked at a later time.