WLAN syncing and data transfer between ios primary vault and desktop imac primary vault

1pwuser31547

Hi all,
My question is about WLAN syncing. In what direction does the syncing occur? I have identical primary vaults on my ios devices and password 7 desktop app (imac).

So if I make a change on the desktop primary vault and I choose to sync, will my ios primary vaults receive the new data (which is obviously what I want) or will my desktop primary vault sync to whatever is on my ios primary vaults, thus erasing data on my desktop primary vault?

In other words does syncing occur bidirectionally to whatever primary vault was updated last? (I know ios can't sync with another ios).
Or is the syncing one way between ios and desktop?

Any changes to a primary vault that I make are always on the desktop app due to ease of typing, etc.
So obviously, I would not want to start a WLAN sync and end up losing new data on my desktop primary vault because the desktop primary vault synced unidirectionally to whatever was on the ios primary vault.

I understand all the awesome advantages syncing to 1password cloud.
I chose to locally sync some data for personal reasons.

Is there a way to sync desktop primary vault and ios primary vault without WLAN (using folders and wired data transfer between devices)?
Also, just to confirm the WLAN syncing is also end to end encrypted, right?

Thanks!

---

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

ag_ana

Hi @1pwuser31547!

So if I make a change on the desktop primary vault and I choose to sync, will my ios primary vaults receive the new data (which is obviously what I want) or will my desktop primary vault sync to whatever is on my ios primary vaults, thus erasing data on my desktop primary vault?

In this example, your iOS device will receive the new data.

If you want to run a quick test to see if this is true, you can create a test item on your Mac, sync it to your iOS device, then edit the original test item on your Mac and see what happens if you sync again ;)

Is there a way to sync desktop primary vault and ios primary vault without WLAN (using folders and wired data transfer between devices)?

No, there isn't.

Also, just to confirm the WLAN syncing is also end to end encrypted, right?

Yes, that's correct. Here is a comparison of sync methods that you might find useful.

1pwuser31547

Hi ag_agna!
Thanks for the reply.
Sorry to ask again, I just don’t want to lose data which is what happened last time this happened a while back.

I can’t recall the exact circumstances on which device the sync was initiated but I ended up losing data because one of the device’s primary vault was empty (I think iOS) and the “updated” vaults on the iMac after syncing became empty just like the iOS. I can’t recall on which device I initiated the sync.

So to clarify the syncing can go in both directions depending on which device I initiate the sync?

In my example when I want to send new data from the iMac primary vault to my primary vaults on my iOS, while retaining the data on my iMac primary vault, on what device should I initiate the sync?

If the syncing involves “pushing” an updated COPY of the data set, then if I want to push data from the iMac primary vault to the iOS primary vault, while keeping the data on the iMac vault, the sync should be initiated on the iMac?

Please correct me if I’m wrong.

Thanks

Lars

@1pwuser31547 - without a play-by-play of what happened in exactly what order, it's going to be as difficult for us to determine (or even offer an opinion about) what might've specifically gone wrong with that WLAN sync problem you had. It sounds, from your description, as if you may have been moving items around into the trash, and then performed a sync, but there's no way to know what the real culprit might've been. Just having an empty vault and syncing it with another vault will not overwrite the filled vault with emptiness; it works the other way. In fact, it's one of the ways you can delete all data in 1Password for Mac, for example, and "re-seed" it with WLAN synced data from an iOS device: you turn off WLAN sync on both devices, reset/erase all data from 1Password for Mac, then turn WLAN sync back on...and the data will be imported from the iOS device back to the Mac. It doesn't overwrite your iOS devices with "blanks" just because 1Password for Mac has no data.

So to clarify the syncing can go in both directions depending on which device I initiate the sync?

Not really. Sync is always bi-directional; that's the meaning of sync. It's not simply one device overwriting the other. But it doesn't depend on which device you initiate the sync from.

