3 ms·

Don't most users just stick with the default though? The shipped password manager going from one with a master password to one without would just mean most user

by mcintyre1994 9y ago

Don't most users just stick with the default though? The shipped password manager going from one with a master password to one without would just mean most users have less security.

zaarn 9y ago
Most users don't use the master password at all so most users will have the same security. Users with master password will have to be informed they need to find a new solution.
- baby 9y ago
  I'm not sure I see the point here, what is the threat model? I guess it does not include laptop protected by full disk encryption?
  - zaarn 9y ago
    The threatmodel of the masterpassword is usually a variation of "attacker on your local system".
    - yjftsjthsd-h 9y ago
      ...who can keylog your master password? It still makes the attack harder, I grant, but not that much harder.
      - zaarn 9y ago
        A keylogger on your system could keylog your master password. A password manager itself has a similar threatmodel but it holds (usually) more valuable information than just passwords (in my case TOTP, Bank Data, Credit Card, etc.) PM's are also usually better equipped to deal with this (Keepass uses a Secure Desktop on Windows) Firefox's master password is "good enough", so to speak. It's unlikely someone will attack you either way but if someone does then FF's system should hold out a day or two if you picked a reasonable password (a modern PM can put up much better brute force defence)
      - s_gourichon 9y ago
        Good point. Nowadays, keylogging the master password is AFAIK easier for an attacker than tracing processes. This is still current: https://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html https://blog.invisiblethings.org/2011/04/23/linux-security-c...
        zaarn 9y ago
        I wish Linux would implement a modern Secure Attention Mode (it has one but that kills all processes). It could be as simple as having a syscall that connects a process directly with the keyboard and does not let any other process intercept any keyboard input until the program lets go or times out (180s, after that the program isn't allowed to get SAM anymore for another 180s)
        yjftsjthsd-h 9y ago
        I feel that kernel-level handling would get messy. Just to name one thing that comes to mind: how would you handle multi-seat systems? Oh, or accessibility; say, there is no physical keyboard, just a touchscreen and onscsreen keyboard that you've just blocked from displaying. Yes, you could handle it, but by the time you've hit a few of these the code will be... inelegant.
        zaarn 9y ago
        I've actually thought about this for a bit and it's not as complicated. If a physical keyboard is present, the program is assigned to the keyboard of the current user's seat (works with sudo since that only sets effective UID/GID not real UID/GID) Additionally, a program with root privileges (or a special CAP) can register itself as a HID in which case the SAM captures any HID's + keyboards of the current seat. Any complex setup would therefore be pushed out of the kernel but still provide reasonable security. An additional edgecase can be seen in debuggers which can be reasonably circumvented by having the SAM mode provide a few pages of memory that aren't mapped into any memory but the current process so a debugger can't read the password. A software keylogger would require strict root privileges to circumvent this system.

Don't most users just stick with the default though? The shipped password manager going from one with a master password to one without would just mean most users have less security.

zaarn 9y ago

Most users don't use the master password at all so most users will have the same security. Users with master password will have to be informed they need to find a new solution.

baby 9y ago
I'm not sure I see the point here, what is the threat model? I guess it does not include laptop protected by full disk encryption?
- zaarn 9y ago
  The threatmodel of the masterpassword is usually a variation of "attacker on your local system".
  - yjftsjthsd-h 9y ago
    ...who can keylog your master password? It still makes the attack harder, I grant, but not that much harder.
    - zaarn 9y ago
      A keylogger on your system could keylog your master password. A password manager itself has a similar threatmodel but it holds (usually) more valuable information than just passwords (in my case TOTP, Bank Data, Credit Card, etc.) PM's are also usually better equipped to deal with this (Keepass uses a Secure Desktop on Windows) Firefox's master password is "good enough", so to speak. It's unlikely someone will attack you either way but if someone does then FF's system should hold out a day or two if you picked a reasonable password (a modern PM can put up much better brute force defence)
    - s_gourichon 9y ago
      Good point. Nowadays, keylogging the master password is AFAIK easier for an attacker than tracing processes. This is still current: https://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html https://blog.invisiblethings.org/2011/04/23/linux-security-c...
      - zaarn 9y ago
        I wish Linux would implement a modern Secure Attention Mode (it has one but that kills all processes). It could be as simple as having a syscall that connects a process directly with the keyboard and does not let any other process intercept any keyboard input until the program lets go or times out (180s, after that the program isn't allowed to get SAM anymore for another 180s)
        yjftsjthsd-h 9y ago
        I feel that kernel-level handling would get messy. Just to name one thing that comes to mind: how would you handle multi-seat systems? Oh, or accessibility; say, there is no physical keyboard, just a touchscreen and onscsreen keyboard that you've just blocked from displaying. Yes, you could handle it, but by the time you've hit a few of these the code will be... inelegant.
        zaarn 9y ago
        I've actually thought about this for a bit and it's not as complicated. If a physical keyboard is present, the program is assigned to the keyboard of the current user's seat (works with sudo since that only sets effective UID/GID not real UID/GID) Additionally, a program with root privileges (or a special CAP) can register itself as a HID in which case the SAM captures any HID's + keyboards of the current seat. Any complex setup would therefore be pushed out of the kernel but still provide reasonable security. An additional edgecase can be seen in debuggers which can be reasonably circumvented by having the SAM mode provide a few pages of memory that aren't mapped into any memory but the current process so a debugger can't read the password. A software keylogger would require strict root privileges to circumvent this system.