4 ms·

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

> 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 https://security.stackexchange.com/a/194818/47800 [1] https://security.stackexchange.com/a/7479/47800 https://security.stackexchange.com/a/7479/47800 [2] https://security.stackexchange.com/a/196430/47800 https://security.stackexchange.com/a/196430/47800

dickeytk 8y ago
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.
- gregmac 8y ago
  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.
  - inetknght 8y ago
    Not only that, but enumerating all possible combinations of 4 or 5 characters from a 20 character password would be untenable.
    - munk-a 8y ago
      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.
    - myhf 8y ago
      20 choose 5 = 15504. You could enumerate them all in less than a second and store all the hashes in less than a megabyte.
    - dickeytk 8y ago
      Again, not defending this I'm just being technical. You wouldn't need every permutation. 100 is probably plenty.
- munchbunny 8y ago
  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.
xyzzyz 8y ago
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.
- xigency 8y ago
  It took me a little bit to find the explanation for this scheme: https://web.archive.org/web/20160909032102/https://smartarchitects.co.uk/news/9/15/Partial-Passwords---How.html https://web.archive.org/web/20160909032102/https://smartarch...
ajuc 8y ago
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.
- IAmLiterallyAB 8y ago
  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
  - ajuc 8y ago
    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.
    - rhinoceraptor 8y ago
      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.
pmarreck 8y ago
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!

dickeytk 8y ago

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.

gregmac 8y ago
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.
- inetknght 8y ago
  Not only that, but enumerating all possible combinations of 4 or 5 characters from a 20 character password would be untenable.
  - munk-a 8y ago
    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.
  - myhf 8y ago
    20 choose 5 = 15504. You could enumerate them all in less than a second and store all the hashes in less than a megabyte.
  - dickeytk 8y ago
    Again, not defending this I'm just being technical. You wouldn't need every permutation. 100 is probably plenty.
munchbunny 8y ago
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.

xyzzyz 8y ago

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.

xigency 8y ago
It took me a little bit to find the explanation for this scheme: https://web.archive.org/web/20160909032102/https://smartarchitects.co.uk/news/9/15/Partial-Passwords---How.html https://web.archive.org/web/20160909032102/https://smartarch...

ajuc 8y ago

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.

IAmLiterallyAB 8y ago
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
- ajuc 8y ago
  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.
  - rhinoceraptor 8y ago
    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.

pmarreck 8y ago

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!