Unlocking needed multiple times
I'm running 1Password 4.2.0.548. When I unlock 1Password via the taskbar icon and then open the interface by clicking on the icon I have to unlock it again though the tray icon already shows the unlocked icon. When unlocked via taskbar I can use 1password in my browser but cannot directly open the application.
Is this a configurable option? Maybe it's a bug? If not I would like this to be configurable, I don't like to enter my password multiple times.
Comments
-
@admxnl - We have a great knowledge base entry that explains why there is sometimes excessive data locking -
If the main 1Password program is not running, unlocking the 1Password extension in your web browser will unlock the helper but not launch the main program; subsequently launching the main 1Password program will require you to unlock it, too. If you do those two things in a row, it will mean entering your master password twice: once in the browser extension to unlock it, and once to unlock the main program.
0 -
Why is this method more secure? I can't imagine unlocking via browser would be less secure then unlocking via the main program. I guess if i'm the only user with physical access to my computer it should matter too.
0 -
@admxnl don't bother. I'm had this argument in great detail many times over. It basically comes down to a philosophical argument between the app components pushing the master key to each other or allowing it to pulled.
At present when you unlock a component (the main app or the browser helper) it takes your master password and uses it to decrypt the master key. It then attempts to push that key (or the MP derived key, I'm not sure) to the other component. This means that if the other component is not running then it can't receive the key.
If you then start the other component then it does not have the key and so needs to be unlocked. It could send a request the already running component to request its copy of the key but Agilebits sees this as a risk because any app could request the key.
There's two fundamental flaws to this line of thinking:
1) They already do code signature validation on the process that they push the key to. There is no reason that this validation could not be done on a process requesting your key also.
2) If you're worried about the security of the code signature check then pushing and pulling is no different in security terms. You can easily compromise the push method by killing any existing 1Password.exe/Agile1pAgent.exe and then running a fake exe in its place. When the user unlocks the other component it will push the key to the fake component you've just run. The only blocker is the code signature verification. Allowing a pull request simply means that you accept requests only from a process whose module is in your install path and passes the code signature check and so, once again you are relying on the integrity of the signature check.
Agilebits deny it, but I suspect that this situation is simply nothing more than a frozen accident; a detail of implementation that they don't want to address.
ok, that post was longer than I intended. :)
0 -
Hi @admxnl,
Why is this method more secure? I can't imagine unlocking via browser would be less secure then unlocking via the main program. I guess if i'm the only user with physical access to my computer it should matter too.
It is not about what's more secure but rather the control of the secure information passing between two separate 1Password processes. We have one process that is responsible for helping the extension fill in with your encrypted data (1Password Helper) and the other one is the main application itself. We actually have a few more processes but for this discussion, it's just these two main ones.
We want to be overaggressive with ensuring that your master password does not exist longer than needed anywhere on your computer, which includes your computer memory. We do this by removing your master password as soon as we don't need it. That does mean when you unlock the extension and the main program is not running, we can't use that password anymore to unlock the main program.
0 -
We want to be overaggressive with ensuring that your master password does not exist longer than needed anywhere on your computer, which includes your computer memory. We do this by removing your master password as soon as we don't need it. That does mean when you unlock the extension and the main program is not running, we can't use that password anymore to unlock the main program.
Sure, but you can easily transfer the master key between the processes instead. When both components are running and you unlock one either the master password, the derived key or the master key must be transmitted across the OTP encrypted connection. I really don't see the difference between doing it when the user unlocks or when the other component is fired up.
0 -
We want to be overaggressive with ensuring that your master password does not exist longer than needed anywhere on your computer, which includes your computer memory. We do this by removing your master password as soon as we don't need it. That does mean when you unlock the extension and the main program is not running, we can't use that password anymore to unlock the main program.
Why can't you unlock the main program in 1 go?
We have one process that is responsible for helping the extension fill in with your encrypted data (1Password Helper) and the other one is the main application itself. We actually have a few more processes...
I guess all 1password process can communicate with each other in a secure manner. That would be first priority for a password management program. If sending master password between process is such a problem why not only let the main program do the unlocking?
It is not about what's more secure but rather the control of the secure information passing between two separate 1Password processes.
As mentioned above sending the master password from 1 process to another wouldn't be such a security risk.
You mention the master password is kept in memory shortly and send between process. As far as I know this would only be a security risk if my computer is compromised. If so, a trojan or other malware could also easily intercept my keyboard entry thus capture my master password.
So again my question, what is the purpose of asking for the master password twice on my own machine, I don't see the relation to extra security?
0 -
Hi @admxnl,
Why can't you unlock the main program in 1 go?
Because the main program is not running, there's nothing to send it to.
Note if you have Universal unlock turned on, unlocking the main application will also unlock the extension when you open it. Make sure you have this enabled; open the main 1Password application, unlock, go to the File Menu > Preferences > Browsers and check Universal Unlock. You'll find the information here: https://guides.agilebits.com/1password-windows/4/en/topic/browsers-tab
I guess all 1password process can communicate with each other in a secure manner. That would be first priority for a password management program. If sending master password between process is such a problem why not only let the main program do the unlocking?
We do, via the Universal Unlock feature but it is limited in how much it can do. You can find out more information in our guide here: https://guides.agilebits.com/1password-windows/4/en/topic/browsers-tab, scroll down to the Universal unlock section.
0 -
A couple of notes.
When you unlock the helper via the tray icon and the app is not running, then we launch the app for you to unlock. Because the app then unlocks the helper, both are unlocked.
There is one scenario (and one scenario only) where the helper does not unlock the app. This is when (a) the app has not been started before, and (b) you unlock the helper via the web browser. In this scenario, you might need to unlock the app. This is an edge case that I'm not loosing sleep over.
0
