4 ms·

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

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

ajuc 8y ago
> 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.
- dpark 8y ago
  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.
  - ajuc 8y ago
    Why? Now all the universal keyloggers don't work (because they remember which keys were pressed, but not which positions they refer to).
    - munk-a 8y ago
      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.
      - ajuc 8y ago
        Sms codes are used anyway, to authorize transfers and changes in the account.
    - ljm 8y ago
      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.
      - ajuc 8y ago
        > 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.
- vkou 8y ago
  > 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.
  - dTal 8y ago
    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.
    - vkou 8y ago
      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.
- inetknght 8y ago
  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.

ajuc 8y ago

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

dpark 8y ago
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.
- ajuc 8y ago
  Why? Now all the universal keyloggers don't work (because they remember which keys were pressed, but not which positions they refer to).
  - munk-a 8y ago
    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.
    - ajuc 8y ago
      Sms codes are used anyway, to authorize transfers and changes in the account.
  - ljm 8y ago
    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.
    - ajuc 8y ago
      > 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.
vkou 8y ago
> 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.
- dTal 8y ago
  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.
  - vkou 8y ago
    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.
inetknght 8y ago
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.