Keyboard Shortcut to switch Vaults

Hi there,

It would be good if the same as in OSX you can switch Vaults using something like CTRL + 1. The same as CMD + 1 in OS X. For both in 1P and 1Pm

Thanks,

Brendan

Comments

  • DBrown
    DBrown
    1Password Alumni

    Thanks for the suggestion, Brendan!

    We're always looking for ways to improve 1Password, so it's good to know what would be useful to you.

  • svondutch
    svondutch
    1Password Alumni

    It would be good if the same as in OSX you can switch Vaults using something like CTRL + 1.

    @BThompson I have added this to version 4.1.0.BETA-540

  • bkh
    bkh
    Community Member

    @svondutch, thanks for this useful feature. Here's a feature request: implement the Ctrl + n vault switching feature in the secure desktop unlock screen.

  • svondutch
    svondutch
    1Password Alumni

    Here's a feature request: implement the Ctrl + n vault switching feature in the secure desktop unlock screen.

    For security reasons, the secure desktop unlock process does not know anything about your other vaults.

  • bkh
    bkh
    Community Member

    For security reasons, the secure desktop unlock process does not know anything about your other vaults.

    Please explain the security issue. If the secure desktop is receiving a file path to unlock, it could just as well receive a vector of 9 with a default selection that the user could override via Ctrl + n; how is that a security issue? On the other hand, if the secure desktop is merely returning an entered master password, it could also return a number from 1 to 9 or 0 for no change.

  • svondutch
    svondutch
    1Password Alumni

    Please explain the security issue.

    Principle of least privilege.

    If the secure desktop is receiving a file path to unlock

    It is not receiving a fully qualified path. It is receiving the least amount of information for doing it's job; giving you a secure desktop where you can enter your master password.

  • RichardPayne
    RichardPayne
    Community Member

    @svondutch I don't understand the concern in this case. The list of a fully qualified paths is openly accessible from the main window when the vault is locked. Why would making them available to the secure desktop be any sort of security risk?

    I have added this to version 4.1.0.BETA-540

    I've just had a look at this functionality and it really doesn't sit well with the way 1Password for Windows handles multiple vaults. The entries in the vault list are constantly switching positions in the list. Ctrl+1 is therefore entirely pointless as it is always the current vault. The shortcut to use for the others depends entirely on the order that you last used them. I would suggest removing the code that re-orders the list.

  • svondutch
    svondutch
    1Password Alumni

    The entries in the vault list are constantly switching positions in the list. Ctrl+1 is therefore entirely pointless as it is always the current vault. The shortcut to use for the others depends entirely on the order that you last used them.

    On Mac, Cmd+1 is primary vault and Cmd+2 is secondary vault.

    On Windows, there is no such thing as primary vault and secondary vault. Ctrl+1 is the vault you have currently open. Ctrl+2 is the vault you had open before that. Ctrl+3 is the vault you had open before #2.

    If you only have 2 vaults, then Ctrl+2 allows you to toggle between them.

  • RichardPayne
    RichardPayne
    Community Member

    I can see the value of that scheme with you're only using two vaults (although Ctrl+1 is still redundant), but if you have more than that then I doubt many people will be able to mentally keep track of the order that they had previously used vaults.

  • bkh
    bkh
    Community Member
    edited February 2015

    Principle of least privilege.

    A good principle. However, I note that the principle of least privilege gives no support to any kind of "security by obscurity" argument.

    It is not receiving a fully qualified path. It is receiving the least amount of information for doing it's job; giving you a secure desktop where you can enter your master password.

    I know that the vault pathnames and their filesystem contents are not secrets in the 1Password security model. I supposed that the secure desktop was to guard the user entry of the master password (and perhaps some crypto computation on that password) from observation by hostile processes. Here's where I start to wonder whether your invocation of the principle of least privilege is not security, merely theatre. Some kind of data comes to the secure desktop and some result goes back. Do you assert that making these data a vector of 9, all of the original type, plus a selector somehow risks the loss of 1 or more bits of complexity in your cryptographically secure system? Or it leaks otherwise cryptographically-protected secrets about multiple vaults, so that compromise of one vault potentially cascades into compromise of all vaults?

    If you can spare the time, please reconsider whether adding the Ctrl+n selector to the secure desktop would actually create a new security exposure, and if not, then I ask that this item be added to the feature request list.

  • DBrown
    DBrown
    1Password Alumni

    Thanks for the suggestion, @bkh.

  • bkh
    bkh
    Community Member
    edited February 2015

    @svondutch, I've thought about this further, and maybe taking a vault-switch command through the secure desktop doesn't need to violate your principle of least privilege.

    Here's the prerequisite: I'm supposing that the secure desktop merely receives a typed password from the user, performs a cryptographically-strong hash on it, and returns the result. If I'm wrong about that, then the rest of this message is trash so ignore it. But if I'm basically right about how that works, then maybe a not-too-difficult tweak can implement the vault switch from the secure desktop, as follows.

    The idea is this. Let the secure desktop receive input character at a time rather than line at a time, and let it receive control characters not just printable characters. If the first character is Ctrl+n, immediately return the hash of that. At the other end, it will be caught as an incorrect password, but before putting up the error popup ("1Password has encountered a problem. Unable to unlock xyz vault ") first check if the (incorrect) hash matches the hash of Ctrl+[0..9], and if so, invoke the currently-existing vault switch action, which will pop right back to the secure desktop for the password entry.

    If this flow seems feasible and no less secure than the result of a user entering a wrong password, please add this enhancement to the feature request list. Thanks.

  • RichardPayne
    RichardPayne
    Community Member

    The trouble I can see with that is that providing sensible user feedback is going to be very awkward. Did the user enter the password wrong or did they Ctrl select the wrong vault?

    If you're just executing the normal switch vault function then when it fails and you select Retry, you're know retrying on the secure with a different set of shortcut assignments.

  • bkh
    bkh
    Community Member

    @RichardPayne, are you re-raising your observation that they currently permute the assignment of numbers to vault names, which makes switching a bit awkward, or is there more? I don't see a new, additional point of confusion. I note that the secure desktop does show the name of the vault it is working on.

    The current flow that I use to switch vaults (from a locked state) is this. I click on the locked padlock in the notification area, they immediately put up the secure desktop, I click cancel, they show the main app screen, I type Ctrl+2, they immediately put up the secure desktop (with the new vault name showing), I enter the password, hit return, and they unlock. With the new flow I'm suggesting, I wouldn't click cancel on the first secure desktop, instead I'd type Ctrl+2. That would immediately bounce out to the main window which would immediately come back to the secure desktop with the new vault showing, without requiring that any of the vault-switch data and logic be present in the secure desktop's context.

    Does this proposed flow make sense? I don't see that it introduces a plausible new source of user confusion. There continues to be the current possible failure mode: type the wrong n in Ctrl+n, then have to cancel out and go through the menus to find the right vault. But I don't see a new failure. In particular, I can't see them mistakenly typing Ctrl+n as the first character of their vault password and thereby getting the wrong vault switched in when they were just misspelling the password. And with the flow I suggest if they type the wrong password for the indicated vault, this (with cryptographically strong probability) will not hash to Ctrl+n causing an inadvertent vault switch rather than the "1Password has encountered a problem. Unable to unlock" popup.

  • RichardPayne
    RichardPayne
    Community Member

    @bkh no, I meant that it's even worse with the secure desktop. When using the normal unlock you can at least see which vault is active after you've hit the Ctrl+# shortcut. With the method you outlined for the secure desktop you'd have no way of knowing if you'd selected the correct vault without dropping back to the main app window, which sort of defeats the point.

    Your idea would have some merit if the Ctrl numbers were static as you'd just learn them. The rotating numbers with a blind selection method just seem like a recipe for frustration to me.

  • bkh
    bkh
    Community Member
    edited February 2015

    @RichardPayne, I disagree. With the method I outlined you would also see if you have selected the correct vault. After typing Ctrl+n, with no additional keystrokes or clicks the secure desktop would exit and then reappear with the new vault selected, and the secure desktop does indeed show the name of the vault that it is unlocking. "Your vaultname vault is locked" appears on the line above the blank password entry field.

  • RichardPayne
    RichardPayne
    Community Member

    Ah I see. That's less bad I suppose.

This discussion has been closed.