Like 1Password 4 for iOS, but the quick password isn't enough.

benguild

This is my one thing so far. When I need a password quickly, I used to like having the 4 digit PIN and also the shorter, local "mobile" password that was in the old version.



I realize this might be a hurdle from an architectural perspective, but for me the App is getting closed out before I can actually benefit from the quick password. Can't we have two quick passwords between getting the actual data? And of course, delete the data locally if 10 bad guesses or something.

jhollington

Do you have [i]Auto-Lock[/i] set to something other than "Never"? This will cause 1Password to return to prompting for the Master Password after the Auto-Lock timeout expires. The 1Password app actually does a pretty good job of staying resident unless you're switching around between a lot of other apps with large memory footprints.



The best way to maximize use of the Quick Unlock Code is to set [i]Auto-Lock [/i]to "Never" and enable [i]Lock on Exit[/i]. For me this works quite well, and I very rarely have to enter the full Master Password when returning to 1Password.

Paco II

Seems like setting Auto-Lock to 'never' would be a major reduction in security. All that's left is a 4 digit pin for full access.

jhollington

In theory, that's true in some ways, but it's always a tradeoff. The 1Password 3.x method also had its own potentially serious security issues, not the least of which was that when using Dropbox for sync, the [i]actual[/i] Master Password was stored in the iOS keychain. That's not the easiest place to get at it, but was definitely less secure in theory than 1Password itself, and could be dug out relatively easily for users who had jailbroken their iOS devices.



With 1Password 4, the data is encrypted by the [i]actual[/i] Master Password, which is not stored anywhere on the device at all. The Quick Unlock Code only applies if the app is open, and you only get [u][i]one[/i][/u] attempt at it before the [i]actual [/i]Master Password is required instead, so brute-forcing is not an option here.

CurbedEnthusiasm

I made a post on another thread about this also. I think Agile have taken a step backwards with this change. There's no way I want to be entering my 40+ character MP into an iPad. Sure, there's the quick access code, but that then unlocks everything - a weaker security model than 1P3's mobile MP and code. Unfortunately, I won't upgrade with this change in place so hoping you supporting 1P3 for a lonnnnnng time <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />

benguild

It seems like the Quick Code is perhaps a more secure option, but what I'm wondering is if this leaves the device vulnerable to cracking if the actual unlock code can be pulled from memory.



If the process is killed or the device is shut off, it seems to lock then. But, what are the consequences of adopting this strategy? I like that entering the code incorrectly triggers a full lock, though.

jhollington

If you're jailbroken, all bets are off, but I think in a standard Apple configuration that's pretty unlikely and would require an app that takes advantage of an existing vulnerability/exploit in iOS. Application memory is normally "sandboxed" and apps don't get any access to things that other apps are doing -- everything is essentially partitioned from each other.



Further, I'm not an Agile developer, just another end user, but based on what I know of how 1Password works, I don't believe the actual Master Password is stored in RAM -- merely the decryption key derived from the Master Password. Further, I expect that like the Mac version, the entire data store isn't left unencrypted in RAM, but is decrypted on-the-fly by the 1Password app, using the derived key, on an as-needed basis.