Interaction Overview

These are all the Minimal Working Examples for the 39 Interactions we found in our Paper.

Usecase S-01: Simple login and password
Domain Matching
Usecase D-01: Different subdomain with the same login
Usecase D-02: Different domain with the same login
Usecase D-03: Different login on different subdomain
Usecase D-04: Different protocol with the same login
Usecase D-05: Redirects after login
Usecase D-06: Login in Iframe pointing to different domain
Usecase D-07: Different Services on different Paths of the website
Input Fields
Usecase I-01: Input Field Name or ID includes 'password' substring for OTP fields
Usecase I-02: Input Field has misleading or unusual name (e.g. 'auth' or 'IDToken1' for username fields)
Usecase I-03: Input Field has misleading or unusual type (e.g. 'password' for TOTP or 'user' for username fields)
Usecase I-04: Autocomplete tags are used within input fields (e.g. autocomplete=username)
Usecase I-05: No information on type of input field (e.g. no hints in ID, name, type or other attributes)
Usecase I-06: form with <textarea> for username does not match for autofill
Usecase I-07: Input field has no type attribute
Usecase I-08: Input-Field has a max-length that leads to truncated passwords
Usecase I-09: Website manipulates input data to a semantical equivalent (e.g. changes email to uppercase), might not be matched to existing accounts
Additional Elements (Auth)
Usecase AA-01: Multiple input fields are used for single (authentication-related) input, e.g. 5 input fields for 1 5-letter PIN or TOTP
Usecase AA-02: Multiple Login-Buttons (e.g. user+pw-fields, google sign in, sso...)
Usecase AA-03: Site includes more authentication-related forms than necessary (e.g. login + registration)
Usecase AA-04: Site includes more necessary fields for authentication (e.g last name additionally to user+pw)
Additional Elements (Non-Auth)
Usecase AN-01: Multiple password and login fields on an admin panel
Usecase AN-02: Checkboxes to remember (auth and non-auth related)
Usecase AN-03: Unrelated elements that shouldn't be touched by javascript
Usecase AN-04: Submit button unrelated to auth that should not be blocked by a pwm
Web Standards
Usecase W-01: Login using Basic Auth
Usecase W-02: Loading files secured by Basic Auth
Non-Web Standard Forms
Usecase N-01: No form tag around the login fields sending the (login-)data via ajax
Usecase N-02: Custom WebComponent-Tag as form element
Usecase N-03: Submit-Button is a div with role=button.
Usecase N-04: Form Submit Button is not part of the form itself.
Usecase N-05: ASP.NET WebForm as login method
Usecase J-01: Hidden field (e.g. display:none HTML-style)/Not all relevant authentication-related fields initially visible
Usecase J-02: Enable Submit-Button on KeypressEvent
Usecase J-03: Multiple login steps on one page; only one input field (e.g. username) visible in first step, more (e.g. passwords) showing up in further steps
Usecase J-04: Multiple login steps over multiple pages; only one input field (e.g. username) visible in first step, more (e.g. passwords) showing up in further steps
Usecase J-05: Site manipulates input in some way (e.g. substitutes with ****, adds whitespaces, deletes automated inputs)
Usecase J-06: Site has two password fields: A real one (initially hidden) and a dummy one (initially shown). On interaction with the field, they swap, leading to the password manager filling the dummy, while no visual changes occur.
Usecase T-01: Delay initialisation of authentication fields
Usecase T-02: Delay of 2fa field