Better n'th character and m'th character handling. It's bad having to show pwd in big text.
Feature request.
How about doing something to limit the exposure of a secret word / phrase when asked for the nth and mth character. In some cases exposing the characters can be avoided entirely in others at least restricting the exposed information to the minimum would be ideal. Right now the easiest way of handling such things is viewing the whole 'password' in large text (which conveniently numbers the characters). Which is terrible, especially in public. In small text its less bad but doesn't number the characters so isn't really helpful.
Being able to expose only the requested characters or 'copy nth character' would make such things at least not a complete 'fail'.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided
Referrer: forum-search:nth character and m'th character handling
Comments
-
Hi there @AWinfield
Ideally, we'd be in a situation where websites or apps don't ask you for partial passwords. There's no evidence of them being any more secure than a full password, and as you've noticed, they represent a bit of a usability hurdle, especially because they can't be autofilled. My previous bank used to request 3 separate characters from my password which resulted in me using a non-random password and counting through the characters in my head to sign in! It was one of the reasons I moved away from that bank. Unfortunately, it does usually seem to be banks and other financial institutions that have some... let's say "interesting" ideas about best security practices when it comes to signing in.
Yours is a tricky question to answer, because we don't want to endorse (or even be seen to endorse) anything but the best security practices, which as of writing, is a strong, random password and two-factor authentication where available. My personal worry is that by making it easier to use partial passwords, we're only really putting a band-aid on the problem, rather than addressing the bigger issue which is that, in 2022 and beyond, no website or app should ever be asking for partial passwords. I'd recommend sending the app or website your feedback about this, and specifically mention that using a partial password makes autofill impossible, leading to a troublesome user experience, or (even worse) using an insecure password because you'll have to remember it.
I'll pass this along to the product team for their consideration. I can't promise if or when we'll implement this, for the reasons shown above, but do keep an eye on the release notes when you update 1Password to see what's new. Thanks for your feedback. :)
— Grey
ref: IDEA-I-2084
0 -
You have to kick the banks they seem to love dual password with one being 'partial' it is security theatre but something that can't be avoided.
0 -
@AWinfield – We're trying! 😄 One of the things we're hoping will push them in the right direction is our blog post:
I would love to see banks and other financial institutions adopting best practices across the board, but it's a hard battle to win.
0 -
Excellent to see this advice being actively promoted.
When you write your next letter, it would be marvellous if you could also encourage them to OFFER at least (if mandating is too intrusive), then to at least OFFER support for MFA via FIDO2 / WebAuthn hardware tokens such as Yubikey.
Far too many banks have decided to meet EU security legislation by implementing the weakest form of MFA, i.e. by sending texts, which as you know, are not even remotely secure. It would be laughable if the subject was in any way funny.
I find it staggering that these large institutions with vast IT resources are so completely hopeless when it comes to implementing modern security frameworks. One of my banking customers in a former life had 1000's of user licenses for their analytical risk management software, so they seem to take that seriously. But when it comes to retail banking and the need to keep their customers secure, they relying on SMS messages for 2FA??? Bizzare.
0 -
@Chippy_boy I work in a banking environment, and at the same time being a bank customer myself, I have an idea why banks invent all these "interesting" but actually pointless security measures.
The really important private bank customers - the ones with the money - are old, and are not computer proficient. They abhore changes. They only understand very simple and straightforward things if it comes to IT. They just want login and do their stuff. To keep these people, banks need to create security measures these people are able to understand and use. Typing some partial password letters, or reading a number from a text message is something they are able to do. Using some password manager with a 20 character random password on every account isn't something they are able to do - it's too big a barrier to get into this.
Using mobile phones and authentication apps - a barrier.
Using mfa authentication - a barrier.
Not only a barrier for hackers, but also a barrier for computer illiterate older customers. They rather change to a bank with less security frontend than adopt state of the art authentication measures. It's also some kind of vendor lock-in the other way round: once they got used to one scheme, customers don't change to other banks with different (no matter more cumbersome or less cumbersome) authentication schemes.0 -
Hi @Tertius3 Thanks for your insightful comments. I find it easy to believe that what you say is true.
Having said that, I cannot understand why they do not offer things like Yubikey support as an option, for their more tech savvy customers. In the great scheme of things and with the banks' VAST IT resources, the development and support costs of doing this must surely be trivial. I'd imagine there would be a strong ROI in fact, both in terms of reduced fraud, and also in marketing mileage, promoting themselves as being the most secure bank, immune from phishing attacks. I'd imagine a lot of customers would find the option of moving to a bank where you cannot be hacked by phishing, quite appealing.
Of course there is always going to be resistance to change (and inability to change with some folks) but to offer support for something is not the same as requiring it.
0 -
@Chippy_boy Well, my primary bank (and that's also the bank I work for with an IT outsourcer) asks for a 3 digit branch id, 9 digit account number, and a 6 character alphanumeric pin for online banking login. The pin cannot have more than 6 characters. Branch id and account number are not secret. This means my private important account is actually protected by a 6 character alphanumeric password. That's not really security.
The bank also offers a reasonably state of the art secure login with userid and long complex password. Would be the solution, however it's not possible to disable the branch+account+pin login after creating a userid login, so it stays unsecure!I contacted their online banking support asked for state of the art pin lengths and characters, and for the possibility to disable the insecure pin login. It was declined and said there were some kind of internal measures and checks that will always make my login secure, albeit the short pin.
Actually, this bank has very strict internal security policy for the intranet accounts of their employees for more than 20 years. Personal accounts, state of the art password complexity rules, password length enforcement, and mandatory change every 60 or 90 days. Nothing to complain about.
About Yubikey: this is an additional thing to implement server side and to give customer support for. Since the existing password-only implementation works and is declared secure by corporate and legal auditors, there is no need for the bank to implement anything more. If the law mandate it, yes, but since it doesn't, no. Implementation+support costs money with no visible return, so it's not done. Refunds due to inferior security are probably less than the costs for a better implementation. Banks don't advertise with "we have the best login security". They advertise with their banking products instead.
I stopped thinking about these issues.
0 -
"About Yubikey: this is an additional thing to implement server side and to give customer support for. Since the existing password-only implementation works and is declared secure by corporate and legal auditors, there is no need for the bank to implement anything more. If the law mandate it, yes, but since it doesn't, no. Implementation+support costs money with no visible return, so it's not done. Refunds due to inferior security are probably less than the costs for a better implementation. Banks don't advertise with "we have the best login security". They advertise with their banking products instead."
Opportunity missied, IMO. And I cannot believe the overall ROI is negative, both in terms of stolen money being refunded, desperately unhappy customers impacted and damage to reputation. And missed opportunity. I think it's laziness and perhaps a fear of increased customer support overhead with clueless customers locking themselves out of their accounts more frequently.
0
