1Password 7 for Windows: Installation to %ProgramFiles(x86)%

Dear 1Password team,

I've upgraded my Mac and Windows licenses to version 7 and I'm surprised that 1Password 7 for Windows, contrary to its predecessors, doesn't install to the Windows default path for 32 bit applications %ProgramFiles(x86)%. There does not even seem to be a way to get asked by the installer where I want to install 1Password, it apparently chooses %APPDATA% or something without any option to override that choice.

Could you please tell me how I get the installer to install to %ProgramFiles(x86)%, as one would expect it from a Windows-compliant application?

Thank you very much.


1Password Version: 7.2.576
Extension Version: Not Provided
OS Version: Windows 7 Ultimate SP1 x64
Sync Type: Nextcloud

Comments

  • @HackintoshHD: Actually, 1Password 7 purposefully installs in your user folder and we don't support installing it elsewhere. On reason being that multiple Windows users may use this same PC and 1Password will be configured differently for each. Isolating the app to your user folder makes it easy to have multiple configurations per user. 1Password isn't alone here. My own AppData folder has folders for everything from 1Password to Adobe to some of my browsers. By tradition, you'r totally right – programs go in Program Files – but that's becoming less true, even on Windows. :chuffed:

  • HackintoshHD
    HackintoshHD
    Community Member

    @HackintoshHD: Actually, 1Password 7 purposefully installs in your user folder and we don't support installing it elsewhere.

    Thank you, @bundtkate, for your answer. I actually did understand AgileBits' motif behind installing to %LOCALAPPDATA% (correction to my initial post: It's actually %LOCAL_APPDATA%, not %APPDATA%, which would be _…/Roaming). I just think - no offense intended - it's an ill-advised design decision and a step backwards for 1Password on Windows as far as security is concerned.

    As far as I can see, AgileBits' decision to install to %LOCALAPPDATA% without choice kills all security concepts of working under a non-administrative user, as %LOCALAPPDATA% / %APPDATA% are not under the protection of the Windows User Account Control (UAC) with all the consequences from that (1Password binaries can be replaced, tampered etc. pp. without a UAC dialog ever getting displayed to the user as long as the resulting binary is signed by a Microsoft-issued developer certificate).

    Please feel free to correct me, if I'm wrong.

    To reproduce:

    1. Scenario A ('as supported by AgileBits'): Normally install 1Password 7 for Windows (it'll install to %LOCALAPPDATA%\1password\app\7) and quit the 1Password.exe *32 process e.g. from the 1Password tray icon.
    2. Open the %LOCALAPPDATA%\1password\app\7\1Password.exe binary in any editor you like - even notepad.exe does the job - alter it and save. You will not be warned by a UAC dialog.

    3. Scenario B ('Windows-compliant, not supported by AgileBits'): Install 1Password 7 for Windows to e.g. %ProgramFiles(x86)%\AgileBits\1Password by simply using the corresponding command line switches for the Inno Setup installer:

      1PasswordSetup-7.2.576.exe /DIR=%ProgramFiles(x86)%\AgileBits\1Password

    4. Open the %ProgramFiles(x86)%\AgileBits\1Password\1Password.exe binary in any editor you like - even notepad.exe does the job - alter it and try to save. You will be warned by a Windows UAC dialog.

    By tradition, you'r totally right – programs go in Program Files – but that's becoming less true, even on Windows. :chuffed:

    Well, the last time I checked it was not really 'tradition', but Microsoft's very own certification requirements for Windows 10 Desktop Apps that make an installation to %ProgramFiles(x86)% mandatory for reasons of consistency and security (Paragraph 10.1):

    " 10.1 Your app must be installed in the Program Files folder by default

    For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder. "

    Again, please correct me if I'm wrong, but in its current state, 1Password 7 for Windows would not be certifiable as a Windows 10 app, would it?

    On reason being that multiple Windows users may use this same PC and 1Password will be configured differently for each. Isolating the app to your user folder makes it easy to have multiple configurations per user.

    ... which is achievable to no less an extend if one chooses the Windows-compliant way - separating program files in %ProgramFiles(x86)% from user data in %APPDATA% or %LOCALAPPDATA%.

    1Password isn't alone here. My own AppData folder has folders for everything from 1Password to Adobe to some of my browsers.

    Okay, but seriously - again, no offense intended -, should the negligence of others like Adobe really be the Leitmotiv for 1Password's design decisions?

    I'd honestly felt weird to learn that the company behind my Password Manager considers something like the Adobe Flash Player (!) as the reference for security.

  • HackintoshHD
    HackintoshHD
    Community Member

    @HackintoshHD: Actually, 1Password 7 purposefully installs in your user folder and we don't support installing it elsewhere.

    Thank you, @bundtkate, for your answer. I actually did understand AgileBits' motif behind installing to %LOCALAPPDATA% (correction to my initial post: It's actually %LOCALAPPDATA%, not %APPDATA%, which would be …/Roaming). I just think - no offense intended - it's an ill-advised design decision and a step backwards for 1Password on Windows as far as security is concerned.

    As far as I can see, AgileBits' decision to install to %LOCALAPPDATA% without choice kills all security concepts of working under a non-administrative user, as %LOCALAPPDATA% / %APPDATA% are not under the protection of the Windows User Account Control (UAC) with all the consequences from that (1Password binaries can be replaced, tampered etc. pp. without a UAC dialog ever getting displayed to the user as long as the resulting binary is signed by a Microsoft-issued developer certificate).

    Please feel free to correct me, if I'm wrong.

    To reproduce:

    1. Scenario A ('as supported by AgileBits'): Normally install 1Password 7 for Windows (it'll install to %LOCALAPPDATA%\1password\app\7) and quit the 1Password.exe *32 process e.g. from the 1Password tray icon.
    2. Open the %LOCALAPPDATA%\1password\app\7\1Password.exe binary in any editor you like - even notepad.exe does the job - alter it and save. You will not be warned by a UAC dialog.

    3. Scenario B ('Windows-compliant, not supported by AgileBits'): Install 1Password 7 for Windows to e.g. %ProgramFiles(x86)%\AgileBits\1Password by simply using the corresponding command line (cmd.exe executed as administrator) switches for the Inno Setup installer:

      1PasswordSetup-7.2.576.exe /DIR="%ProgramFiles(x86)%\AgileBits\1Password"

    4. Open the %ProgramFiles(x86)%\AgileBits\1Password\1Password.exe binary in any editor you like - even notepad.exe does the job - alter it and try to save. You will be warned by a Windows UAC dialog.

    By tradition, you'r totally right – programs go in Program Files – but that's becoming less true, even on Windows. :chuffed:

    Well, the last time I checked it was not really 'tradition', but Microsoft's very own certification requirements for Windows 10 Desktop Apps that make an installation to %ProgramFiles(x86)% mandatory for reasons of consistency and security (Paragraph 10.1):

    " 10.1 Your app must be installed in the Program Files folder by default

    For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder. "

    Again, please correct me if I'm wrong, but in its current state, 1Password 7 for Windows would not be certifiable as a Windows 10 app, would it?

    On reason being that multiple Windows users may use this same PC and 1Password will be configured differently for each. Isolating the app to your user folder makes it easy to have multiple configurations per user.

    ... which is achievable to no less an extend if one chooses the Windows-compliant way - separating program files in %ProgramFiles(x86)% from user data in %APPDATA% or %LOCALAPPDATA%.

    1Password isn't alone here. My own AppData folder has folders for everything from 1Password to Adobe to some of my browsers.

    Okay, but seriously - again, no offense intended -, should the negligence of others like Adobe really be the Leitmotiv for 1Password's design decisions?

    I'd honestly felt weird to learn that the company behind my Password Manager considers something like the Adobe Flash Player (!) as the reference for security.

  • AGAlumB
    AGAlumB
    1Password Alumni

    @HackintoshHD: This doesn't have any impact on security, as 1Password is installable without admin rights, and, in fact, we recommend not installing it with admin rights.

  • HackintoshHD
    HackintoshHD
    Community Member

    I'm afraid we're writing past one another, @brenty.

    The point I'm trying to draw the support team's attention to is that the design decisision to install the 1Password binaries to %LOCALAPPDATA% sacrifices the Windows User Access Control (UAC) protection they would normally have in the Windows default program files folder %ProgramFiles(x86)%.

    In other words: Any process run under your user space, also accidentally executed malware, can now replace or tamper 1Password's binaries without you even noticing. Because you simply won't get a UAC warning dialog in that case.

    Sure you may argue that 1Password's binaries are protected against manipulation by their developer's signature. But that covers only the second case of tampering your binaries and still leaves room for replacing them, as long as the replacement has any valid signature (so it's not necessary that it's yours!). And that's IMHO far from being only a theoretical threat.

  • AGAlumB
    AGAlumB
    1Password Alumni
    edited September 2018

    @HackintoshHD: Thanks for clarifying. You are correct: 1Password is digitally signed. Installing to the user folder also ensures that it cannot be modified by other user accounts, which is good not only for security but also reliability. And not requiring admin rights to install and update is a long-standing feature request -- probably the most requested, until we released the new app that works that way. You're not wrong that malware could modify it, but that goes for anything running with full access. 1Password being installed in Program Files isn't going to save you from malware, and comes with some actual downsides for users. More important is not running an outdated/unpatched/modified OS, and practicing good security hygiene so you don't have malware in the first place. Otherwise, all bets are off. I don't think it's helpful to pretend otherwise.

  • HackintoshHD
    HackintoshHD
    Community Member

    You're not wrong that malware could modify it, but that goes for anything running with full access. 1Password being installed in Program Files isn't going to save you from malware

    I'm sorry, but that statement is still inaccurate and misleading. It's evident if you compare these two scenarios:

    Situation A: A malware executed under your user's context with normal privileges can't modify or replace 1Password's binaries unnoticedly when they're installed to %ProgramFiles(x86)%. Instead you'll get a UAC prompt warning you that an elevation of privileges is needed due to %ProgramFiles(x86)% ACLs. The UAC prompt will either ask you for permission (if your user has admin privileges) or for invocation of another user account with admin privileges (if your current logon user doesn't have them). Bottom line: You are being warned by a UAC prompt and you can decide whether or nor you want to grant the requesting application the permission to write to %ProgramFiles(x86)%.

    Situation B (current practice of 1Password 7): A malware executed under your user's context can modify or replace 1Password's binaries installed to %LOCALAPPDATA%\1password\app\7 without you noticing. You will not see a UAC prompt and you can't decide whether or not you want to give your permission.

    More important is not running an outdated/unpatched/modified OS, and practicing good security hygiene so you don't have malware in the first place. Otherwise, all bets are off.

    Well, 'not running an outdated/unpatched/modified OS' is probably more important than everything security-wise, so that's a knockout argument against probably any reasonable effort to make an application more secure and is IMHO distracting. Fact remains AgileBits have created an unnecessary attack vector against 1Password 7 users here.

    I might be more relaxed about the problem if 1Password 7's installer at least had given me the choice to optionally install to Windows' default %ProgramFiles(x86)%. But no - the installer GUI doesn't allow it, the support team tells me they're 'not supporting it' and fails to mention the installer's command line switches, which ends in me literally having to dissect the installer to find out it's fairly easy to achieve. Not ideal.

    AgileBits would really do well to allow an installation to the Windows default location %ProgramFiles(x86)% again.

  • AGAlumB
    AGAlumB
    1Password Alumni

    I'm sorry, but that statement is still inaccurate and misleading.

    @HackintoshHD: No. What's "inaccurate and misleading" is that you're suggesting that 1Password could somehow be responsible for malware you install on your machine. I'm in complete agreement with you that malware can do bad things, and that UAC can help protect against certain threats. But you're just sailing right past this reality: If you install malware on your machine that has the ability to modify any files, you're in trouble regardless of where 1Password is installed.

    To reiterate, you have a completely valid point: UAC can alert you if some something tries to modify files. However, when you install malware on your system, all bets really are off. From Microsoft (emphasis mine):

    "Notify me only when programs/apps try to make changes to my computer - this is the default level, and UAC notifies you only before programs make changes that require administrative permissions. If you manually make changes to Windows, then a UAC prompt is not shown. This level is less annoying as it doesn't stop the user from making changes to the system, it only shows prompts if an app or file wants to make changes. When a UAC prompt is shown, the desktop is dimmed, and you must choose Yes or No before you can do anything else on your computer. Security impact: this is less secure than the first setting because malicious programs can be created to simulate the keystrokes or mouse movements made by a user and change Windows settings. However, if you are using a good security solution, such situations should not occur.

    This is malware 101. And the default setting, which almost everyone will be using, is still not going to be able to defend against any but the most incompetent attackers.

    Fact remains AgileBits have created an unnecessary attack vector against 1Password 7 users here.

    Nope. You do by installing malware on your machine. And I'm sorry to say that we can't stop you from doing that, and neither can any "security" software you use, unless it locks things down so you cannot install anything. So maybe that's a good case for Windows 10 S.

    To summarize, these are the threats you face by installing malware on your computer, regardless of where/how 1Password is setup:

    1. Malware can simply override local user registry keys and install itself instead of 1Password as browser helper
    2. Malware can run its own copy from user's account and access 1Password memory because they are both running at the same privilege level
    3. Malware can do the same for the browser and steal secrets there
    4. Malware can — well, long story short, it can do pretty much anything you can

    The moral of the story: If your system is compromised, 1Password's installation folder is the least of your problems. Presumably you're concerned about this because you don't want malware to compromise 1Password, and thus the important data you store in it. I feel exactly the same way, but we have to be realistic. If 1Password is installed to Program Files, malware can still steal your data as you access it, without replacing/modifying the 1Password app itself. It's actually even much less work than creating an impostor app to fool users, and it can be done silently: no UAC, no UI, just collect data in the background.

    AgileBits would really do well to allow an installation to the Windows default location %ProgramFiles(x86)% again.

    It's something we're continually evaluating as we developed 1Password, so it's helpful to know that this is something you'd want.

    I'm sorry to disagree with you on many levels regarding this topic, but it's important that we avoid security theater and not promote installing 1Password to another location as somehow making people immune to malware attacks, since that isn't the case. There are certainly other reasons that some folks may want to install it somewhere else though, and perhaps that's something we can offer in the future. Thanks for your passionate feedback on this interesting topic. :)

This discussion has been closed.