Filling multiple (>2) fields on a login page

A number of banking related login pages in the UK ask for passwords in the form of "Please enter characters 4 , 9 and 10 from your password".

https://creditcards.virginmoney.com is one example of this.

Fortunately the fields have ids that map to the characters, e.g. randomPassword_1, randomPassword_8, …, randomPassword_n where n is the character in the password.

I've been trying to save this into 1Password as part of the 'Saved Form Details' as suggested here: https://discussions.agilebits.com/discussion/81785/need-three-fields-filled-on-one-page-for-login. Specifically promising was the mention there that 'This trick supports a few different attributes including name, id, and placeholder. '.

If I save the login manually through the 1Password extension by default it saves the form details with the name HTML attribute as the label in 1Password which whilst works for filling the page, is unfortunately unhelpful as this attributes value does not map to the characters in the password.

If I then edit the label names in the 1Password Login's Saved Form Details to the value of the id attribute, e.g. randomPassword_8, 1Password then stops filling anything entirely (even the fields where the label still matches the name rather than id).

Why might that be happening? And is there any way to get this to work?


1Password Version: 7.0.7
Extension Version: 4.7.2
OS Version: 10.14 Beta (18A371a)
Sync Type: 1Password

Comments

  • littlebobbytables
    littlebobbytables
    1Password Alumni

    Hi @jgarnham,

    That approach won't work by editing a Login item saved by the extension, it only works on Login items that were created from inside the main 1Password application. It's doubtful it will work anyway and your best bet is probably something called Large Type. The reason I'm doubtful is any Login item set up to try and fill a page like that would need a field entry per character. When evaluating whether this is a correct approach though one of the things we factor in is how many fields from the Login item did we use when filling and 3 out of n is a really poor percentage. I do think you're best best is Large Type and I say that as somebody based in the UK and used to this kind of nonsense from the banks.

    As an aside, have you ever asked yourself how they can confirm individual characters from your password? I don't know either but what I do know is security breaches where they didn't protect the stored password are usually highlighted for their lax precautions.

  • jgarnham
    jgarnham
    Community Member

    @littlebobbytables That's a shame, I've been using Large Type previously but for Virgin Money in particular it makes the log-in flow take a long time as you need 6 individual characters, 3 from your password and 3 from your passcode.

    I have thought about how they confirm individual characters, I can't in my mind figure out how they store the password/passcode securely when they require individual character input. Even with one way hashes per character it'd insecure. Perhaps salted too makes it marginally better? Hmm.

  • littlebobbytables
    littlebobbytables
    1Password Alumni

    Hi @jgarnham,

    That's like the RBS, password and PIN with three from each so I know what you're going through. Even with salting, if they're storing individual characters it drastically cuts down the search space as each is in isolation from the others.

    Turns out the poor Canadians have it even worse than us. I was helping a customer and it prompted a question to my fellow Canadian colleagues, did a particular bank really secure your accounts online with a 4/5 digit PIN? (I think 4 but either way awful) and I was told that was pretty normal for Canadian banks. Now that scared me.

    I know a guy who works in one of bank's fraud departments and while they're never able to go into all the details but do monitor a number of factors and adjust their threat detection based on the results, all of which we're oblivious to. I still wish they would adopt sensible password requirements though.

This discussion has been closed.