On WLAN Sync in 1Password 7

Those of you who have relied on Wireless LAN synching for 1Password data will have noticed that this is not supported in 1Password 7. There are lots of reasons for this, which I will break down into three.

It's hard to use

It's a nightmare to support

It does not provide the kinds of security that people may imagine it does

My first draft of this topped 3000 words. You will be pleased to know that I did some editing.

Let us know

It's hard to use

With (most) other synching mechanisms for 1Password data, you set it up once on each device and then can entirely forget about it. You don't have to worry about which device you made what changes to when.

You have to think about which devices may not have synchronized. If you've made changes on multiple mobile devices you need to do manually sync and resync to get everything propagated.

This may be a price you are willing to pay, but that doesn't take away from the fact that it really is harder.

It's a nightmare to support

Almost everyone reading this right now is aware of multiple choices and has some idea of where the data can live. And that's great.

But most others have set up 1Password once and no longer know how they set up synching. They only knew which they picked when and shortly after they set things up. When they go to set up a new device they don't know how they are already synching. Despite our efforts at setup guidance, even if 1% of people set up a new device incorrectly, that is still tens of thousands of people. The large majority of support queries are to resolve sync problems, and the overwhelming majority of sync problems are the result of multiple ways to sync.

Let me make this clear that none of this is the user's fault. People shouldn't have to know about sync mechanisms to be able to use 1Password well.

WLAN adds to that general problem by being yet another sync method, but it is also easier to mess up, and there are the networking issues. A typical household will just have one local subnet (so-called guest networks notwithstanding). But there are a lot of atypical ones.

When people notice synching problems we can't ask them to describe their local network topology and expect reliable answers. Again, this is not the user's fault. People shouldn't have to know about network topology to use 1Password.

Security of WLAN versus 1Password accounts

Your data is end-to-end encrypted. That means that it is encrypted with keys that are derived from secrets that only you hold before your data ever hits a disk, much less a network. If that encryption were not good enough for "the cloud" than it wouldn't be good enough on your own devices.

Encrypted data can be stolen from "somebody else's computer", and it can be stolen from your own. What I'm going to ask you to consider is whether WLAN actually offers you more relevant security or whether it just offers you a greater sense of security.

First let me talk about the security advantages WLAN sync.

Our system is a juicier target than your system.

We are continually under attack. (They are kind of amusing to watch and only very rarely require any manual intervention on our part. But we do keep an eye on them.)

We get some scraps of metadata. We can know when you connect to the service, where you connect from and how much data you have.

If you keep your data entirely within your own network, then nobody has that information.

Our Privacy by Design means that can't know the websites you have logins for, we can't know the titles you've given to items or vaults. We can't know the names of tags that you use.

But still, we do get a little bit more information about you than we do if you only sync on your own network. (If you use Dropbox, then they or anyone who compromises them have that data.)

Lockout. What power do we have to lock you out of your own data?

We never want to lock people out of their own data. We do not even want to have the capability of locking people out of their own data.

With some effort, you can make sure that you always have a backups of your own data locally. It's not as robust and automatic as it should be, but we are working at improve this.

You may need to keep things to local networks for compliance reasons.

You may work in an environment in which you simply are not allowed to store data, no matter how well encrypted, outside of your own organizations system. This is the most compelling reason to use WLAN sync. I believe that in this case your organization's rules and policies may be misguided, but my opinion doesn't change the requirements placed upon you.

We will continue to explore ways to make 1Password work for you. But I can't offer any promises about what the nature of that resolution may be. Folder Sync remains an option between some systems, but it does not cover everything.

Now let's look at the security advantages of our service.

Two-Secret Key Derivation (2SKD). 1Password data stolen from your own machine or network is protected only by your Master Password. Data stolen from our systems is protected by both your Master Password and a your 128 bit Secret Key.

It is hard to over-state the importance of this. When we designed the service, we designed things knowing that we would be a juicy target. And there are limits to how much things like PBKDF2 can do for you. Our concern was that if someone stole your data from us they would be able to launch password cracking attempts against your Master Password.

