Paper to refer to: https://emb3d.mitre.org/assets/EMB3D_Paper_09-23-24.pdf
| Threat Maturity | Threat Evidence |
| - | - |
@@ -59,81 +59,67 @@ Known Exploitable Weakness | Documentation of known weakness exploitation, such
Proof of Concept | Reference to research paper/report
Theoretic | Reference to research paper/report
Threat if plugins aren’t properly configured or secured.
Browser plugin issue is that t have to inject some javascript. On modern platforms like iOS and Android, the OS mediates (use system methods if available)
## Threat Actors
They don't create risks themselves, they help us think about the risks themselves.
Malicious website, attacking the pwm at scale. Net-fishing: verify with all means possible, that the site is authentic, and not masquerading? Is this a bonus feature?
Curious Spouse: See a list of sites I have passwords stored for? Spy on my personal life?
Evil maid: Lock when device sleeps
Vendor of the PWM itself (malicious insider / disgruntled employee): Best practices, code reviews, etc. - Placing a backdoor / exfiltration method?
Supply Chain Threat Actors: Network based functionality that loops back to the developer? Best practices, code reviews, etc. embedding of 3rd party code
User Enterprise (insider threat): Protect multiple vaults (needs a manager of the vault)
Curious neighbor: Mask all password data *************
Password managers should convey contemporary understanding of password security when creating a password. (Use password generation, not user input). BSI, NCSC -> passphrase is different. (minimum entropy??)
For consumers: Checking the passwords across the whole database. Reuse is an antipattern, but enterprise should be having their own policy.
Guidance:: What about mandated backdoor? (State Actors?) Out of scope. Either the system is lawful, or it isn't.
What about known breaches?
Guidance: From a user-perspective don't tell them their password is weak, because it can lead to fatigue.
Bar thief: User is using their phones in a bar - they unlock phone with pins, thieves see this, the phones are stolen, and then this is detected by the OS. (iOS had it first, now Android has it) Snatch Detection
Password manager cannot be considered in isolation, such as in the case where you are using a PWM in a device where you have a keylogger, this is a scenario where the threat on the device impacts the "healthy functionality of the password manager".
PWM is lost if the device is lost. The OS should improve its boundaries (shared memory, copybuffer etc.) -- it is out of our remit.
Getting access to the DB itself / intercepting the DB in the cloud. Encrypt at rest -> base level mitigation.
Malware is installed: Protecting against an attacker on the device attacker?
- Threat if plugins aren’t properly configured or secured.
- Browser plugin issue is that have to inject some javascript. On modern platforms like iOS and Android, the OS mediates (use system methods if available)
### 2.3 Threat Actors
Why they are relevant
- They don't create risks themselves, they help us think about the risks themselves.
- Think about who attacker is and what they're doing
- Does the attacker themselves create a risk? No but helps us this about what the actual risks are
Specific examples
- Malicious website, attacking the pwm at scale. Net-fishing: verify with all means possible, that the site is authentic, and not masquerading? Is this a bonus feature?
- Curious Spouse: See a list of sites I have passwords stored for? Spy on my personal life?
- Evil maid: Lock when device sleeps
- Vendor of the PWM itself (malicious insider / disgruntled employee): Best practices, code reviews, etc. - Placing a backdoor / exfiltration method?
- Supply Chain Threat Actors: Network based functionality that loops back to the developer? Best practices, code reviews, etc. embedding of 3rd party code
- User Enterprise (insider threat): Protect multiple vaults (needs a manager of the vault)
- Curious neighbor: Mask all password data
- Bar thief: User is using their phones in a bar - they unlock phone with pins, thieves see this, the phones are stolen, and then this is detected by the OS. (iOS had it first, now Android has it) Snatch Detection
### 2.4 Guidance
Situations and Goals
- Password managers should convey contemporary understanding of password security when creating a password. (Use password generation, not user input). BSI, NCSC -> passphrase is different. (minimum entropy??)
- For consumers: Checking the passwords across the whole database. Reuse is an antipattern, but enterprise should be having their own policy.
- What about mandated backdoor? (State Actors?) Out of scope. Either the system is lawful, or it isn't.
- What about known breaches? From a user-perspective don't tell them their password is weak, because it can lead to fatigue.
- Password manager cannot be considered in isolation, such as in the case where you are using a PWM in a device where you have a keylogger, this is a scenario where the threat on the device impacts the "healthy functionality of the password manager".
- PWM is lost if the device is lost. The OS should improve its boundaries (shared memory, copybuffer etc.) -- it is out of our remit.
- Getting access to the DB itself / intercepting the DB in the cloud. Encrypt at rest -> base level mitigation.
- Malware is installed: Protecting against an attacker on the device attacker?
- BIG BLANKET STATEMENT SOMEWHERE:
If the device is "owned" by a threat actor, there is nothing that a PWM can do to save itself. This is the worst possible case, from which there is no real recovery and nothing that the PWM standard can offer. That said, up until the point of "no return / full compromise", take classical opportunities.
- If the risk level is VERY high (i.e. Critical Infrastructure) - consider using a high protection approach (usability / convenience on a gradient toward "perfect" security )
- NICE FEATURES: Go to a website and change your password? Maybe the insider threat is just a tragic?
- Breach detection?
- Mitigation: Autolocking
If the risk level is VERY high (i.e. Critical Infrastructure) - consider using a high protection approach (usability / convenience on a gradient toward "perfect" security )
GUIDANCE:: NICE FEATURES
Go to a website and change your password? Maybe the insider threat is just a tragic?
Breach detection?
Mitigation: Autolocking
Generic Scenarios.
Generic Scenarios
- Someone or something has access to your device and DOES NOT know your credentials.
- Someone or something has access to your device and DOES know your credentials.
- [PHISHING] Someone or something has your credentials, but not access to your device.
- Biometrics
Start with the Passwords themselves - what value do they have when they are used. A primary purpose of a PWM is to enforce access to a password. A breached password is "in the wild" and has no access control that can be applied to it.
The threats to the access of the manager, not necessarily the post-factum security of their interface.
Boundary of the interface is internal to the PWM - it needs to be protected (based perhpas on product types):
- Copy/Paste Buffer is not in our remit
Browser-based: Boundary is more likely to be in scope.
Always use the highest security method on the OS / Device;
For example on Android there is CredentialManager (there is also a legacy method) Stop using them if there is something better that is available.
HERE ARE A FEW I HAVE BEEN THINKING ABOUT
- Keystroke logger - can theoretically be defeated if you use a password manager that does not type individual characters into the field
Context
- Start with the Passwords themselves - what value do they have when they are used. A primary purpose of a PWM is to enforce access to a password. A breached password is "in the wild" and has no access control that can be applied to it.
- The threats to the access of the manager, not necessarily the post-factum security of their interface.
- Boundary of the interface is internal to the PWM, it needs to be protected (based perhpas on product types): Copy/Paste Buffer is not in our remit
- Password manager lost if the device is lost, in this case OS should improve its boundaries - should not be mandated by a standard
- Securing the copybuffer is out of scope but might want to specify a timeout or recommend that?
- Boundary between scope of password manager as an application itself and another application or the operating system
- Browser based - boundary is more likely to be in scope
- Different types are likely to have different constraints
- Always use the highest security method on the OS / Device; For example on Android there is CredentialManager (there is also a legacy method) Stop using them if there is something better that is available.
- Not up to a password managers to judge a password, only to guard it
- When password manager generates a password should it clarify the generation mechanism? It might not enhance security for the user
### 2.5 Threats
Note: not able to discuss these in depth during this meeting
| Threat Maturity | Threat Evidence |
| - | - |
@@ -155,17 +141,6 @@ HERE ARE A FEW I HAVE BEEN THINKING ABOUT
