The Credentials object is representing any type of credential asset like;

  • Passwords
  • Login keys
  • Encryption keys
  • Signing credentials/keys
  • MFA tokens
  • Hashing keys

The main purpose of credentials in a model is to represent how difficult it would be to guess, find, steal, use and reuse them.Some of these actions depend on the User properties NoPasswordReuse and SecurityAwareness. Others depend on the location of where these credentials can be found or if they might have been disclosed.

It is in most cases recommended to connect a Credentials object to each Identity object in a model.



Connecting a Credential object to an Identity object represents the Credentials necessary to use the Identity. If a user or an attacker possess the Credentials, it can impersonate the Identity.


Credentials "Username & Password" allows use of the Identity "User Account".

For MFA, please see the Nested Credentials section below.


Credentials can be connected to Data in four different ways; InfoContainment, EncryptionCredentials, SigningCredentials and Replica.


InfoContainment is the most commonly used connection type and represents that the Credentials can be read from the Data once Read is achieved on Data. This connection is suitable for representing both a location (like a configuration file) where the Credentials fan be retrieved but also for default Credentials or disclosed/leaked Credentials.

For system-to-system communication, it is not unusual that for instance a web application has the credentials of a database stored in configuration files. This is modeled as follows.


The WebServer's configuration contains the Credentials used to access the DatabaseContent via the DatabaseUserIdentity Identity.

If Credentials are either trivial/default or might have been leaked with some probability, it can be modeled using an InfoContainment to a (public) location that the attacker has got access to.


Representing leaked or default credentials is done using InfoContainment to a public Data object. The likelihood of the Credentials being leaked can be adjusted using the DataNotPresent property of the Data (rockyou.txt) object.


If a Credentials object is connected to a Data object with EncryptionCredentials, the Data is encrypted with the Credentials. In other words, in order to Read the Data, you also must gain access to the Credentials object.


The SigningCredentials connection is used for stating that you can not do Write on Data unless you also have the Credentials object connected with SigningCredentials. This is useful for modeling supply chain structures where signing of applications is used. You need to both gain Write access to the Data (representing for instance a software repository) and also gain access to the Credentials object in order to successfully Write to that Data.


In order to successfully write to a software repository where signing is in place, the Credentials used for signing also needs to be acquired.


Since, technically speaking, the Credentials object inherits from the Information object in coreLang, the Information property Replica is also present for Credentials. If the Credentials are replicated then writing, deleting, or denying them requires disabling the replicas which require access to all of the connected Replicas.

Nested Credentials

When more granular credential modeling is required, it can be acquired by using nested Credentials objects.


When an additional token is required for using the Credentials, this is modeled by connecting an additional Credentials object to the first Credentials object. In the following example, it is not enough to know the (default) username and password, but the attacker also need to gain access to the token in order to use the Credentials that are linked to the Identity.


The "Username & Password" has a default password set, i.e. publicly accessible via for instance documentation. However, the Token is also necessary.

When connecting a token (represented by an additional Credentials object) to a Credentials object, start from the "Username & Password" and release the connection at the "Token". Select the upper link type, i.e. "ConditionalAuthentication (requiredFactors --> credentials)".



Attack step nameAttack step purpose
AttemptAccessPrerequisite to Read/Write/Delete/Use.
AttemptUsePrerequisite to using credentials.
CredentialTheftSucceeding with stealing the credentials. Can be due to reading a data set where the credentials are present.
CredentialsReuseSucceeding with using the same credentials for authenticating as other identities. If one set of credentials is stolen from a user and the user has the PasswordReuse defense (partially or entirely) disabled, this attack step is applicable. Also, related to the Unique credential defense.
DeleteDeleting credentials from a Data the attacker has gained Write access to.
DenyDenying the Data object holding the Credentials also lead to denying the Credentials.
GuessCredentialsSucceeding with a dictionary attack targeting the Credentials. Related to the NotGuessable defense on Credentials.
ReadReading the Credentials. Prerequisite to AttemptUse.
UseUsing Credentials to authenticate and impersonate an Identity.
UseLeakedCredentialsSame as CredentialTheft but related to the NotDisclosed Credentials defense parameter.
WriteAltering Credentials.


Defense nameDefense purpose
NotDisclosedRepresents the (inverted) probability that the Credentials are disclosed/leaked.
NotGuessableRepresents the probability that the Credentials are strong enough not to be retrieved using a dictionary attack.
NotPhishableRepresents the probability that the Credentials are not possible to reuse even if successfully phished. Such credentials are for instance time limited login tokens.
UniqueRepresents the probability that this particular credential is not used elsewhere in the model as well.