In my example when I want to send new data from the iMac primary vault to my primary vaults on my iOS, while retaining the data on my iMac primary vault, on what device should I initiate the sync?

Either one, but it doesn't really work like that. If your WLAN system is active and functioning correctly, and you have 1Password open on both your Mac and your iOS device, sync happens automatically in such cases. You don't need to "initiate" it. You DO have to remember to have 1Password open and unlocked on both devices for that to happen...but there's no "sync now" button you need to push.

If the syncing involves “pushing” an updated COPY of the data set, then if I want to push data from the iMac primary vault to the iOS primary vault, while keeping the data on the iMac vault, the sync should be initiated on the iMac?

I'd really urge you to stop trying to think about this in terms of "pushing" or "pulling." Sync compares your data. If there is a newer copy on one device, then the other device will receive those changes...because they've been made since the last time you synced.

It's also worth mentioning here that a 1password.com membership solves many if not most of the sync issues we continue to have with WLAN sync. WLAN is our most fragile method of sync, by a longshot. That's not because it's old or broken or anything like that, but because of the nature of having to work over a variety of system states (on for one device but not on the other), individual network/wireless topologies, routers and a host of other individual software filters and the like that can interfere. You came here asking a specific question about WLAN sync, so that's what we've been trying to answer and I don't know what your ultimate goal is -- but if that goal is simply the most reliable method of sync, and the greatest data security/redundancy, then a 1password.com membership is far and away the best solution. Let us know if you have any questions.

1pwuser31547

Thanks for the clarification about syncing.

I do have a 1pw membership and do sync the vast majority of my data.
I just haven’t made the psychological leap to store my most sensitive data in the cloud. I don’t think I’m totally alone in this regard.
If you can convince me that 1pw cloud storage is actually MORE secure (not just more convenient) than storing and syncing data in primary vaults, then I’ll do it.

Best regards

Lars

@1pwuser31547 - ahhh, well that's the real $64,000 question, isn't it? I'll put it this way to begin: if we didn't believe it was, we wouldn't offer it to you as an option. I realize that's not evidence, but it should serve as evidence that we think so, after a careful review of things and even more careful setup of the 1password.com server backend.

I'm a bit reluctant to dive into a lengthy explanation in a reply here on the forum, partly because I'm not sure what your level of understanding or questions are, but also because we've already written out, in much more complete form, the security aspects of 1password.com servers/accounts. Very briefly, your data is more secure because we (1Password) never have the encryption keys to your data nor the secrets with which to derive those keys. All en/decryption takes place on your local device before anything is ever transmitted to us, meaning that we have only encrypted blobs of data which we cannot read under any circumstances. I'm guessing you probably have at least one or two "yeah, but what about" questions after reading the preceding. I would, too. :)

So what I'd recommend to help answer those would be the following article as a starting point, especially this section on sync services in general and the subsequent section on 1password.com accounts specifically (focusing on SRP and your Secret Key) specifically. The Secret Key article itself should offer you a good overview. Finally, if you want the full, nitty-gritty details of how we keep your data secure on the 1password.com servers (and in transit to/from), I'd recommend the full 1password.com security white paper (warning, math :lol: ). And if you get done with any or all of that and still aren't sure about how it works, I'm happy to answer any questions.

1pwuser31547

Thanks for the info Lars. I did read the white paper- very interesting.

Clearly the biggest risk, mathematically speaking, to one's data comes from the user, who is subject to malware, phishing and MITM attacks and who may practice poor cybersecurity hygiene, rather than from an attack on or from within the 1PW server.

So I would to clarify some "best practice" use of 1PW based on the following:

To quote:
"Despite that preservation of E2E encryption and zero knowledge authentication,
the use and availability of the web client introduces a number
of significant risks...
User mitigations include:
1. Use (code signed) native clients as much as possible...
The browser itself is a hostile environment, running processes and content that are neither under your control nor ours...