So client side a Secret Key is combined with your Master Password during key derivation. The Secret Key is stored on your device, but is never sent to us. Without the Secret Key, there is simply no way that anyone could attempt a Master Password cracking attempt on data from our services. (And if they were to get the secret key from your machines, then they would also have your local copy of encrypted data as well, and wouldn't need anything from our systems.)

No secrets transmitted during authentication

When your client connects to our server and authenticates, no secrets are transmitted. We cannot learn anything about your Master Password and Secret Key during that process. It's really cool, and we've published the source code that is used for this.

Does not depend on the secrecy of TLS/SSL

We do use TLS, and we do so very strictly. But we do not depend on it. In addition to your data always being encrypted with keys derived from your Master Password and Secret Key, our own communication protocol encrypts and authenticates messages with a session key that is negotiated during authentication. And finally, all of that is done over TLS. So that gives you three layers of encryption during transport.

Data format improvement.

Just as OPVault has important security improvements over its predecessor, Agile Keychain Format; what we use with our service is an improvement over OPVault.

Our systems are better protected than yours.

You have been using WLAN sync, so you are a sophisticated user who knows how to protect your systems. But in addition the obvious resource advantages we have in protecting the systems on which your data reside (our ops team, virtual private clouds, full database encryption, monitoring, etc), there is an even bigger difference:

The only thing that ever happens on each of our systems is the very narrow purpose of that component. Our database systems only run the database for example. Your systems, on the other hand, are used for web browsing, for email, for Twitter, for document preparation, for watching videos, and playing games. This is a deep and fundamental difference that makes our systems inherently easier to secure.

So while it remains true that our systems are a more attractive target, we have designed things so that we even if we are compromised, your secrets remain safe. Our security is layered, relies on end-to-end encryption, maintains privacy by design, and focuses on real defenses instead of theatrical ones. We want you to have as much control over your own data as possible, while still making things work for you.

[This forum thread originally appeared in the 1Password for Windows Beta forum, but has been moved to non-beta forum as the release of 1Password for Windows 7 approaches].

I believe since it's already implemented in the macOS version of 1Password, it's not going to go away. 1Password 6/7 for Windows is a clean (new) codebase, so it would have to be built completely to support WLAN sync.

I agree, I sometime want to use WLAN sync for specific vaults but I also dealt with a lot of WLAN sync issues that is just magically gone as soon as I use Folder Sync + 1Password.com together. I can't have Folder Sync on my iOS devices but you can use Folder Sync on Android devices. Here's hoping that Apple will evolve Files and add more extension points for it to allow 1Password on iOS to use it to sync standalone vaults with.

I never had any WLAN Sync issues. Is it convenient? No. Is it for everyone? No. Is it for me? 100% yes.

I've read through all the text you wrote and appreciate the effort, but here's the thing: Your cloud doesn't provide the kind of privacy that you may image it does. As a freelancer I sign a lot of NDAs and I'm simply not allowed to upload credentials to 3rd parties. I even turn off iCloud backup for 1P on my phone because of this.

This is the most compelling reason to use WLAN sync.
I believe that in this case your organization's rules and policies may be misguided

Sure, maybe. But that's an irrelevant statement. Many people do work at places with strict rules. You wouldn't believe what's not allowed at big companies if you're used to work at startups.

WLAN sync is secure enough for many cases but most importantly it solves legal/privacy restriction that you cannot fulfil otherwise.

I got an analogy for you: Imagine that Excel can only access files stored on OneDrive. How does that feel?

Really, I would think folder sync with a network folder share would create the same effect. Heck, most sec departments might appreciate the ability to use share-based permissions to further refine who has access to the folder via ldap or ad and just feel better about the whole thing. For the home user, it would depend on whether they found folders easier or wlan easier, but it would seem to me that folder sync with a folder share gets most of those Corp exactly what they want (mapped drive at logon through Corp wired or secure wireless network). And the home user gets something they can easily visualize and is familiar.

What kind of sense does local vaults in 1PW7 have, if sync is only possible via 1PW Account and Dropbox? Sorry, but I think to fulfill the requirements to use 1PW local there is a need to sync 1PW locally e.g. WLAN or local NAS e.g. via WebDAV, SFTP....

Glad to hear. I've never had any WLAN sync issues (knock on wood) and not a Windows users, so I'm all smiles

@ohreally: That's great to hear! Certainly some users have their network environment under control, and don't experience bugs or "features" of their hardware and software that end up interfering. But if that were the case for everyone, and all of that was easy for the average user to setup — from device to router and everything in between — we'd probably all be living in a different world as far as syncing data.

And I agree, maybe Apple will give us something to cheer about at WWDC

Here's hoping! Improvements in file management would help a lot of people who want to use iOS devices for even more advanced tasks.

I never had any WLAN Sync issues. Is it convenient? No. Is it for everyone? No. Is it for me? 100% yes.

@frame: We appreciate knowing that. This is something we'll continue to evaluate.

I've read through all the text you wrote and appreciate the effort, but here's the thing: Your cloud doesn't provide the kind of privacy that you may image it does. As a freelancer I sign a lot of NDAs and I'm simply not allowed to upload credentials to 3rd parties. I even turn off iCloud backup for 1P on my phone because of this. This is the most compelling reason to use WLAN sync.

There's a big difference: Apple has encryption keys for user data in some cases; we don't.

I believe that in this case your organization's rules and policies may be misguided

Sure, maybe. But that's an irrelevant statement.

You left out the last half of that sentence:

I believe that in this case your organization's rules and policies may be misguided, but my opinion doesn't change the requirements placed upon you.

We recognize that it may be irrelevant to you, but that doesn't change the fact that it is very relevant to the vast majority of 1Password users, and, by extension, to us here at AgileBits. We have to carefully consider what we work on, based on what can do the most good for the greatest number of people. I know that doesn't help you in this case, but in others you're the beneficiary of that. We'll continue to evaluate if there are things we can do to help with niche use cases that can benefit more people — like perhaps enhancements to folder sync.

I got an analogy for you: Imagine that Excel can only access files stored on OneDrive. How does that feel?

I really don't think that's apt. It would be if we ran our own cloud storage service and required all 1Password user to use that for not only 1Password for general cloud data storage, but that's not the case.

Many people do work at places with strict rules. You wouldn't believe what's not allowed at big companies if you're used to work at startups.

Actually we're painfully aware of these things, as we work with companies like that ourselves and have to do a lot of compliance and sign agreements. Fortunately for all involved, many have been modernizing — paperwork not withstanding.

WLAN sync is secure enough for many cases but most importantly it solves legal/privacy restriction that you cannot fulfil otherwise.

I think you hit the nail on the head; this is less about security (since you can get the same or better security with other methods) than it is about following rules. Thank you for taking the time to share your thoughts on this!

What kind of sense does local vaults in 1PW7 have, if sync is only possible via 1PW Account and Dropbox?

@Finke03: Many people prefer use local vaults and sync the data themselves (or not at all) and not pay for a subscription — for example, someone who only uses 1Password on a single device, or just a few, who doesn't need licenses for all platforms and is comfortable managing things themselves.

Sorry, but I think to fulfill the requirements to use 1PW local there is a need to sync 1PW locally e.g. WLAN or local NAS e.g. via WebDAV, SFTP....

1Password already supports the local folder option, which you could use with a network drive (but be sure to backup your data in case it goes offline and something gets damaged). So you can already do that. This discussion is only about us developing our own WLAN Server sync option in expressly for the new app.

That‘s right. But the possibility’s to sync with an iOS device are limited to cloud services like 1PW Account and Dropbox, or?

@Finke03: I'm not entirely sure what you're asking here, but to clarify this has nothing to do with 1Password: iOS has no ability to work with data sync'd to arbitrary folders the way other platforms do.

Ok, but this will not work with the iOS App as MikeT mentioned in another thread, right?

Right. That will work on macOS, Windows, and Android.

So it’s not a solution for most of the users.

Indeed, folder sync is an advanced option and is unsuitable for most people.

Due of that my final statement is: WiFi sync is still required.

Similarly, WLAN Server is an advanced option and is unsuitable for most people.

I've been the family champion for diversifying passwords and using a password keeper. For some (not all) family members, I've prevailed.

For one family member, who uses Windows and an iPhone, she's ready to use a password keeper, but not ready for her password data to leave her house. (FWIW, neither am I, and I am not a novice in this area.)

I use the Mac and iOS versions of your app and I'm very happy using a WLAN server to sync my Mac and iOS vaults; never had a problem.

Imagine my thrill for my cousin when I saw your announcement today. I sent her a text right away to let her know her wait for a system that worked well, something she could use between her desktop and iPhone without her data leaving her house, was coming to an end.

But maybe I was too quick: based on what I'm reading above, I have to ask, will there be any way for her to sync the passwords on her two devices without her password data having to go out of her house?

I like how Jeff focused on the security aspect of WLAN Sync vs. 1Password memberships in his post here, and had I waited I would have stole most of this for my post. But I was impatient and wrote my own essay in my reply to Paule on the announcement post.

In my reply there you'll see my perspective on why WLAN Sync couldn't make it into 1Password 7, as well as a special WLAN Sync newsletter for those who need this option to sign up to. This is important as it will give us a way to track how many people actually need this feature (keep in mind that we don't include analytics of any kind within 1Password), which will come in very handy during our next planning call.

You say it was difficult to setup? I can't clearly remember the (setup)process anymore, but all I am doing now is pressing WLAN sync, entering my password, done. Is this what you consider to be difficult?

EDIT: Cutting of features is sometimes necessary, yes. But you decided to hand us a solution with the standalone license after we were (more or less) begging for you to do so (and the well expected shitstorm). Now you cut off the only way (to my knowledge) to sync to my phone without using a third party, aka dropbox... I have read the comment replies and the statement here... I don't get it, sorry.

The set up you describe will continue to work if you are doing the WLAN Sync between your Mac and iOS. And you can still use Folder Sync between Windows and Android. What is gone now is direct local synching between Windows and iOS.

What you may not realize is that WLAN synching roughly means that to do this with every combination, we would need four different sync methods.

WLAN Windows/Android

WLAN Windows/iOS

WLAN Mac/Android

WLAN Mac/iOS

This is a bit of an overstatement, but it does correctly reflect the nature of the task in maintaining these. To top it off, these things need to behave differently based on operating system version and Software Development Kit. We (very correctly) didn't want to tie ourselves to some of the frameworks/libraries used for 1Password for Windows 4 when developing 1Password for Windows 7. There was no reasonable way that we could have carried over the WLAN code from 1Password for Windows 4 to what we are doing with 7.

So it's not as if we said ourselves, "hey let's drop this thing from 1Password for Windows 7." Instead it was "If we try to develop WLAN sync for this new combination in time for launch, we will have to forego too many other things we want to develop for it."

Help us understand

As @dteare said, we (correctly) don't know how many people are using WLAN and what their over all configurations are. We hear from some of the people who run into trouble (but we only hear from those who contact us and we don't hear from those who simply give up.) And we hear from people like you who come to our forums and blog to tell us. So this is why I want to ask you about your choices. I want to know your reasons.

From my point of view, if someone believes that 1Password's data encryption isn't good enough to live on "somebody else's computer" then they shouldn't believe that it is good enough to live on their own devices (which get lost or stolen). So I genuinely have a hard time understanding your perspective, and that is why I am asking for your help in explaining your view to me.

It's obvious that the 1Password team has a programming/implementation challenge supporting WLAN across the different platforms; I don't envy them that. And, I get that the numbers of people who have trouble with WLAN (and call for support) are almost by definition going to dwarf those who use it (and never call).

Nonetheless, "From my point of view, if someone believes that 1Password's data encryption isn't good enough to live on 'somebody else's computer' then they shouldn't believe that it is good enough to live on their own devices (which get lost or stolen)," isn't likely to win customers AND it misses the point. Yes, it's your point of view, but you're not the customer.

So, (and to go to the not-beside-the-point stuff) I've read your security page, and there's a lot of good stuff going on there. Needless to say, for example, using SHA256 is much better than SHA1, like Firefox has been doing for the last (at least) nine years.

However, the finest minds in cryptography will tell you "encryption is hard." (And, if you think they wouldn't, and if you don't know it yourselves, then there's another issue.)

You've got a bug bounty program, which is better than a lot of companies can say; this is good. There are two explanations (which are not mutually exclusive): it's for marketing and/or you recognize that no system is perfect and there may be a bug in your implementation, which is worth at least $100,000 (mid-market) to pay for. Still a good thing, but (probably) an acknowledgement that vulnerabilities (even outside your control) can exist.

Does AgileBits write all its own code from scratch? Probably not, but even if you did, it may not be the better thing. Many/most open-source libraries are vetted and reliable, and--given the scale of the code required--better than doing everything one's self. But the downside--a supply chain compromise--is the same one discovered by Avast's Piriform in CCleaner last year.

And, then there's the dependence on Amazon Web Services. No two customers use it just the same way, but it's not perfect.

But all that is beside-the-point stuff.

Let's go back to one of the original points: you counter "Our system is a juicier target than your system" with "Our systems are better protected than yours." That's pretty cold comfort to many people and a pretty low bar. Anonymous folks like my cousin (rightly) prefer to take their chances with quality software like 1Password KEPT AND SYNC'D locally, rather than sync'd over systems they have no control over (when Agile Bits is a "juicier target" than my cousin and others are).

I am unaware of a profitable company that is prepared to promise the value of its existence to each of its customers, in case of a compromise for which the customer is not responsible. If Agile Bits is prepared to do so, I'll wholeheartedly recommend 1Password, synced via your systems, to my cousin. That's a challenging bar for any company, and it's the reason that US law doesn't hold company executives responsible (a priori) for breaches like Equifax's (which is a whole other story). If it did, odds are we either would have great cyber security or we'd have crappy CEOs.

Right now, 1Password is the best there is, I'm persuaded of that. But, the absence of a local sync option (for reasonable programming resources issues, if nothing else) is leaving folks who would otherwise practice good computer hygiene to put their "cash under their mattresses." (And, even banks get robbed, with guns or code. Maybe 1Password should help folks at least put their cash in a safe in their anonymous basement?)

Your customers (or potential customers) who don't trust all the security layers involved actually ARE quite rational. "Rational" isn't binary. They may not know the details of CCleaner, Firefox, AWS, or Equifax, but they know enough.

Please do keep seeking a count of folks who use WLAN, I hope we all respond. Given everything that can be done to our systems when we just use a single password for all our accounts, we will all be better off when developers like Agile Bits do all they can to encourage folks to practice fundamental cyber security.

As an aside, Windows<->iOS would be what I'd personally use the feature for.

@jpgoldberg The WLAN syncing feature (or some alternative form of syncing not yet created) is a complementary feature to standalone vaults, and therefore should not be compared to the 1Password.com service to justify its exclusion. The feature only ought to be compared to alternative sync methods for standalone vaults.

Let's take Dropbox as an example. We have significantly less insight into what's going on with Dropbox's computer and networks than we do our own. If Dropbox were breached, or for that matter any network in between while the file was in transit, we would have no warning or knowledge that our information was compromised until they deigned to communicate it - and recent history has emphasized that companies are often reluctant to share that sort of information. Consequently, our information could be misused long before we even become aware of it.

On the other hand, were a computer or device of our ownership stolen or lost, we should know right away. Active measures could be immediately taken to change every password.

I note your references to whether or not 1Password's data encryption is "good enough". To me, it's more about layers of security and reducing points of failure - if it comes down to the strength of 1Password's data encryption being the only thing protecting my data, something has already gone horribly wrong. If the data stays entirely within my network/possession, I have additional layers protecting it including, but not limited to, drive encryption, firewalls, network monitoring, and good security practices e.g. not running untrustworthy software or opening strange e-mail attachments, etc. Of course, I'd like 1Password's data encryption to be strong on top of all of that, but I'd prefer things not reach the point where that becomes necessary.

As soon as you introduce an external sync solution like Dropbox, you're adding multiple levels where things can go horribly wrong, both of the electronic sort and the human sort. The more places the data lives and travels outside one's network, and the more badly-trained workers that are perfectly happy to open INTERNATIONAL_LOTTERY_WINNER_CLAIM_FORM.notavirus.pdf.exe on their poorly-secured corporate network, the more it matters whether 1Password's data encryption is indeed "good enough." But, again, with WLAN syncing we'd do a lot to prevent it from reaching that point.

We'll continue to evaluate if there are things we can do to help with niche use cases that can benefit more people — like perhaps enhancements to folder sync.

I think you get so much negative feedback here because 1P is basically loved and there's only two password managers that supports on-premise syncing between Windows and iOS. There's simply nowhere to go except Enpass (which supports WebDav sync to Own/Nextcloud).

You didn't refer to me, but I'd like to add this: I feel a horrible loss of control if I'm forced to store data, even encrypted, anywhere else except my local network. This is an emotional dilemma and it doesn't matter how much logic you throw at it. Just the thought alone is physically sickening. I got taught many times that one should not upload anything into the internet that you're not willing to share publicly. It's very hard to unlearn this and it's especially hard to stomach when you already offered a quite solid solution in 1P 4.

(my original argument about legal/privacy limitations is still my main concern and deal breaker, btw. I just wanted to share my emotional stance as well)

I wrote a comment to this thread, but after editing it a couple of times to try to clarify a couple of points it gave a small error that said it was in moderation and the comment seems to have disappeared.

I'll try to keep the rewrite more succinct:

@jpgoldberg WLAN syncing is a complementary feature to standalone vaults, and should therefore be considered from the perspective of someone who's only interested in a standalone license. The feature should then only be compared to alternative means to sync standalone vaults excluding the 1Password membership. WLAN syncing (or some other new feature that has the same end result) beats the alternatives because you know where the data is at all times, and the strength of 1Password's data encryption doesn't really enter into it unless several other layers of security have already failed (e.g. encrypting your hard drives, monitoring your network, good security practices such as not opening suspicious attachments or running untrustworthy programs).

When you add an external sync provider like Dropbox (and I'd go as far as to wager most of them don't have nearly as good of an attitude towards security as you folks), you add a lot of places where things can go horribly wrong, and a lot of people working for those companies who can make mistakes with the end result that your information is compromised. For some types of information, it would be an acceptable risk, but when it comes to passwords, I (and probably many others) rather err on the side of caution and mistrust. As soon as that information leaves your hands, it's out there. Decryption then becomes a matter of eventuality - whether a weakness in the encryption algorithm itself is found, or some weakness in the implementation, or even if simply enough hardware and/or parallelization is thrown at it with modern cracking techniques, the information will be revealed. Frankly, I'd rather keep it to myself.

I'm going to talk about things bit by bit, and probably will not touch upon everything in one response.

Cryptography is hard

the finest minds in cryptography will tell you "encryption is hard."

Yes it is. Even when using extremely well designed and implemented libraries it is remarkably easy to use them incorrectly. It is easy for very smart developers to make text book errors because they aren't familiar with the textbooks.

Look at an early (long since fixed) WhatsApp design error. They used a well chosen and implemented stream cipher for session data between client and server. Except that they used the name nonce/key combination for traffic in both directions. I cannot blame anyone who hasn't had a course on cryptographer for knowing why that was such a terrible thing to do.

If you look at our own open-sourced SRP library, which is one of the very few places where we have rolled our own crypto, you will note that it deviates from some naming conventions. Instead of using "a" for the client's ephemeral secret, it is actually called "ephemeralSecret". This is because when going over an earlier implementation of SRP in when of our platforms, I said something about "little a" being a cryptographic secret. One of our developers asked the excellent question: "How was I to know that little a is supposed to be a secret?"

To anyone familiar with reading about Diffie-Hellman-like protocols, we all know what "a", "A", "b", and "B" are about. But there is no reason to expect others to.

OK. I've digressed. Cryptography is hard. Application security is hard. And anyone who says that their system is unbreakable is either a liar or too stupid to be in the business. I really hope that I wasn't saying anything that made me a liar or stupid.

My point was one of comparison. If you trust 1Password to encrypt your data on your own device, which can be easily lost and stolen, why wouldn't you trust it elsewhere? Now you may not trust it in either place, or you may trust it in both; but my question is why one and not the other?

Code supply chain

OK. I am letting myself get off track to talk about more of the really good points that you made.

Does AgileBits write all its own code from scratch?

For cryptographic operations and protocols we do as little as possible. One exception is the SRP implementation I pointed to above. And in OPVault, we had to roll our own "Encrypt-then-MAC" implementation. We knew we needed authenticated encryption, but getting something like GCM mode encryption on every platform we needed to support would have led to a really nasty chain of library dependencies at the time. (That has changed. GCM is now pretty much natively available in all OS provided SDKs.)

the downside--a supply chain compromise

These are the kinds of choices that make security hard. We don't have a single rule about this for all development teams, and we address these decisions and the management of these on a case-by-case basis. Mistakes are always possible.

But again, such mistakes apply as well to data on your own devices as it does to data stored elsewhere.

To be continued ...

It's dinner time, and I've barely touched upon your points and comments. I will be back later.

Hi,
It’s exciting to hear that 1PW7 is out of alpha.
I really appreciate the work you do at agilebits.
However dropping support for WLAN sync is a disappointment on my end because I heavily rely on it with my windows desktop and iphone.

Nonetheless the decision is made and there is no going back I guess. I have to find a way to sync my iphone and my windows machine without using WLAN support.

So big words short : is it possible to sync my iphone and my windows machine without using WLAN or cloud services ?

I know I should be focusing on the main points, but there are just so many cool questions and issues that @ftwilson raise, so ...

Key derivation and hashing

Needless to say, for example, using SHA256 is much better than SHA1, like Firefox has been doing for the last (at least) nine years.

Obviously nobody should build anything today using SHA1, but I think that a lot of people criticizing some systems that still use it fail to understand what the problems are and what the security properties different systems need from a cryptographic hash function.

The problem with is with their iteration count, not with the use of SHA1. A cryptographic hash function is supposed to satisfy three major properties

Pre-image resistance

Collision resistance

Second pre-image resistance

Collisions

SHA1, with its 20 byte output is coming closer and closer to failing on collision resistance. We don't want it to be feasible to two things that produce the same hash. That would be a "collision."

Even if it were otherwise perfect in this regard (which it isn't) it
is just too short to offer collision resistance in a world of more
data and more processing power. Roughly we need cryptographic hashes
(where collision resistance matters) to be twice as long as our
security parameter. With respect to collisions, the hash needs to be
roughly twice as large as our security parameter. A system with 256
bit hashes is needed to get 128 bit security in this respect.

But that isn't relevant for password hashing. It's not a security property we need. With respect to collision resistance, we only need much weaker guarantees.

Second pre-images

Where things like MD5 dramatically fails and SHA1 to a lesser degree is with second pre-image resistance. This is a special type of collision. If you are given a particular thing and its hash, can you construct a second thing that has the same hash? Suppose that message m is hashed and produces hash h. Can an attacker with knowledge of m and h construct a different message, m1 that also hashes to h? That is, can they find a second pre-image, m1, of h?

The answer with MD5 is demonstrably "yes". The answer with SHA1 is "not yet." These matter most importantly for digital signatures. Let me quote something I wrote six years ago. Note that in that article I used the word "collision" to include second preimages.

Now let’s look at why collision [second preimage] resistance is important for digital signatures. Suppose that Patty, one of my dogs, creates two files. One of them says, “Molly is the cleverest and prettiest dog ever, and Molly gets to rule.” The other file that Patty creates says, “Patty will get all of Molly’s dog treats.” Patty, of course, is the clever one. She is able to create these two files so that they produce the same hash. Patty has created these two files in such as way that their hashes collide [she has created a second preimage for the hash of one of them]. Patty asks Molly to digitally sign the “Molly rules” file, and Molly is happy to comply. Molly, using her secret key, creates a signature for the “Molly rules” file. The digital signature is actually a signature of the hash of the file, and so that signature will also work as a signature for the “Patty gets all the treats” file.

Patty will then bring me the “Patty gets all of Molly’s treats” file along with Molly’s signature. I calculate the hash of the file and verify that the hash really is signed using Molly’s secret key. Nobody but Molly knows that secret key, and so I figure that Molly must have signed that file. I give all of Molly’s treats to Patty. Molly may like to collide with Patty on walks, but this is one collision that Molly is not at all happy about.

So SHA1 must not be used in digital signature schemes. This is why
digital certificates that have been signed using SHA1 are soon to no
longer be accepted by major browsers and systems.

But, again, second preimage resistance is not a security property that is relevant for password hashing.

Finding Pre-images

The first requirement of a hash function is that you cannot learn anything about the message that was hashed from the hash alone. If h = H(m) then knowledge of h should give you zero information about m. The idea is that you cannot work backwards from the hash to the thing that was hashed. This is the security property that matters for password hashing. (There are other things we want in password hashing, but this is the property that matters for the underlying hash function.)

Cryptographic hash functions, including SHA1 and even MD5 still do a good job of that. But do not use them in your systems. The problem with using them even uses where they still work is that it makes it much much easier for their roles to shift in your system and for them to end up being used where they shouldn't be.

Even very smart developers are not going to know what uses of SHA1 are "safe" unless they've had substantial cryptographic training. So it is best not to use them at all. So yes. Don't build password hashing systems that use SHA1, but there is nothing inherently wrong with a legacy system that happens to use it. (There is likely to be other things wrong with it because it will be old and will not have benefited from more recent developments).

There is one more thing that may be misleading about the way I have described preimage resistance. I've said that having the hash should give the attacker no (meaningful) advantage in learning anything about m. But we know that that isn't true with passwords. Hashes get "cracked". It's not that the attacker works backwards from the hash to the password, but they use the hash to test various password guesses.

So what's going on here. A preimage resistant hash function means that the hash should provide no (meaningful) help in determining the original message, but when a site is breached and the attackers get the hashes, they do end up learning what a lot of the passwords were.

This apparent conflict is resolved when preimage resistance is defined more fully. The full definition requires that m be drawn uniformly from a large set of possible messages. It is because the password choices that people make are far from uniform that password cracking is possible even when when the hash function is preimage resistance.

The point of all this?

I don't know. I suffer from a pathological compulsion to explain things to people. But before of rules of thumb. Yes, "SHA1 is bad, don't use it" is a good rule of thumb, but it doesn't mean that something that uses SHA1 necessarily weak.

A lot of people get caught up in algorithm choice. Those choices are important, but it's really the design of the construction using those algorithms that are often more important.

And, I've still procrastinated on addressing the substance of your message.

Sorry guys, but for me it looks like that we are at the same point as 1 year ago. There was a thread with thousand of posts from the user base regarding the needs of local vault support instead of 1PW Account only.
Focused on a {redacted, this is a family-friendly forum] against 1PW, you announced several months ago to support local vault support in 1PW 7 for Windows. The user base was happy again and gave you the time you needed to integrate this feature in the new version of 1PW for Windows.
Now, shortly before you are releasing the new version of 1PW for Windows with local support, you announced that there will be no possibility to sync the mobile app e.g. iOS without cloud integration?

Sorry but this is no local vault support from my perspective. After waiting for a period of one year and all hopes to get a fantastic new 1PW solutions in which the user can decide how to store and sync the data, it’s very disappointing.

Instead of discussing the advantages and disadvantages of storing the vault into the cloud, you should put your energy into implementing this kind of feature which already was included in previous versions and used by several users.

Sorry for my hard words, but I’m a fan of 1PW and scared to loose some of my main functionalities.

Well, I am one of those users who is using 1Password 4 with manual password sync between Windows 10 and Android phone. I do not want my data hosted somewhere else out of my range. I am aware of all arguments which put the cloud solution on top. I have convinced so many people to use 1PW and they all sync their data manually with their phones (we are a big user group). Since the current version 4 is getting older we all had looked forward to new Version 7 with local vault support. Right now after your announcement of not supporting local wlan sync, nearly everybody is disappointed. Nobody understands how local vaults without a build in sync solution should make sense.

I am completely aware of the all the arguments from your side not to provide such an option, but I think you miss a really important point here:

It’s for customers!

Just imagine how it would be to sell your product with 2 big slogans on your starting page:

“100% local or cloud comfortable, it’s up to you!

Man I bet you would get that much more users you cannot imagine right now. If it belongs to the money, just develop an extra wlan module and sell it separately. Nobody cares about the money as long it is a single price license where you pay only once.

Please don’t act like Electronic Arts who are saying they know exactly what their users want and they want (from the view of EA) micro transactions to have a better game feeling. We all know how this has ended.

I take offense to the "our security is better than yours" line. I'm a network security architect with 20 years of experience. I think any platform with a greater attack surface (like you said... you get attacked daily) is a much bigger risk than my home network which is hidden on the internet behind a firewall with no open ports.

I agree with @frame. I just want the ability to sync my devices on my network without resorting to the cloud. Does that mean WLAN sync? Not necessarily. That isn't the requirement... it was cludgy. But there are tons of other options:

Webdav. If the local vault is protected enough to be sent to the cloud or to drop box, no reason you can't support arbitrary webdav servers. In fact, the code would be very similar to Dropbox so you can share a good portion of it. Its up to us to build a webdav server for the data. Heck, if its set up right, the webdav folder is the authoritative vault and can be what we back up. No need to worry about backing up my laptop (which I argue should be able to be thrown away and rebuilt quickly). Since the people fighting for on prem sync out of the cloud are going to be more technical, and the code is fairly simple, this is an easy win. Plus, you can say you don't support. Just provide a list of webdav servers that you know work well and a sample config and its up to the owner.

SMB or CIFS to a folder... Might be harder to build this support in iOS devices but the ability to copy a folder between network shares is simple.

Custom on prem software... You can indeed write a sync mechanism that leverages a service running on prem. Its harder than just supporting webdav, and you'd own it, but you already have a lot of that code written for your cloud anyway.

I waited months to go from 1password 4 to 1password 7 just because you said you were bringing back standalone vaults. A few weeks ago in another thread I asked about syncing and you said you were working on it. Now, you're going to backtrack on that commitment? Really? So you get me to pay up for the upgrade and now you pull out a necessary feature?

@scott_savarese: Please don't. You're (presumably) just one person, and you have to sleep at some point, while we can have folks on our team monitoring our systems around the clock. That's not a knock against you. You just (hopefully) have a life outside of security. But it's effectively all we do here at AgileBits.

I'm a network security architect with 20 years of experience. I think any platform with a greater attack surface (like you said... you get attacked daily) is a much bigger risk than my home network which is hidden on the internet behind a firewall with no open ports.

Absolutely. But you're probably not actively monitoring everything. You're just — reasonably — setting things up and expecting that all is well unless something happens to make you think otherwise. But apart from our own efforts to continually test ourselves, we participate in external audits and cooperate with independent security researchers to ensure that we're not just seeing what we expect to see and missing something because it just works and we're just happy it does. I have no doubt that you're both competent in your area of expertise and care about your own security, but the work we do to secure our systems can be more efficient and effective because every bit of effort we put into it is multiplied to benefit all 1Password.com members — so we can invest more heavily in that as a result than we could if, say, Joe were the only 1Password.com member. Scale matters.

Webdav.

We're not doing that. It's something we worked on in the past, and long story short it is not at all suitable for 1Password.

SMB or CIFS to a folder...

Network shares can be very unreliable, so we always recommend using a local folder. But folder sync is already an option, and you're free to do that if you wish.

Might be harder to build this support in iOS devices but the ability to copy a folder between network shares is simple.

There's no way to sync to an arbitrary folder on iOS (yet? We'll see if Apple changes that in the future), so that's not an option.

Custom on prem software... You can indeed write a sync mechanism that leverages a service running on prem. Its harder than just supporting webdav, and you'd own it, but you already have a lot of that code written for your cloud anyway.

We're probably not going to do that because we've already built a great custom sync solution: 1Password.com.

I waited months to go from 1password 4 to 1password 7 just because you said you were bringing back standalone vaults. A few weeks ago in another thread I asked about syncing and you said you were working on it. Now, you're going to backtrack on that commitment? Really? So you get me to pay up for the upgrade and now you pull out a necessary feature?

Nope. Local vaults are already in version 7. It's something we announced last year and we're (publicly) delivering on it now with the beta of 1Password for Windows version 7. WLAN Server is a completely separate feature (quite literally), and while WLAN Server will not be in version 7.0, the purpose of this discussion is to see if you or anyone else would like us to spend the time and energy to develop, test, and support that in the new Windows app, and the reasons for that. Please see Dave's earlier comments about signing up so we can gauge interest.