Traveling--how to login while on the road

RichardPayne

I guess I should add I don't know is 1PasswordAnyWhere a program that is separate or something you turn on inside 1P.

@svondutch's link doesn't really cover what 1PasswordAnywhere actually is. It is a small software application written purely in Javascript. This means that it can execute fully inside a browser, unlike the main 1Password program and extensions which mostly execute in native code.

The problem is that because the code is stored, unencrypted, in the vault it is vulnerable to being modified in a way that the native program binaries installed on your PC are not. When you load the 1Password.html file into a browser you are loading code that whose trustworthiness is entirely determined by the security of your dropbox account. If someone has gained access to it then they can modified the code in 1Password.html to do anything they like, including sending your master password to a remote server to be logged.

Note that it is only the unencrypted data that is at risk of modification and it is only the code that presents a security risk. That risk is only present if you allow the javascript code to execute, and as @svondutch‌ noted, only then when you enter your master password. Someone can hack 1Password.html all they like, but if you only ever access your vault through the 1Password installed applications then there is no risk.

jpgoldberg

At the risk of repeating what others have said, I would like to sum up a few points that have caused some confusion.

To put it more directly, the existence of 1PasswordAnywhere does not pose any risk. It is only when you choose to use it that the issues raised here become a concern.

1PasswordAnywhere isn't something you enable or not. If you are using Dropbox with the Agile Keychain format, it is available to you.

1PasswordAnywhere is a "web based system" and so is susceptible to threats that apply to such systems. The rest of 1Password is not a web based system, and so attacks on web-based systems are not relevant to 1Password as a whole.

raahh

Thanks for clarifying Richard and jpgoldberg.

Just so I'm clear, would you say it would be more secure to install 1Password locally on a device (e.g. netbook running Windows or iOS) as oppose to accessing 1PasswordAnywhere via Dropbox on a browser using an Android tablet?

also, are there any other ways I can protect myself when using 1PasswordAnywhere via Dropbox? (e.g. launching Chrome in incognito mode, using VPN software etc)

RichardPayne

Just so I'm clear, would you say it would be more secure to install 1Password locally on a device (e.g. netbook running Windows or iOS) as oppose to accessing 1PasswordAnywhere via Dropbox on a browser using an Android tablet?

Absolutely. As @jpgoldberg‌ said, the native code apps don't have the same vulnerabilities that script code running in a browser does.

also, are there any other ways I can protect myself when using 1PasswordAnywhere via Dropbox? (e.g. launching Chrome in incognito mode, using VPN software etc)

Not really. Incognito just prevents Chrome from writing client side logs and temporary data. As the warning that Chrome displays clearly states, it does not prevent tracking or logging on the server side. Think more "prevent snooping house mates" than "prevent cyber criminals".

VPN software might help if you were using a private cloud to host your vault, but even then it's only as good as the rest of your security setup.
It really doesn't matter how secure your access to your vault is. The risk is from someone else gaining access to it and modifying it. A secure download channel would just result in your securely downloading malicious code in that case.

The only sensible thing I can think of is to create a new vault in order to get a nice new, clean, copy of 1Password.html. Then rename this and tuck it away somewhere obscure in your dropbox. Then, when you need to use 1Password Anywhere, simply copy in your saved clean file and overwrite the html file in the vault.

Obviously, this isn't a perfect solution since it assumes that a hacker won't look at the renamed clean file and realise what it is. If they do then you're back to square one. The only hope here is that they'll see the obvious honey pot of the vault itself and not think to look for other copies of the html.

Overall though, I really wouldn't bother. Just use the apps.

[Deleted User]

@Peter_Pappas‌

PS To use the other format do I need to start from scratch, maybe using copy and paste?

Correct, switching formats is a manual process. You have to create a completely new vault and choose opvault in the dropdown menu. Then paste or import your data from the agilekeychain in some way. When I switched to opvault I exported the agilekeychain as a .1pif file, then imported that file to the newly created opvault. This was not without errors, for example some Router items (but not all) lost their password info.

I think you should wait until Agilebits create some official method to convert to the new format.

svondutch

I think you should wait until AgileBits...

@Xe997 is right. Officially, opvault is still unsupported.