Secret Key, Obfuscation, and Hmmmm

I get the purpose of the secret key, the additional entropy it adds as a sort of master key prefix or two part key.
What irks me, is, as near as I can figure, it only really serves to secure the database when it is centralized (your cloud, someone else's cloud, etc). If the secret key is in a browser cookie and only obfuscated, or buried in a native app, then that endpoint at least has part of the overall key (no, nsa is not after me, just thinking out loud).

So, why not use the master key to encrypt the secret key in the browser and the app? (the cookie ones really makes me scratch my head).

I'm sure I'm way off somewhere, which is why I came by for some clarity.

Thanks!

===
btw, trialing the app right now and the reviewers don't do it justice. Not that any of them get into the technical guts of it either. Its why I have lastpass to start but really started disliking it. The updated Elcom blog brought me this way. But you do need some more consistency across platforms (um, oh, about that security audit either in the web or the windows client... would be nice. Everyone else has got it).

And while we are at it, i get 2fA has nothing to do with encryption. But it would be a huge authorization and authentication peace of mind at the office.


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Windows
Sync Type: 1password

Comments

  • This effectively would mean you have a single factor, your master password, locally that protects the locally encrypted vault - but the truth is you really only have this anyway as the secret key is stored locally and potentially discoverable. At least if the local secret key is encrypted in some form locally with either an AB key built into the app or your master password then it would appear to be less accessible.

    If your master password was used to encrypt you local secret key would this provide an easier way to brute force your master password as you could use the known output format of the secret key to confirm when the correct master password had been guessed when the local secret key was calculated? Would an AB private key in the app, which is then used to decrypt the local security key, be better as there is no direct link to your master password? Or is this just as weak / possibly discoverable in the app itself - and even if it is, does it provide at least some security of the local secret key over the current simple obfuscation method?

    From my understanding AB's argument is that they don't really have to protect it locally as they consider that if your machine was compromised enough that the local security key was captured then it is game over anyway. I think if you can protect it you should as it is another hurdle, as long as it does not compromise security elsewhere.

    2FE - 2 factor encryption - Split keys (secret key + master password).
    2FA - 2 factor authentication - something you know (mental) and something you have (physical).

    With regards to 2FA I think it is important to have a second factor to authenticate when you are accessing 1password via the web or the application wants to download/sync with the web. I understand that accessing the local vault is all about encryption if you want to retain the ability to access it offline and you would have to sacrifice the offline ability if you enforced an online 2FA mechanism.
    I also understand that 2FE adds more to real world security than 2FA does but I still think both should be available and both have their purpose. From my understanding AB's argument is that your secret key is a 2nd factor - you know your master password but not your secret key (so that is something you have) but for me true 2nd factor is an every changing value not a static one YubiKey / U2F / Authenticator VS Secret Key. That way if it is captured it is either one time (yubikey/U2F) or limited to 30 seconds (authenticator). My problem with using secret key as 2nd factor authentication is that it is a static value so is really just another piece of something you know, which is not true 2FA.

  • JacobJacob

    AgileBits Team Member

    Hi @AlwaysSortaCurious! Thanks for asking about this. It looks like fryrpc's post above covers everything I was going to say. I spoke with the security team to confirm as well. Encrypting the Secret Key with your Master Password would indeed provide an easier way for someone to derive the Master Password from that encrypted Secret Key using brute force. The explanation on two-factor encryption and two-factor authentication is also accurate.

    I encourage you to read the security white paper for 1Password.com since it discusses things in detail. If you have some other questions about things, feel free to let us know.

  • Hmmm.. posted a reply last night, but it hasn't shown. Let me try again...

    Ok. Thanks @fryrpc and @Jacob

    So really the AB password is really for centralized database encryption.. there's no real extra help at the client endpoint and that's okay (the nsa can always beat it out of me if tbey want my creds to this forum

  • edited September 12

    hmmm... only three sentences? let me post the rest (weird)

    Please keep in mind that wasn't complaining I was just thinking out loud.

    If cracking the secret key gives up my password ( my idea above) and that makes sense then all they need to do is crack my local database since from a trusted device or browser, they have that part (the key). Seems to be the same difference. I'm okay with the extra level of security in the cloud with AB because you guys are the real Target. Not me as a solo act. I should have a strong master key anyway...

    That said I will say that 2fa argument is weak. Lol. That's strictly authentication authorization to the app or site. It allows me to leave my secret key on a work pc, but prevents your average keyloggin corp. snoops from getting in. I agree with @fryrpc its static.

    Just scanned the doc you referenced, and looks like i was right mostly. The secret key is really there to add extra layers to the server copy of the DB. Depending on the platform it could be better protected but not all platforms are equal.

  • AGKyleAGKyle AgileSupport

    AgileBits Team Member

    Hi @AlwaysSortaCurious

    Not sure if there's a question about the whole Secret Key / encrypted with master password part there. If there is I'm afraid I'm not seeing it so I can't answer. Sometimes discussion around this stuff is hard though so my apologies if I'm missing something more obvious here. I'd love to make sure you have all the answers you need however.

    The Secret Key is definitely more motivated in the case of protecting data stored on our server, and notably protecting against users who may (inadvertently perhaps) use a weak Master Password. Making our server a less interesting target is important. If an attacker knows that the data they could in theory acquire from our server is impossible to crack then it makes our server a lot less interesting to them. Not only that even if they do gather that information it's still useless. It definitely helps against the idea of our server being the target. It may not help in the case of you yourself being the target, 2FA could help alleviate some of that.

    The thing with 2FA that I think you're missing with regard to your work pc is that if someone gains access to your data from the work pc, they could copy your local database and run a password cracking tool on it locally, which would bypass requiring authentication from our server. We could in theory require every sync to authenticate with 2FA, as that's going to have to contact the server, but as long as we maintain a local cache of the data on the computer, then there's a way around the 2FA since there's a copy of that data locally on the device. If that data can be captured from the local device, then authentication is no longer necessary.

    2FA works best for websites because every access requires contacting the server, so it's incredibly easy for 2FA to work into the sign in process. But for an app like ours, where the data is both on our server and local (because offline use is important), it complicates things a lot. 2FA isn't involved in the encryption, just in granting access. So in our case, access can be "bypassed" by gathering the local data.

    In the case of a key logger, assuming they have

    1. Access to your computer, then they also have access to the data
    2. And access to the Secret Key
    3. And could potentially gather your Master Password (they'd have to bypass Secure Input on Mac)

    That's 2 of the 3 things they'd need, and potentially the 3rd.

    This goes back to what fryrpc said, in that our stance is that a compromised computer is not something we can really do a lot to protect against. We can delay the inevitable, but it's very difficult to stop it entirely.

    It's possible we could make 2FA not cache the data. This could in theory prevent that type of situation as well and I believe it is something we have discussed as part of implementation of a theoretical 2FA solution.

    I hope that gives some insight, but security is a complex thing with a lot of layers.

  • LastPass have the option of trusting a device and allowing it to have an offline copy of the vault.
    That way some of your devices running the software can have a local vault and some can not and have to get it from the server with 2FA - dependent on whether you trust the device or not.
    You also have an option to disable offline access completely at an account level thus enforcing 2FA every time and accepting that you will have no access if the server is down, so you have to make sure to use the pocket.exe app to create a local encrypted export every now and again and use the same app to open it if needed.
    I am not endorsing LastPass as I am a defector, but was a loyal customer of theirs for quite a number of years. It is just interesting to see how others have tried to tackle the problem ;-)

  • AGKyleAGKyle AgileSupport

    AgileBits Team Member

    Thanks @fryrpc

    Always good to see how others tackle things, as it gives some insight into what people might expect from a similar feature.

  • @AGKyle No question. Just musing out loud. I'm with @fryrpc on this, I was going to post the below in https://discussions.agilebits.com/discussion/60687/ but thought not to (new here and didn't want to seem like I was trolling), but I will take the draft and add it here since it now seems appropriate.

    Why I think 2FA is so desirable? And I haven't browsed extensively through the forums, but some, and often people speak of hacking the vault. Let's put that aside as impractical, the effort that will take more than your lifetime to accomplish if you have a decent master password, not to mention the secret key and are not the target of a state actor or the Russian or Ukrainian mob.

    Most hackers that concern me nowadays are going to social us, phish us, trojan us. They are NOT going to go after the DB directly. They want our creds. 2FA prevents them from gaining authorized access to the app and DB after pick pocketing my creds or owning my desktop.

    If they pull up my name from our stupid 'here is the guy you want to get and his extension and easy to guess email' directory, and I have a bad day and click the wrong junk mail. Pow!

    2FA would nullify that effort. They would not likely have the 2FA shared secret since my device and your server were not the original targets.

    No? (secret key as a static 2fa parameter sounds just wrong. and if valid, digital 2FA improves the convenience)

    I read https://discussions.agilebits.com/discussion/comment/364163/#Comment_364163

    The attacker use case above would NOT have the 2FA shared secret. This is strictly a case of A&A.

    DUO as an example (from the blog)--So even DUO for apps and the web site serves a purpose (though I have seen DUO go down, we use it too). For the "offline mode" part the blog, I got no good answer LOL. But yeah, some would be willing to suffer or it could be implemented on an app/device specific basis (like having Google Authenticator on my phone with a 2FA password manager is kind of silly, right? So no need for me to 2FA it)

  • BenBen AWS Team

    AgileBits Team Member

    I would argue that 2FA does not protect you if your computer is "owned." The attacker may not be able to get at your data via a replay attack but they'll simply steal it as you access it instead (e.x. as it is entered into web forms).

    There are certainly attacks that 2FA does protect against, and we aren't arguing that it doesn't have a place. It just isn't the solution to all the problems that many folks think it is.

    What we want to avoid is:

    1) Providing a false sense of security
    2) Adding technical complexity unnecessarily

    Ben

  • I agree there are no full solutions, just ayers of improvements. I see it as another layer in the Improvement cycle I still like the product, and will use it, but without 2FA. I'm not sure how many Enterprises would be willing to embrace the tech. Right or wrong I know my security guys would never allow it as an Enterprise solution.

  • Currently 2FA is available as a Beta option in 1Password Teams - it uses DUO for 2FA

    Obviously being a Beta feature does not guarantee it will make it out of the Beta phase into the Production environment for either 1Password Teams or any of the other 1Password account types. Fingers crossed.

    I think AB want to test 2FA to ensure it is a good fit for 1Password and does not compromise security. I think DUO is a good interesting option as it puts the owness of 2FA device recovery with DUO so does not involve AB in the process. Something like TOTP authenticator would require a lot more hands on from AB if a user lost a device and needed to bypass 2FA. I personally like U2F with a backup of YubiKey, TOTP or DUO.

  • brentybrenty

    AgileBits Team Member

    @fryrpc: Pretty much, though there are other considerations as well. Thanks for letting us know your preferences! :)

    @AlwaysSortaCurious: Ultimately two-factor authentication does not protect against brute force attacks, and these are ultimately what we need to defend against. Regardless of authentication methods, we've always designed 1Password to protect your data even if the vault is captured. At that point, authentication (if any) has already been bypassed, and we all want 1Password to withstand attack even in this next-to-worst-case scenario (following the one Ben mentioned above). So long as you're using a long, strong, unique Master Password, that will protect your data even if you are using two-factor authentication that has been bypassed (for example, the device is already trusted).

    You're right that this is something that is on a checklist for many businesses though, which is why we've introduced Duo authentication as a beta feature in the 1Password Teams Pro plan. It is paramount for 1Password.com to be fundamentally secure without these additional measures, but as we continue to develop the service we may add additional options like this as well — especially with the feedback of folks in the beta and others like you. Cheers! :)

Sign In or Register to comment.