mitre-attack / attack-stix-data Goto Github PK

enterprise file, attack pattern with ID:

attack-pattern--035bb001-ab69-4a0b-9f6c-2de8b09e1b9d

property x_mitre_data_sources, value 'Network Traffic Flow' repeated twice

WMI Creation's description [Initial construction of a WMI object, such as a filter, consumer, subscription, binding, or provider (ex: Sysmon EIDs 19-21)] has been added to other data sources: Network Connection Created, Malware Content, OS API Execution, Host Status, and Active DNS.

Hi! I'm trying to query mitre to get the relevant APTs or TTPs of a certain indicator. I've tried to use Filter where my query is basically indicator.value = <my-indicator-value but I get nothing back. If anyone can help me out or point me in the right direction that would be great!

enterprise-attack file, element x-mitre-collection:

        "type": "x-mitre-collection",
        "id": "x-mitre-collection--23320f4-22ad-8467-3b73-ed0c869a12838",

Uuid inside Id is invalid - the first segment is 7-char long, should be 8

1.) In Release v13.1 : "external_id": "G0097" -- appearing in both "x_mitre_domains": "mobile-attack" and "enerprise-attack"

mobile-attack-13.1.json
17685: "external_id": "G0097",
17687: "url": "https://attack.mitre.org/groups/G0097"
17697: "description": "Bouncing Golf is a cyberespionage campaign targeting Middle Eastern countries.(Citation: Trend Micro Bouncing Golf 2019)",
21073: "description": "GolfSpy is Android spyware deployed by the group Bouncing Golf.(Citation: Trend Micro Bouncing Golf 2019)",
59771: "description": "Bouncing Golf delivered GolfSpy via a hosted application binary advertised on social media.(Citation: Trend Micro Bouncing Golf 2019) ",
63828: "description": "Bouncing Golf distributed malware as repackaged legitimate applications, with the malicious code in the com.golf package.(Citation: Trend Micro Bouncing Golf 2019)"

enterprise-attack-13.1.json
692360: "external_id": "G0097",
692362: "url": "https://attack.mitre.org/groups/G0097"
692372: "description": "Bouncing Golf is a cyberespionage campaign targeting Middle Eastern countries.(Citation: Trend Micro Bouncing Golf 2019)",

2.) In Release v13.1 : "external_id": "S0302" -- appearing in both "x_mitre_domains": "mobile-attack" and "enerprise-attack"

mobile-attack-13.1.json
19550: "description": "Twitoor is a dropper application capable of receiving commands from social media.(Citation: ESET-Twitoor)",
19570: "url": "https://attack.mitre.org/software/S0302",
19571: "external_id": "S0302"
38696: "description": "Twitoor can hide its presence on the system.(Citation: ESET-Twitoor)",
50166: "description": "Twitoor encrypts its C2 communication.(Citation: ESET-Twitoor)",
54579: "description": "Twitoor can be controlled via Twitter.(Citation: ESET-Twitoor)",
61597: "description": "Twitoor can install attacker-specified applications.(Citation: ESET-Twitoor)",
66798: "description": "Twitoor uses Twitter for command and control.(Citation: ESET-Twitoor)",

enterprise-attack-13.1.json
691943: "description": "Twitoor is a dropper application capable of receiving commands from social media.(Citation: ESET-Twitoor)",
691963: "url": "https://attack.mitre.org/software/S0302",
691964: "external_id": "S0302"
692181: "description": "Twitoor uses Twitter for command and control.(Citation: ESET-Twitoor)",

Hello,

In the function get_related(...) from the relationships microlibrary code snippet in file USAGE.md the fourth filter creates a situation where variable relationships is always empty.

I haven't tested every possibility but I get this result with functions:

• software_used_by_groups(thesrc)
• groups_using_software(thesrc)
• techniques_used_by_groups(thesrc)
• groups_using_technique(thesrc)
• mitigation_mitigates_techniques(thesrc)
• technique_mitigated_by_mitigations(thesrc)