Locally exposed Secret Keys:
...Where possible, the Secret Key will be put into something provided by your system for storing authentication secrets. For 1Password for Mac and 1Password for iOS that will use the iOS and OS X keychains respectively.
But when 1Password has been used from a web browser, the Secret Key is stored in the browser’s local data store, a fairly exposed location...."

So, in order to mitigate these risks one should use the 1pw apps rather than the web client to access one's data, where possible.

However, by definition, wouldn't using browser extensions (with the native client app) to autofill entail greater (albeit small) risk than manually copying and pasting (from the app)?

Also, the data on the apps is protected only by your MP whereas data on the cloud is protected by the MP, secret key (and 2FA when enabled).
So at rest, the data appears to be more secure on the cloud than in the app but to access the data there's lower risk of succumbing to social engineering based attacks when using the native client rather than the web client.

Is this a correct analysis?

Other than practicing individual good security , is there no further way beyond the MP to secure the app against unauthorized access?
(For example, do you foresee 2FA as option for the mac OS app in the future?)

Thanks

Ben

Hi @1pwuser31547

So, in order to mitigate these risks one should use the 1pw apps rather than the web client to access one's data, where possible.

That is a fair statement.

However, by definition, wouldn't using browser extensions (with the native client app) to autofill entail greater (albeit small) risk than manually copying and pasting (from the app)?

I don't believe the risk is much if any greater. Consider that the easiest attack vector here is to read the passwords from the web page after they are filled / pasted there. This level of access is typically a fairly low barrier to entry. The 1Password extension itself is a much more hardened target. If someone has malware on your machine it would be much easier to steal the passwords from the web pages as you access them than to try and attack 1Password.

Also, the data on the apps is protected only by your MP whereas data on the cloud is protected by the MP, secret key (and 2FA when enabled).
So at rest, the data appears to be more secure on the cloud than in the app but to access the data there's lower risk of succumbing to social engineering based attacks when using the native client rather than the web client.

That sounds about right, yes.

Other than practicing individual good security , is there no further way beyond the MP to secure the app against unauthorized access?
(For example, do you foresee 2FA as option for the mac OS app in the future?)

So, to be clear, the Mac app does support 2FA for authorizing the client to your account. This typically only needs to be done once. I doubt we'll ever require 2FA on each unlock, in part because ultimately this would be security theater. If someone has access to attack the client app on your device they would also have access to steal the encrypted data and attack it on their own device on their own time. 2FA does not strengthen the encryption. A strong Master Password is what protects you in this situation.

Ben

1pwuser31547

Thanks Lars and Ben for your responses.
One more question: is Unlock on Secure Desktop mode available (or will be available) for MacOS?
I see this mode is available for Windows.

It would help thwart keylogger malware functioning, right?

Ben

@1pwuser31547

We use the macOS equivalent called SecureInput by default. The intention is to help prevent keylogging, yes.

Ben

1pwuser31547

Thanks!

Ben

You are very welcome. :)

Ben

1pwuser31547

Ben,

Not being in the cybersecurity field, I’m trying to learn as much as possible about the security measures at 1PW.

Given the previous conversations regarding security of native vs web based client, I would like your opinion and comments on the study by Independent security Evaluators that was published in February of this year.

If 1 PW has already commented on this, please direct me to that forum/document.

They were highly critical of ALL the major password managers in the way data is stored on native clients.

Here's the link: https://www.securityevaluators.com/casestudies/password-manager-hacking/

Thanks.

Specifically:

After assessing the legacy 1Password4, we moved on to 1Password7 (Windows ), the current release. Surprisingly, we found that it is less secure in the running state compared to 1Password4. 1Password7 decrypted all individual passwords in our test database as soon as it is unlocked and caches them in memory, unlike 1Password4 which kept only one entry at a time in memory. Compounding this, we found that 1Password7 scrubs neither the individual passwords, the master password, nor the secret key (an extra field introduced in 1Password6 that combines with the master password to derive the encryption key) from memory when transitioning from unlocked to locked. This renders the “lock” button ineffective; from the security standpoint, after unlocking and using 1Password7, the user must exit the software entirely in order to clear sensitive information from memory as locking should.

