apple
RFC: A quirk that prevents the suggestion of saved passwords for unrecognized OTP fields
Background
This RFC proposes a new type of quirk that would make it possible for a browser or password manager to stop suggesting saved passwords when a site is asking the user for an app-generated or SMS-based one-time passcode (OTP).
When a user is redirected to a different page that asks for an OTP, the quirk will let the user enter the code without 'interference' of being suggested a saved password by the browser or password manager in certain situations, e.g. verifying a purchase transaction on their banking site, or their sign-in attempt on an enterprise site.
Ideally, this quirk should also improve the automatic one-time code autofill feature offered by iOS and macOS, as it becomes clear to the system and password managers that the page is expecting a one-time code instead of a saved password.
Examples
Verifying a purchase transaction
Some sites that offer products or services will offer a way of paying via bank-issued debit or credit card. Using this option will usually involve authentication through Visa Secure (aka Verified by Visa, for bank-issued Visa cards) or Mastercard SecureCode (for bank-issued Mastercards).
In practice, the user is redirected to a new page after they have entered their bank card details. The page is the user's bank communicating with them directly, and will ask the user to verify their identity using a one-time-password/PIN (OTP) that is delivered to the user via SMS. The OTP is generated by the user's bank and is required every time the user transacts online at a merchant that also provides the service.
A specific example of this is TGV Cinemas. Attempting to purchase a movie ticket will redirect the user to a payment gateway domain which again redirects to the user's bank domain specifically handling the Visa Secure transaction, eg. [Maybank](.webarchive file available upon request), as shown in the screenshot below:
Another example of this page includes one set up to handle [HSBC](.webarchive file available upon request) customers, as can be seen below:
The proposed quirk would then exclude these specific subdomains (eg. evgr-securepay.hsbc.com.my) from the browser's or password managers's saved password autofill suggestion as shown in yellow in the screenshots above, even when the user has a saved password for the domain itself (eg. hsbc.com.my).
Logins with enterprise SSO
Some enterprise domains that initiate the login process use an internal SSO service (eg. tied to the company email, eg. [email protected]) to complete authorization. This SSO service will also ask the user to provide an app-generated OTP, but might still be on the same subdomain or API endpoint and does not redirect to a special subdomain just for handling an OTP.
Example: Acme Corp. properties initiate their SSO authorization process when the user clicks a "Acme Employee Login" button and redirects the user to https://login.acme.corp/intranet/profile/AzureAD/Unsolicited/SSO. This page will ask for a username and password; and if correct, then asks for an app-generated OTP to complete the login process. Throughout the login process, the user stays on the same SSO page aforementioned. Only after completion, the user is redirected to another domain for online service.
The proposed quirk should be able to also exclude the above example page from the browser's/password manager's saved password autofill suggestion based on the HTML element name of the OTP field.
Proposed Quirk Format
I'd like to propose the following format for the quirks/websites-with-unrecognized-otp-fields.json file (name can be changed):
{
"domain.com": {
"passwordFieldNamesOrIds": [
"pwEnteredHere",
"password-field"
],
"otpFieldNamesOrIds": [
"sixDigitPin",
"sms-2FA-code",
"pin",
"otp"
],
"SpecifiedOtpPages": [
"domain.com/txn-verify/v2/authorizationOTP.do",
"otp-verification.domain.net"
]
},
// more entries go here //
}
This format would allow for specifying the examples described earlier:
{
"hsbc.com.my": {
"passwordFieldNamesOrIds": [
"password"
],
"otpFieldNamesOrIds": [
"password",
"verifyWithSmsOtp"
],
"SpecifiedOtpPages": [
"evgr-securepay.hsbc.com.my",
"hsbc.com.my/security"
]
},
"login.acme.corp": {
"passwordFieldNamesOrIds": [
"TEMPPASSWORD"
],
"otpFieldNamesOrIds": [
"OTPPASSWORD"
]
},
"maybank2u.com.my": {
"passwordFieldNamesOrIds": [
"my-password-input",
"password1"
],
"otpFieldNamesOrIds": [
"oneTimePin",
"tacVal",
"tacPin"
],
"SpecifiedOtpPages": [
"maybank2u.com.my/mbb/m2u/m9000/m2uFpxConfirmPayment.do",
"maybankcardsmsos.maybank.com.my"
]
}
}
Let's go over the details of this proposed format.
Details of the Proposed Quirk Format
Referencing the format of the password rules quirk and shared credential backends quirk, this quirk has multiple JSON objects at its root, with each object being the domain name of a website making up the quirk's individual entries. The main site name may be linked with entries in other quirk files, eg. password-rules.json or websites-with-shared-credential-backends.json.
Each entry is an object with the following keys: passwordFieldNamesOrIds, otpFieldNamesOrIds, and SpecifiedOtpPages.
passwordFieldNamesOrIds is an array of records defining the possible field names or IDs attached to the HTML field element for the password. The array must not be empty; it tells the browser/password manager to only suggest saved passwords, and not OTPs. An example of related HTML code:
<input type="password" name="TEMPPASSWORD" id="login-password-field" size="30">
otpFieldNamesOrIds is an array of records defining the possible field names or IDs attached to the HTML field element for the OTP. The array must not be empty; it tells the browser/password manager to only suggest OTPs, and not saved passwords. An example of related HTML code:
<input type="password" value id="tacPin" maxlength="6" size="8">
SpecifiedOtpPages is an array of records defining the specific web addresses that present an OTP challenge process originating from the main site name (i.e. the address only ever asks for an OTP, and never the saved password) to a user. This array can be empty; an omission of this array, such as the Acme Corp. login example, means that the site serves the OTP challenge in the same domain as the main site name, perhaps only with different endpoint addresses.
In the case of a main site that does ask for OTP on specific pages, the array would be present. E.g. above, Maybank processes their OTP challenges on both the same domain as their main site at maybank2u.com.my/mbb/m2u/m9000/m2uFpxConfirmPayment.do and also at a separate external domain maybankcardsmsos.maybank.com.my). The browser/password manager therefore should only offer OTPs on these specific web addresses and never a saved password, even if the name/ID/type attached to the HTML field element indicates that it is a password.
Reasons for the Proposed Quirk to Exist
-
It allows for more precise enforcement of password suggestions and improves the user's experience.
-
Allows iOS, macOS, or a password manager with OTP capabilities to correctly offer up the relevant the OTP in what I feel is a more efficient manner.
Credits + Q&A
Big thanks to @Cldfire, as their RFC inspired me to make this post. Any comments and questions are welcome below! 😊
@CasualDeveloper This is great! I think we can take some of your ideas and incorporate them into something we’ve been talking about in the project’s Slack group. Can you follow the steps in the README to request access to the Slack? Once you’re there, I’ll point you to the discussion we’ve been having about a more generalized version of this more akin to “classification heuristic overrides”.