It appears that by only filtering out the revoked objects everything works just fine.
I use the local data from file enterprise-attack.json for my work.

If someone could double check that'd be awesome.

PS: In the case I'm wrong there still is a mismatched quote with a double quote in that same line.

(Issue created as of v12.1)

For entries that are marked revoked or x_mitre_deprecated, it can be useful to note if one entry supersedes another.

For example, T1050:

https://attack.mitre.org/techniques/T1050/

redirects to

https://attack.mitre.org/techniques/T1543/003/

In enterprise-attack.json, there could be a field for attack-pattern--478aa214-2ca7-4ec0-9978-18798e514790 (T1050) that refers to attack-pattern--2959d63f-73fd-46a1-abd2-109d7dcede32 (T1543.003).

As far as I'm aware, the two entries don't have a link with each other to reflect one replaces the other.

Hi,

i'm not sure if this belong here...
maybe you can bounce it to the right people/repo.

Under Discovery -> Software Discovery there's 'Security Software Discovery'
Please also add "Backup Software Discovery" because that's a major factor with ransomware gangs.

In the 13.0 release, some techniques in the ICS bundle have kill_chain_phases.phase_name that don't match the x_mitre_shortname in any of the tactics in the bundle. Relevant documentation here.

For example, technique: attack-pattern--7374ab87-0782-41f8-b415-678c0950bb2a has a collection-ics kill_chain_phases.phase_name. However, there is no x-mitre-tactic with a collection-ics x_mitre_shortname.

hi, just got bedevilled by a bug until i realised that the attack relationships have the field
x_mitre_platforms

yet this is not listed in the documents, whereas it is for all other objects that use it. Just a heads-up. I have fixed the error anyway

Mobile-Attack object: missing "description" property (as shown below) and "kill_chain_phases" list is empty:

    {
        "x_mitre_domains": [
            "mobile-attack"
        ],
        "object_marking_refs": [],
        "id": "attack-pattern--11bd699b-f2c2-4e48-bf46-fb3f8acd9799",
        "type": "attack-pattern",
        "created": "2017-10-25T14:48:30.462Z",
        "revoked": true,
        "external_references": [
            {
                "source_name": "mitre-mobile-attack",
                "url": "https://attack.mitre.org/techniques/T1425",
                "external_id": "T1425"
            }
        ],
        "modified": "2018-10-17T01:05:10.699Z",
        "name": "Insecure Third-Party Libraries",
        "kill_chain_phases": [],
        "x_mitre_version": "1.0",
        "x_mitre_data_sources": [],
        "spec_version": "2.1",
        "x_mitre_attack_spec_version": "2.1.0"
    },

Added details. Actually, there are 14 of them in 'Mobile-Attack' missing 'description' field:
"attack-pattern--11bd699b-f2c2-4e48-bf46-fb3f8acd9799"
"attack-pattern--1f96d624-8409-4472-ad8a-30618ee6b2e2"
"attack-pattern--45dcbc83-4abc-4de1-b643-e528d1e9df09"
"attack-pattern--51aedbd6-2837-4d15-aeb0-cb09f2bf22ac"
"attack-pattern--6b846ad0-cc20-4db6-aa34-91561397c5e2"
"attack-pattern--831e3269-da49-48ac-94dc-948008e8fd16"
"attack-pattern--a21a6a79-f9a1-4c87-aed9-ba2d79536881"
"attack-pattern--a9cab8f6-4c94-4c9b-9e7d-9d863ff53431"
"attack-pattern--b765efd1-02e6-4e67-aebf-0fef5c37e54b"
"attack-pattern--b928b94a-4966-4e2a-9e61-36505b896ebc"
"attack-pattern--c91c304a-975d-4501-9789-0db1c57afd3f"
"attack-pattern--e30cc912-7ea1-4683-9219-543b86cbdec9"
"attack-pattern--f296fc9c-2ff5-43ee-941e-6b49c438270a"
"attack-pattern--f9e4f526-ac9d-4df5-8949-833a82a1d2df"

