#!/bin/bash
sleep 2.0
xdotool type "$(xclip -o -selection clipboard)"
Take this one: https://systemschimb.telekombanking.ro/login - enter a random user id, and behold the password input field:
- all characters are separated (not one password field, but 10-15 ones)
- some characters are randomly grayed-out (you're not supposed to enter all the characters of your password)
Using a shared secret in addition to a salted password is probably acceptable, although how much extra security it gives is debatable.
(if they ask for 2 characters, assuming a-zA-Z0-9 you're talking maybe 4k permetations, and then you know 2 characters)
A 10 character 64 symbol phrase would take 64^10, or 1e18 guesses
5 lots of 2 characters 64 symbols would take 5*64^2, or 20k guesses
And all this to protect for keyloggers. Probably a hardware token second factor is more effective.
They then loose me as a customer, and everybody else who I can influence.
It was (is?) common practice to have a visual keyboard to enter the password in extremely sensitive applications like banking. This prevents the password from being captured by keyloggers and from being saved by the browser, because malware automatically extract and collect these, which was a very real issue with banking.
We did something similar for call center caller authentication (you don't want the operator to get the whole PIN of the user, so he asked only for e.g. two characters). Not that this would be very useful, security-wise.
Wouldn't this be way easier to crack if the password hashes were leaked? Once you crack one 5-letter hash, you can trivially crack the one that shares 4 characters with it, and do that repeatedly until you have all 10 characters.
You're reducing the effective search space not by a factor of 252 (8 bits of entropy, which would often be acceptable) but to its square root, losing half of the entropy.
Although it seems like security theatre, the PIN solution actually sounds more useful. The typical attack on a system protected by PINs, like bank cards, is not cracking hashes offline - it's that the attacker tries the PINs on the live system and gets locked out after a small number of failures. Assuming the bad actor can't just initiate another call and ask for the other two digits.