It appears 1Password may have rewritten their software to produce 1Password7 without implementing secure memory management and secrets scrubbing workflows present in 1Password4 and abandoning the distinction between a ‘running unlocked’ and ‘running locked’ state in terms of secrets exposure. Interestingly, this is not the case. Prior marketing material for 1Password claimed to feature Intel SGX technology. This technology protects secrets inside secure memory enclaves so that other processes and even higher privileged components (such as the kernel) cannot access them. Were SGX to be implemented correctly, 1Password7 would have been the most secure password manager in our research by far. Unfortunately, SGX was only supported as a beta feature in 1Password6 and early versions of 1Password7, and was dropped for later versions. This was only evident from gathering the details about it on a 1Password support forum.

"Conclusion:

"All password managers we examined sufficiently secured user secrets while in a ‘not running’ state. That is, if a password database were to be extracted from disk and if a strong master password was used, then brute forcing of a password manager would be computationally prohibitive.

Each password manager also attempted to scrub secrets from memory. But residual buffers remained that contained secrets, most likely due to memory leaks, lost memory references, or complex GUI frameworks which do not expose internal memory management mechanisms to sanitize secrets.

This was most evident in 1Password7 where secrets, including the master password and its associated secret key, were present in both a locked and unlocked state. This is in contrast to 1Password4, where at most, a single entry is exposed in a ‘running unlocked’ state and the master password exists in memory in an obfuscated form, but is easily recoverable. If 1Password4 scrubbed the master password memory region upon successful unlocking, it would comply with all proposed security guarantees we outlined earlier.

This paper is not meant to criticize specific password manager implementations; however, it is to establish a reasonable minimum baseline which all password managers should comply with. It is evident that attempts are made to scrub and sensitive memory in all password managers.

However, each password manager (targeting the Windows 10 platform: 1Password 7 , 1Password 4 , Dashlane , KeePass , and LastPass) fails in implementing proper secrets sanitization for various reasons. "

AGAlumB

@1pwuser31547: Indeed, that was a hot topic back in February, and it's an important topic. External security evaluations are something we commission ourselves and cooperate with when independent parties take it upon themselves as well since that makes 1Password a better, safer product. That paper has brought renewed attention to the challenge of memory management: how we do not manage our own memory, and why not. The most important thing to note is that the issue described in the report is only a threat to a computer that is already compromised. If your computer is not compromised, you aren't affected. You can read more details in our knowledgeable article on the subject though:

Managing 1Password secrets in memory

If you have any questions not addressed there, don't hesitate to reach out via email at support@1password.com so our security team can answer them. Thanks for caring, and for your interest in 1Password in the first place. :)

1pwuser31547

Yes, I read the 13 pages of the thread. It was very interesting and frankly, terrifying.
I read your reiteration of the recommendations laid out by the ISE paper:

Keeping the OS updated
Enabling or utilizing well known and tested anti-virus solutions
Utilizing features provided by some password managers, such as “Secure Desktop”
Using hardware wallets for immediately exploitable sensitive data such as crypto currency private keys
Utilizing the auto lock feature of their OS to prevent ‘walk by’ targeted malicious activity
Selecting a strong password as the master password to thwart brute force possibilities on a compromised encrypted database file
Using full disk encryption to prevent the possibility of secrets extraction in the event of crash logs and associated memory dumps which may include decrypted password manager data
Shutting a password manager down completely when not in use even in a locked state (If using one that doesn’t properly sanitize secrets upon being placed into a locked running state)
And certainly restarting the device will clear memory if you want to be sure, since otherwise it's up to the OS to reallocate as needed.

Unfortunately, anti-malware software may not pick up such viruses that mimic normal behavior such as "diagnostic app that tries to grab memory dump in user space" (to quote another in the forum).

At the present time given this vulnerability with memory management, along with these above recommendations would you also recommend using 1 password X, at least until a remedy is found to this memory management problem?

I know, in general that using a web client vs native client presents different risks but as you've said in that thread, the hostile nature in web environments has 'hardened" web extensions, especially this "thick" type extension which historically has had vulnerabilities (Last Pass).

Also, I suppose one could disable core dumps in Mac OS?

littlebobbytables

Greetings @1pwuser31547,

It isn't that we want to dissuade having this conversation but as it gets more technical many of us may run the risk of offering incorrect information even with the best of intentions. That's the main reason Brenty suggested emailing in so that somebody from the security team could respond and ensure the answers are correct. Security can often be like complex mathematics, insanely difficult, not intuitive and takes a lot of effort to master well.

The original paper focussed only on Windows and my understanding is much of it does not apply to 1Password for Mac. The security team will be much better placed though to discuss this if you're concerned. I don't see 1Password X as being more secure than 1Password for Mac though. You are correct that browsers have to put some effort given the hostile nature of the web at large but an extension is still written in JavaScript and subject to all the limitations that imposes. I, like everybody at 1Password, use 1Password not just for work but for everything and from the work perspective I'm sure you can imagine our vaults contain some pretty sensitive data given everything developers need to build and run the client and service. I'm not concerned about running 1Password for Mac as I know I'm much safer with it than without.

1pwuser31547

OK

littlebobbytables

Thank you for your understanding, if you do write in I hope we're able to ease any concerns you have :smile:

ulbn

I am a fairly new user ("rookie"?) of 1Pw7...and now I have a basic question for the community and/or expert teams:

I (am a retired 72 yrs old Swede) and I mostly work my 3 Apple units - MacBookPro, 1 iPad mini 5, iPhone 8 plus a 4th unit, a stationary PC with Windows 10, the latter fairly seldom used but also armed with 1Password7 and thus "linked" to the above Apple units.

I also am very cautious surfing on the net with the PC...(only very well trusted webpages, and with log-in use of 1Pw7)

On the W10 PC, where 1Pw7 was installed some 6 months ago (and is working fine) i presently have no third party anti-virus software -

I deleted the old anti-virus program approx. 2 months ago when I switched from ADSL internet to Mobile(wireless) Broadband all over my 4 units (a cost-based decision).

The way I am now set-up, am I much more vulnerable now WITHOUT third party anti-virus software on the PC??
I am not very skilled technically, so I am curious and (and also little worried...)

I would appreciate an answer and recommendation from neutral parties (e.g. a Norton or other sales representatives would probably be very anxious to sell me their anti-virus software)

/B

DanielP

@ulbn:

Like you, I also have a Windows 10 PC here which does not get a ton of usage. On that computer, I use the built-in Windows Defender only, without a third-party antivirus, and for my usage this configuration is enough. I cannot say what the best option for you would be, but I can tell you that Windows Defender is a capable antivirus, and that you can avoid a lot of risks just by using common sense and secure browsing habits.

A third-party antivirus will not protect you if you don't follow basic security hygiene. It is just a piece of the puzzle, like everything else.

Make sure that Windows Defender is enabled though!

===
Daniel
1Password Security Team

ulbn

Thanks a lot, Daniel!
That is very reassuring to read, and “using common sense and secure browsing habits” as you wrote, is quite natural for me.
Have a nice day!
/B

ag_ana

On behalf of Daniel, you are welcome @ulbn! If you have any other questions, please feel free to reach out anytime.

Have a wonderful day :)

ulbn

Yes...I do have another slight "problem" - and I will come back on that...
But first I have to create a few screenshots to illusate what I mean..So, any day now!
Meanwhile have a good week-end!
/B

ag_ana

@ulbn:

Please feel free to open a new discussion here in the forum anytime you are ready :)

You have a good weekend too!