Live data from Hacker News

Partial password usability sucks

gaevoy.com

61–70 of 87 posts

Re: Partial password usability sucks

#61
post #41
post #38

Earlier quoted context omitted.

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.

Re: Partial password usability sucks

#62
post #33

Earlier quoted context omitted.

> 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 Maybe. > One example I just thought of: Ask for 75% of the passwo…

> 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 remem…

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.

Re: Partial password usability sucks

#63
post #20

Earlier quoted context omitted.

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.

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

Re: Partial password usability sucks

#64
post #57

Earlier quoted context omitted.

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

Re: Partial password usability sucks

#65
post #23

> 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 r…

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 rememb…

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

Re: Partial password usability sucks

#66
post #23

> 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 r…

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 rememb…

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.

Re: Partial password usability sucks

#67

> 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 r…

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.

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.

Re: Partial password usability sucks

#68

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.

Re: Partial password usability sucks

#69
post #23

> 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 r…

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 rememb…

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

Re: Partial password usability sucks

#70
post #20

Earlier quoted context omitted.

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.

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