I would like to understand the relationship/link between both especially that they are both owned by MITRE. Is it safe to assume that CVE is more of an initial log open to the cyber security community at large, where as STIX-formatted ATT&CK is more of a standard form of sharing info, in particular this json here be it enterprise, mobile or ics ?

How do you reconcile both or do you treat them as two separate datasets?

As a reader of the documentation, I want the hyperlinks to additional resources to lead me information relevant to the current version of the data. Presently, many hyperlinks in the USAGE document lead to the STIX 2.0 documentation, even though we are now using STIX 2.1. These links should be replaced with links to the relevant sections of the STIX 2.1 spec document.

Hi,
Just a heads-up

I found a new field/property in the latest version, which is not reported in the USAGE.md file. I caught it because my input python classes (extensions to the OASIS Stix2 Python library) threw an exception while trying to parse the object, before translating into my schema language.
The property is "x_mitre_network_requirements": false,
the new class property is ('x_mitre_network_requirements', BooleanProperty()), (note i didn't set it as false by default)

I notice the USAGE.md file hasn't been updated for eight months. Might be a good time to amend the property table for Techniques and Subtechniques

Hi @ElJocko, I have found that the platforms of all MITRE ATT&CK ICS Techniques have not been added.
All ICS Techniques have "x_mitre_platforms": [ "None" ]

E.g.

The same happens also on the website https://attack.mitre.org/techniques/T0889/
where the associated assets

have Embedded platform:

There are at least 10 data source entries in the STIX file where the url is a broken link.
Here is one example where
"url": "https://attack.mitre.org/data-sources/DS0002" - broken (has a "-" in datasources)
"url": "https://attack.mitre.org/datasources/DS0002" - correct

        "type": "x-mitre-data-source",
        "id": "x-mitre-data-source--0b4f86ed-f4ab-46a3-8ed1-175be1974da6",
        "external_references": [
            {
                "source_name": "mitre-attack",
                "url": "https://attack.mitre.org/data-sources/DS0002",
                "external_id": "DS0002"
            }
        ],

file Usage.md, section Techniques:
https://github.com/mitre-attack/attack-stix-data/blob/master/USAGE.md#techniques

The type for element x_mitre_system_requirements should be string[] (string array instead of string).
At least according to actual data inside data files

I believe STIX versioning isn't properly implemented/applied to whatever is generating the current ATT&CK JSON.

From section 3.6 Versioning of the STIX 2.1 spec:

STIX Objects MAY be versioned in order to update, add, or remove information. A version of a STIX Object is identified uniquely by the combination of its id and modified properties. The first version of the object MUST have the same timestamp for the created and modified properties. More recent values of the modified property indicate later versions of the object. Implementations MUST consider the version of the STIX Object with the most recent modified value to be the most recent state of the object. For every new version of an object, the modified property MUST be updated to represent the time that the new version was created. If a consumer receives two objects that are different, but have the same id and modified timestamp, it is not defined how the consumer handles the objects. This specification does not address how implementations should handle versions of the object that are not current.

There are 422 attack-patterns in the current JSON that have non-matching creation/modification times and are missing the required revoked property. There are 297 attack-patterns that do have the revoked property. The first attack-pattern (['objects'][1]) in the is an example of an object that is clearly versioned, but doesn't have the requisite properties.

attack-pattern--0042a9f5-f053-4769-b3ef-9ad018dfa298 is versioned but missing 'revoked':
created: 2020-01-14T17:18:32.126Z
modified 2022-04-25T14:00:00.188Z

['objects'][1].keys()
['x_mitre_platforms', 'x_mitre_domains', 'object_marking_refs', 'id', 'type', 'created', 'created_by_ref', 'external_references', 'modified', 'name', 'description', 'kill_chain_phases', 'x_mitre_detection', 'x_mitre_is_subtechnique', 'x_mitre_version', 'x_mitre_modified_by_ref', 'x_mitre_data_sources', 'x_mitre_defense_bypassed', 'spec_version', 'x_mitre_attack_spec_version']

Provide tags when releasing a new version of MITRE ATT&CK data
as done for the https://github.com/mitre/cti repository.

There are values in external_references that cause problems with validating against the OASIS schemas. The schemas specify "format: uri" for the "url" attribute (schemas/common/url-regex.json), and this may enforce validation of content against RFC3986, depending on the toolset that consumes ATT&CK data.

The problematic values include:

"url": "http://download.ahnlab.com/global/brochure/[Analysis]Andariel_Group.pdf"
"url": "https://global.ahnlab.com/global/upload/download/techreport/[Analysis_Report]Operation%20Kabar%20Cobra.pdf"
"url": "https://www.fireeye.com/blog/threat-research/2018/10/triton-attribution-russian-government-owned-lab-most-likely-built-tools.html "
"url": "https://www.dragos.com/wp-content/uploads/CRASHOVERRIDE2018.pdf "
"url": "https://www.welivesecurity.com/wp-content/uploads/2017/06/Win32_Industroyer.pdf "
"url": "https://dragos.com/blog/crashoverride/CrashOverride-01.pdf "
"url": "https://www.wired.com/images_blogs/threatlevel/2010/11/w32_stuxnet_dossier.pdf "
"url": "https://redcanary.com/blog/how-one-hospital-thwarted-a-ryuk-ransomware-outbreak/ "
"url": " https://unit42.paloaltonetworks.com/ironnetinjector/"
"url": "https://www.zscaler.com/blogs/research/super-mario-run-malware-2-\u2013-droidjack-rat"
"url": "https://www.virustotal.com/gui/file/0b4c743246478a6a8c9fa3ff8e04f297507c2f0ea5d61a1284fe65387d172f81/detection "
"url": "https://www.winosbite.com/verclsid-exe/\u00a0"
"url": "https://blog.malwarebytes.com/101/2016/01/the-windows-vaults/ "

To meet RFC3986 the square brackets should be percent-escaped as "%5B". Leading/trailing spaces should be removed, and it looks like the \u2013 and \u00a0 characters should also just be removed from the URL.

File enterprise-attack, the following 2 IDs are referenced in relationship objects but are not defined in the file:

malware--c19cfc89-5ac6-4d2d-a236-70d2b32e007c
malware--c41a8b7c-3e42-4eee-b87d-ad8a100ee878

from the usage example given,
load_from_file takes 3-4 seconds.

is there a way to optimize this?

def main(argv):
    try:
        mitreId = argv[1].upper()
        src = MemoryStore()
        src.load_from_file("enterprise-attack-9.0.json")
        object = src.query([ Filter("external_references.external_id", "=", mitreId) ])[0]

i'm expecting quite a number of python script execution.

Hello,

I am opening this issue to discuss about the Mitre ATT&CK data usage regarding the terms of use.

Context :
I submitted a contribution to the CNCF project named FalcoSecurity Rules to provide a Mitre ATT&CK base knowledge to the project, using attack-stix-data for the data.

It is important to mention that I am not copying the data.

Since this repository has a custom License, it does not appear in the list of licenses compliant with the CNCF.
The terms of use in the attack-stix-data license are not problematic for the data usage made in the contribution code, but the issue is only related to the CNCF policies.

As a consequence, the pull request is pending for FalcoSecurity Rules until the maintainers can file a license exception to the CNCF.

As maintainers, have you experienced the same kind of problems for other contributions to CNCF projects ? Or does a contributor of your repositories already faced a similar issue ?

Thanks in advance !

Bundles in STIX 2.1 don't use the spec_version property. From 2.0 to 2.1 spec_version was moved to the objects so that a single bundle could hold objects of differing spec versions. Including it on the bundles may confuse some STIX implementations.

cc @chisholm

I'm working with the ATT&CK v11.2 json, and I'm finding some weirdness in the data that is breaking my scripts. Maybe this is expected behavior, but can anyone explain?

attack-pattern--06780952-177c-4247-b978-79c357fb311f is revoked but not x_mitre_deprecated.
attack-pattern--36675cd3-fe00-454c-8516-aebecacbe9d9 is revoked but not x_mitre_deprecated.
attack-pattern--6636bc83-0611-45a6-b74f-1f3daf635b8e is revoked but not x_mitre_deprecated.
attack-pattern--6747daa2-3533-4e78-8fb8-446ebb86448a is revoked but not x_mitre_deprecated.
attack-pattern--772bc7a8-a157-42cc-8728-d648e25c7fe7 is x_mitre_deprecated but not revoked.
attack-pattern--7fd87010-3a00-4da3-b905-410525e8ec44 is x_mitre_deprecated but not revoked.
attack-pattern--c4ad009b-6e13-4419-8d21-918a1652de02 is x_mitre_deprecated but not revoked.
attack-pattern--f879d51c-5476-431c-aedf-f14d207e4d1e is x_mitre_deprecated but not revoked.

Object property extensions are currently being implemented under the depreciated 2.0 standard. Where custom properties are inserted into the object's json, with 'x_' appended to the property name. This mode of extension was deprecated in the STIX 2.1 standard, making way for a new standard documented in section 7.3 of the current documentation.

To keep in line with the 2.1 standard, all Mitre implemented property extensions will need to be converted to the new format.

This will involve implementing an 'extension-definition' for each set of extended properties made to existing STIX objects, then referencing said 'extension-definition' under the 'extensions' property found in most STIX objects.

I have included an example of what is needed below. Section 7.3 of the current documentation has better examples.

Below defines an extension definition.

{
    "id": "extension-definition--12345678-GUID-GUID-0000",
    "type": "extension-definition",
...
    "extension_types": [ "toplevel-property-extension" ],
    "extension_properties": [
        "mitre_platforms",
        "mitre_domains"
    ]
}

Below defines an extended object.

{
    "id": "attack-pattern--12345678-GUID-GUID-1111",
    "type": "attack-pattern",
...
    "mitre_platforms": [
        "Windows"
     ],
    "mitre_domains": [
        "enterprise-attack"
    ],
    "extensions": {
        "extension-definition--12345678-GUID-GUID-0000" : {
            "extension_type": "toplevel-property-extension"
        }
    }
}

Hi,

I am not 100% sure, whether relationships used in Attack, both existing Stix ones and new Attack ones, have additional attack-specific fields. Can you advise please?

I note that the table at this link (https://github.com/mitre-attack/attack-stix-data/blob/master/USAGE.md#extensions-of-the-stix-spec) says most of the attack-specific properties are not used by relationships. But two properties, "x_mitre_modified_by_ref" and "x_mitre_attack_spec_version" do not specifically prohibit relationships.

Can you advise please?? Do the relationships used by Attack, including the existing Stix ones and the additional attack ones, have Attack-specific property fields??

Thanks

In the file attack-stix-data/enterprise-attack/enterprise-attack.json, the UUID for the x-mitre-collection is invalid (too short):

"id": "x-mitre-collection--402e24b4-436e-4936-b19b-2038648f489",

The last group should be 12 characters long. It is 11 characters long.

Since mobile-attack-4.0.json the relationship relationship--f825f5ea-3815-431f-b005-4c01b8b2fed9 is invalid.
The modified timestamp is before the created timestamp.

when we build a copy of the attack website for our sneakernet enclave, we typically use the mitre/cti copy of the stix. But our mirror of this site is behind so I saw that the "same" file is in mitre-attack/attack-stix-data. The bundle IDs are the same, but when looking at the source repos I discovered the content is very different. How can the bundle ids match for these two different files!?

stix-capec.json.converted.json.zip

• combine/format the text into description
• translate x_mitre_xxxx properties
• map parent-child technology as sub-technology
• organize the data for attack-workbench compatible(including relationship generating)

If the work could be helpful, I would opensource the convent tool later and make a more official pr.

As a user, I want to know what version of the ATT&CK spec is represented inside of a given collection.

Add x_mitre_attack_spec_version to x-mitre-collection type objects. See also center-for-threat-informed-defense/attack-workbench-frontend#251.

I'm pretty sure HKLU from HKLU\\Software\\Microsoft/Windows\\CurrentVersion\\RunOnce doesn't exist. Text is inside the description key

{
            "object_marking_refs": [
                "marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
            ],
            "id": "relationship--e1cf08cf-e483-44a1-bdfe-cdfa424d69e5",
            "type": "relationship",
            "created": "2021-06-10T15:48:43.867Z",
            "created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
            "external_references": [
                {
                    "source_name": "Malwarebytes Kimsuky June 2021",
                    "url": "https://blog.malwarebytes.com/threat-analysis/2021/06/kimsuky-apt-continues-to-target-south-korean-government-using-appleseed-backdoor/",
                    "description": "Jazi, H. (2021, June 1). Kimsuky APT continues to target South Korean government using AppleSeed backdoor. Retrieved June 10, 2021."
                }
            ],
            "modified": "2021-06-10T15:48:43.867Z",
            "description": "[AppleSeed](https://attack.mitre.org/software/S0622) has the ability to create the Registry key name <code>EstsoftAutoUpdate</code> at <code>HKLU\\Software\\Microsoft/Windows\\CurrentVersion\\RunOnce</code> to establish persistence.(Citation: Malwarebytes Kimsuky June 2021)",
            "relationship_type": "uses",
            "source_ref": "malware--295721d2-ee20-4fa3-ade3-37f4146b4570",
            "target_ref": "attack-pattern--9efb1ea7-c37b-4595-9640-b7680cd84279",
            "x_mitre_version": "1.0",
            "x_mitre_modified_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
            "spec_version": "2.1",
            "x_mitre_attack_spec_version": "2.1.0",
            "x_mitre_domains": [
                "enterprise-attack"
            ]
        }

Hi, this ticket is to open a discussion about cyclic references in mitre data.

In stix-capec.json, some attack pattern have refs that reference the data in the 2 sides.

The attack pattern 'attack-pattern--9ad2c2eb-9939-4590-9683-2e789692d262' is referencing 'attack-pattern--92cdcd3d-d734-4442-afc3-4599f261498b' through x_capec_can_follow_refs

And The attack pattern 'attack-pattern--92cdcd3d-d734-4442-afc3-4599f261498b' is referencing 'attack-pattern--9ad2c2eb-9939-4590-9683-2e789692d262' through x_capec_can_precede_refs

This situation is complex to handle in a data absorption point of view as its impossible to get the full information with only one round of data ingestion. For example in this case the attack-pattern--9ad2c2eb-9939-4590-9683-2e789692d262 will not be created with the correct x_capec_can_follow_refs as the attack pattern to link will not yet be created. To get all data its mandatory to absorb the file twice to finally get everything but I dont think its a good way to handle that cyclic reference.

So the question is more about "there is a way to remove the cyclic reference?" Maybe using a stix relationship instead of a ref?
That will be something like that ATTACK01 - can-follow -> ATTACK02 that could be easily translated to can-precede when looking on ATTACK02?

Ensure strong password length (ideally 25+ characters) and complexity for service accounts and that these passwords periodically expire. Also consider using Group Managed Service Accounts or another third party product such as password vaulting. (Citation: AdSecurity Cracking Kerberos Dec 2015)

This should be changed based upon the NIST guidance below please.

https://pages.nist.gov/800-63-3/sp800-63b.html

A.2 Length
Password length has been found to be a primary factor in characterizing password strength [Strength] [Composition]. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.

The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted. In order to prevent an attacker (or a persistent claimant with poor typing skills) from easily inflicting a denial-of-service attack on the subscriber by making many incorrect guesses, passwords need to be complex enough that rate limiting does not occur after a modest number of erroneous attempts, but does occur before there is a significant chance of a successful guess.

Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.

Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.

A.3 Complexity
As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification.

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.

Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets.