6

When I looked up hardcoded password vulnerability in software world, I saw there are three kinds of vulnerabilities. These are that:

CWE-798: Use of Hard-coded Credentials

The Hardcoded Creds vulnerability definition:

"The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data."

CWE-259: Use of Hard-coded Password

The Hardcoded Password vulnerability definition:

"The software contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components."

CWE-260: Password in Configuration File

Password in Config vulnerability definition:

"The software stores a password in a configuration file that might be accessible to actors who do not know the password."

When I investigate these cwe pages, I am fully confused. Because the CWE-798 and CWE-259 gives same vulnerable code snippets exactly as an example. I mean both of these vulnerabilities looks like same.

In addition, CWE-798 and CWE-259 give vulnerable config code snippets as an example that take place in CWE-260 at the same time.

Can someone explain why all of these cwe entries aren't a single entry? What are the differences between these entries?

Improve this question

3 Answers 3

Reset to default
6

CWE-259 and CWE-260 were added on 2006-07-19, and originated from the 7 Pernicious Kingdoms, a very early attempt to provide a taxonomy for vulnerabilities.

Meanwhile, the Internet evolved.

CWE-798 was added on 2010-01-15 by MITRE, with the rationale:

More abstract entry for hard-coded password and hard-coded cryptographic key.

So what we learned in the 4 years between them is that 259 and 260 weren't comprehensive enough, and indeed too specific, so a more general term was added.

However, we can't just remove them, because in those four years there were backlinks made to 259 and 260, and it doesn't really do any harm to keep them: except for confusion, of course.

But the CWE itself is not well-architected (in my opinion) and could do with some overall refinements to make current relevant threats more accessible and historical ones less prominent.

Improve this answer
2
  • If old classifications have been replaced with new ones, could the CWE system deprecate or retire them; leave them to be there for the existing links but discourage using them any further?
    – Esa Jokinen
    Commented Jan 3, 2023 at 5:44
  • 2
    @EsaJokinen I think the older classifications were generalized, not so much replaced. That is, a system affected by 259 (or 260) is also affected by 798, but a system affected by 798 may not be affected by 259 (or 260). From a remediation standpoint, the more specific a CWE the better, because the advice is more targeted to the circumstances of that vulnerability. Thus, a system affected by 259 (or 260) has specific ways it can be fixed, but a system affected by 798 may have only general advice for fixing. For these reasons, I think MITRE chooses to leave 259 and 260 active.
    – bishop
    Commented Jan 3, 2023 at 19:22
8

I think the answer to the why question is that...

CWE™ is a community-developed list of software and hardware weakness types.

It is an indicative tool rather than an authority for vulnerability classification.

All the mentioned CWEs are also linked to each other through their parent CWEs:

However, the links are not exclusive, as any CWE could have multiple children and also multiple parents. It might be a good idea to make more direct relationships between CWEs that share common examples.

Furthermore, as all the CWEs are part of CWE VIEW: Research Concepts, one must take into consideration

  • their general objective

    This view is intended to facilitate research into weaknesses, including their inter-dependencies, and can be leveraged to systematically identify theoretical gaps within CWE. It is mainly organized according to abstractions of behaviors instead of how they can be detected, where they appear in code, or when they are introduced in the development life cycle. By design, this view is expected to include every weakness within CWE.

  • the relationship types

    Classes are still very abstract, typically independent of any specific language or technology.

    Base level weaknesses are used to present a more specific type of weakness.

    A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology.

Improve this answer
2
  • 2
    In summary, it looks like a hot mess.
    – le3th4x0rbot
    Commented Jan 2, 2023 at 12:24
  • 798 seems to be the wrong one here, as a hard-coded credential is not necessarily a weak one. The weakness is insufficient protection, which is captured under 522. A hierarchy like 522->798->259 would make sense.
    – user20574
    Commented Jan 2, 2023 at 18:04
4

It's different things.

CWE-260 talks about storing the authentication credential in clear text in a configuration file, so that an attacker can learn it.

CWE-259 talks about using hardcoded passwords for incoming or outgoing communication. Note that this hardcoded password need not be configurable, nor stored in plain text. It can be a hash in the source code that's compiled into a binary.

CWE-798 widens this to include any kind of credential used for authentication or encryption, even if for encrypting data at rest.

It could be argued that CWE-798 covers CWE-259 as well. But CWE-260 is a distinct type where the credential is stored in a configuration file.

Improve this answer
3
  • When I look up CWE-798, there are hardcoded password as clear text in configuration file in example number 4, when I look up CWE-259, there are hardcoded password as clear text in configuration file in example number 3 and when I look up CWE-260, there are hardcoded password as clear text in configuration file in example number 1 and 2. So all of them contains clear text password in configuration file as an example. In addition when I look up 798 & 259, there are same code snippets for hardcoded password in example number 1 and 2 in each one. So both of them contains same hardcoded password.
    – Hasan
    Commented Jan 1, 2023 at 14:08
  • You would have to ask the persons that did the taxonomy to explain their decisions. As we (on this site) did not perform the taxonomy or write the definitions, we can only tell the difference between them as given by the authors.
    – vidarlo
    Commented Jan 1, 2023 at 15:33
  • Putting this as a comment rather than its own answer because I'm not 100% sure this aligns, but my understanding based on what you said, CWE-260 is like having a MySQL configuration file on a server that ends up being readable by people not authorized to connect to prod data, CWE-259 would be like a password version (As opposed to the tokenized version) of the Moonpig Bug, where if the password is leaked, it can't be reset/changed without breaking functionality, and CWE-798 could be Superfish.
    – Alexander The 1st
    Commented Jan 1, 2023 at 23:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .