Vesper 2.0 and Vesper Sync(vesperapp.co)
vesperapp.co
Vesper 2.0 and Vesper Sync
http://vesperapp.co/blog/vesper-2-0-and-vesper-sync/
9 comments
We hash the password using pbkdf2. The actual code looks like this:
crypto.pbkdf2(text, salt, ITERATIONS, BYTES, function...
ITERATIONS is 1000, and BYTES is 32.
Our code is descended from the code on this page: http://www.thejoyofcode.com/Exploring_custom_identity_in_Mob...
crypto.pbkdf2(text, salt, ITERATIONS, BYTES, function...
ITERATIONS is 1000, and BYTES is 32.
Our code is descended from the code on this page: http://www.thejoyofcode.com/Exploring_custom_identity_in_Mob...
That's great; it's the answer I quietly predicted I'd get. If you're communicating to laypeople, you can say something like "we use a modern secure password hash".
Note, if your crypto.pbkdf2() is using SHA1 underneath, then 1,000 interations of SHA1 is very little computation for a GPU, which can do billions of SHA1 per second.
Also, asking for 32 bytes from PBKDF2-HMAC-SHA1 has some bad side-effects, particularly if you are splitting up the result. (1Password got bitten by this, and wrote up the issue here: http://blog.agilebits.com/wp-content/uploads/2013/07/playing...)
Also, asking for 32 bytes from PBKDF2-HMAC-SHA1 has some bad side-effects, particularly if you are splitting up the result. (1Password got bitten by this, and wrote up the issue here: http://blog.agilebits.com/wp-content/uploads/2013/07/playing...)
No OS X version yet, but it's what they're working on next according to the last part of http://vesperapp.co/blog/vesper-2-0-and-vesper-sync/
> There's no OS X app for this yet, is there? I'd use it for personal stuff if there was.
I haven't fully committed to Vesper b/c it lacks a desktop client. I'm glad it is on the horizon. Now I'm hoping this client will somewhat resemble NVAlt (Notational Velocity).
I haven't fully committed to Vesper b/c it lacks a desktop client. I'm glad it is on the horizon. Now I'm hoping this client will somewhat resemble NVAlt (Notational Velocity).
If it's not too big a topic, could you expand on the appropriate cryptography for this use case? How 'bout without a central server? (Not interested in web clients.)
That's a fair complaint. The PBKDF2 answer is quite satisfactory (though I think that these days 10k iterations is warranted).
What I'm much more concerned about though is the server-side encryption of the notes[1]. Having the notes encrypted with a key that's kept on the same server, however frequently changes, adds barely any security. It gives the illusion of security: they can now truthfully say "your notes are encrypted on the server, yay!" But that's disingenuous, because the keys are stored on the same server.
A much better system would be to encrypt the notes on the device, using a key derived from the password. That way, the server can never see the plaintext of the notes, except for during login and when the password is being changed[2].
[1]: http://inessential.com/2014/04/17/vesper_sync_diary_14_keys
[2]: This is actually pretty easy to get around, by not sending the plaintext password to the server for login, but rather a different password-derived key. But if it were built that way it'd make it a little harder to update all the notes when changing passwords. But again, you could fix that by simply storing an encrypted version of a randomly generated encryption key on the service, and simply re-generating that when the password is changed, without having to chain the note ciphertexts. Kind of like how OS X full disk encryption works.
I actually touched on this by mentioning it to Brent via twitter the other day: https://twitter.com/kob/status/471152663384440832
What I'm much more concerned about though is the server-side encryption of the notes[1]. Having the notes encrypted with a key that's kept on the same server, however frequently changes, adds barely any security. It gives the illusion of security: they can now truthfully say "your notes are encrypted on the server, yay!" But that's disingenuous, because the keys are stored on the same server.
A much better system would be to encrypt the notes on the device, using a key derived from the password. That way, the server can never see the plaintext of the notes, except for during login and when the password is being changed[2].
[1]: http://inessential.com/2014/04/17/vesper_sync_diary_14_keys
[2]: This is actually pretty easy to get around, by not sending the plaintext password to the server for login, but rather a different password-derived key. But if it were built that way it'd make it a little harder to update all the notes when changing passwords. But again, you could fix that by simply storing an encrypted version of a randomly generated encryption key on the service, and simply re-generating that when the password is changed, without having to chain the note ciphertexts. Kind of like how OS X full disk encryption works.
I actually touched on this by mentioning it to Brent via twitter the other day: https://twitter.com/kob/status/471152663384440832
If they don't feel like they know exactly what they're doing with cryptography, I'm glad they opted to be candid about their limitations rather than bragging about their military-grade encryption.
It's incorrect that salted hashes are obsolete or quickly attackable per se. Password hashes are a subset of all hashes. Therefore they are hashes. bcrypt uses an internal salt (as it says in the first two sentences of its Wikipedia page).
Salted hashes have been irrelevant for at least 5 years, possibly more. It was a big deal in 1995-2004, back when "Rainbow Tables" were a thing. It just doesn't matter any more, and hasn't for a long time.
Don't be misled by the fact that bcrypt/pbkdf2/scrypt both use hashes, and have salts on the front - that's just a property of them, not their primary essence.
Don't be misled by the fact that bcrypt/pbkdf2/scrypt both use hashes, and have salts on the front - that's just a property of them, not their primary essence.
I think the right thing to say is that password hashes are all randomized, just like a salted hash --- but that when you say "salted hash", you are evoking SHAx(password, salt).
> We’ve tried to make it as easy and simple as possible to use. Here’s how it works. First, you create a Vesper Sync account using an email address and a password. Then, your Vesper data — the text of your notes, your image attachments, your tags, everything — syncs to our cloud service. Sign in using the same account on another device, and your Vesper data will appear on that device.
> That’s it.
I don't get why it's mentioned as something special - isn't it how it usually works? Dropbox, OneNote, OneDrive, Google Drive, anything? You create account, sign in, bam you have your data synced.
> That’s it.
I don't get why it's mentioned as something special - isn't it how it usually works? Dropbox, OneNote, OneDrive, Google Drive, anything? You create account, sign in, bam you have your data synced.
> Though it’s theoretically possible for Q Branch to read the decrypted note text or view image data, we don’t have a mechanism in place to do that, and we won’t create a mechanism unless legally ordered.
So you can't protect data from US organizations. That's the reason I ditched dropbox, I don't see any reason adopting another solution which is less supported by third parties and has the same flaws.
Any non-US citizen using US-based companies for online data storage should think twice before adopting any solution which is not in the EU or even better on his own country.
So you can't protect data from US organizations. That's the reason I ditched dropbox, I don't see any reason adopting another solution which is less supported by third parties and has the same flaws.
Any non-US citizen using US-based companies for online data storage should think twice before adopting any solution which is not in the EU or even better on his own country.
Genuinely interested in why you guys decided to roll your own cloud sync service instead of using something like dropbox or the like.
I recently started using YNAB (youneedabudget.com) for OSX and iPhone, and one of the things I liked the most is how they used dropbox to sync flawlessly between devices.
It's probably hard enough doing sync right even with the help of dropbox API, but it just seems to me that rolling your own makes it two problems instead of one.
Care to share your reasoning? Thanks!
I recently started using YNAB (youneedabudget.com) for OSX and iPhone, and one of the things I liked the most is how they used dropbox to sync flawlessly between devices.
It's probably hard enough doing sync right even with the help of dropbox API, but it just seems to me that rolling your own makes it two problems instead of one.
Care to share your reasoning? Thanks!
As the other posters have remarked, Brent's sync diary provides some of the concrete technical reasons why we rolled our own.
Big picture, though, we consider sync so essential to Vesper's long-term success that we wanted to control it. Dropbox is fantastic. We all rely on it personally. But we don't want Vesper to rely on it. I'm sure everyone here on Hacker News has a Dropbox account, and I'll bet most Daring Fireball readers do too. But we want Vesper to appeal to everyone, including people who don't know what Dropbox is or don't want it. (Plus, Dropbox doesn't work exactly the way we want it to work; we have code running on our servers, not just data stored on them. Vesper Sync works exactly the way we want sync to work.)
iCloud is very tempting too, because it puts all the onus of identity, privacy, and security on Apple's shoulders. But with iCloud, you have to choose between document syncing and Core Data -- neither of which is a perfect fit for the way Vesper is designed.
Lastly, we want to keep the door open for a web app version of Vesper, and a non-Mac App Store version for OS X. iCloud, by design, only works for apps distributed through the App Store.
We wanted to offer one and only one good way to sync. That meant rolling our own.
Big picture, though, we consider sync so essential to Vesper's long-term success that we wanted to control it. Dropbox is fantastic. We all rely on it personally. But we don't want Vesper to rely on it. I'm sure everyone here on Hacker News has a Dropbox account, and I'll bet most Daring Fireball readers do too. But we want Vesper to appeal to everyone, including people who don't know what Dropbox is or don't want it. (Plus, Dropbox doesn't work exactly the way we want it to work; we have code running on our servers, not just data stored on them. Vesper Sync works exactly the way we want sync to work.)
iCloud is very tempting too, because it puts all the onus of identity, privacy, and security on Apple's shoulders. But with iCloud, you have to choose between document syncing and Core Data -- neither of which is a perfect fit for the way Vesper is designed.
Lastly, we want to keep the door open for a web app version of Vesper, and a non-Mac App Store version for OS X. iCloud, by design, only works for apps distributed through the App Store.
We wanted to offer one and only one good way to sync. That meant rolling our own.
That makes a lot of sense.
What I was thinking about was just how many times I gave up on an app because it made me "sign up" for something just to create simple documents, play a game (sometimes even ones that should work offline!), or take notes.
But, obviously, in your case it seems having more control clearly outweights these small problem-user cases. ;)
Congrats on shipping, good luck!
EDIT: Also, making syncing optional, as I just read you saying you would, makes this problem go away.
What I was thinking about was just how many times I gave up on an app because it made me "sign up" for something just to create simple documents, play a game (sometimes even ones that should work offline!), or take notes.
But, obviously, in your case it seems having more control clearly outweights these small problem-user cases. ;)
Congrats on shipping, good luck!
EDIT: Also, making syncing optional, as I just read you saying you would, makes this problem go away.
In other words, you agree that iCloud's attempt at vendor lock-in is bad for developers and consumers alike.
You are as weak as the weakest link in your system.
The more you rely on 3rd party services the more likely you're going to be burned by them.
If you have sync under your control, you can guarantee a certain level of user experience.
Is it more work? Definitely. Is it worth it? It depends on what your priorities are.
The more you rely on 3rd party services the more likely you're going to be burned by them.
If you have sync under your control, you can guarantee a certain level of user experience.
Is it more work? Definitely. Is it worth it? It depends on what your priorities are.
You have this the wrong way around.
If you roll your own sync service, then you become the weak link in the user's system. Given how much effort it takes to get this stuff right and to maintain the service, it is irresponsible to do it yourself unless there are features you cannot otherwise deliver.
It's far better from the user's perspective for developers to use Dropbox or even iCloud, because the chances of them abandoning or losing user data, or simply failing as a business, are much slimmer than those of an app developer selected at random.
If you roll your own sync service, then you become the weak link in the user's system. Given how much effort it takes to get this stuff right and to maintain the service, it is irresponsible to do it yourself unless there are features you cannot otherwise deliver.
It's far better from the user's perspective for developers to use Dropbox or even iCloud, because the chances of them abandoning or losing user data, or simply failing as a business, are much slimmer than those of an app developer selected at random.
If you've never heard of the horror stories, I invite you to read up on that. It's not about the company going out of business, it's about having issues with a "black box" that you can't possibly debug or fix.
The things you don't have control over will end up breaking your promise to the user.
http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-...
http://arstechnica.com/apple/2013/03/frustrated-with-icloud-...
The things you don't have control over will end up breaking your promise to the user.
http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-...
http://arstechnica.com/apple/2013/03/frustrated-with-icloud-...
This isn't about trying to defend iCloud's teething problems, so these links are irrelevant.
Yes, there are risks associated with using a 3rd party service. However if you don't use one, you are claiming that you can do better in architecture, implementation, and DevOps.
How many apps do you have? Let's say you have 30.
What percentage of the developers of these apps do you think will do a better job of sync than Dropbox or Apple?
Unless you think that number is in the high 90's, then your advice is a severe disservice to end users.
Yes, there are risks associated with using a 3rd party service. However if you don't use one, you are claiming that you can do better in architecture, implementation, and DevOps.
How many apps do you have? Let's say you have 30.
What percentage of the developers of these apps do you think will do a better job of sync than Dropbox or Apple?
Unless you think that number is in the high 90's, then your advice is a severe disservice to end users.
You cannot shrug real problems off as "irrelevant".
Let me do a comparison to highlight how relevant it is:
1. iCloud: A user experiences an issue. Contacts your support. You finally figure out that the problem is caused by a system you have no control over. You tell the user a) there's nothing you can do about it b) they should prepare for it happening in the future. The user is unhappy. This repeats over and over again.
2. Custom sync: A user experiences an issue. You go to your server, find the root cause and fix it. The user is happy, and you also fixed problems for all the other users with the same issue. So this particular situation is never repeated again.
I've never said everything in your system had to be custom made. I emphasized, "it depends on what your priorities are".
If you priority is customer experience, then you can take the huge field of syncing, slice off a little manageable portion of it -- that makes sense for your app -- and attack it with elegance.
See you don't have to do a better iCloud, you just have to do a better slice of the syncing pie. Big difference.
Clearly not all developers are suited for this. But in a lot of cases, it is not only possible, but even advisable at the moment. Vesper is a good example.
(scenario number (1.) is not just a hypothetical situation you just have to look at the mountains of evidence: lot of apps had to remove iCloud syncing, because of the tons of complaints that flooded their support channels)
Let me do a comparison to highlight how relevant it is:
1. iCloud: A user experiences an issue. Contacts your support. You finally figure out that the problem is caused by a system you have no control over. You tell the user a) there's nothing you can do about it b) they should prepare for it happening in the future. The user is unhappy. This repeats over and over again.
2. Custom sync: A user experiences an issue. You go to your server, find the root cause and fix it. The user is happy, and you also fixed problems for all the other users with the same issue. So this particular situation is never repeated again.
I've never said everything in your system had to be custom made. I emphasized, "it depends on what your priorities are".
If you priority is customer experience, then you can take the huge field of syncing, slice off a little manageable portion of it -- that makes sense for your app -- and attack it with elegance.
See you don't have to do a better iCloud, you just have to do a better slice of the syncing pie. Big difference.
Clearly not all developers are suited for this. But in a lot of cases, it is not only possible, but even advisable at the moment. Vesper is a good example.
(scenario number (1.) is not just a hypothetical situation you just have to look at the mountains of evidence: lot of apps had to remove iCloud syncing, because of the tons of complaints that flooded their support channels)
Do you know anything about current icloud stability for document syncing?
I agree that scenario 1 is not hypothetical, and that iCloud was too unusable unstable for the first two years. I personally avoided including it in my apps for that reason, to my great disappointment.
However, it is routinely incorporated in new apps now, and as and end user I have had no serious problems since iOS7.
As a user I'd far rather trust iCloud or Dropbox than yet another sync service.
I've read Brent Simmons articles on how he did syncing for vesper, and it seems like he's done it well. Having said that, there is no indication of how well it will scale, and more importantly Brent has the experience to do this job well, whereas most App Developers do not.
I agree that scenario 1 is not hypothetical, and that iCloud was too unusable unstable for the first two years. I personally avoided including it in my apps for that reason, to my great disappointment.
However, it is routinely incorporated in new apps now, and as and end user I have had no serious problems since iOS7.
As a user I'd far rather trust iCloud or Dropbox than yet another sync service.
I've read Brent Simmons articles on how he did syncing for vesper, and it seems like he's done it well. Having said that, there is no indication of how well it will scale, and more importantly Brent has the experience to do this job well, whereas most App Developers do not.
You might be interested in one of the team's writings on the subject: http://inessential.com/vespersyncdiary
There is a deep dive on the granularity of syncing that hints at why they aren't doing Dropbox file-level syncing: http://inessential.com/2013/11/05/vesper_sync_diary_3_immuta...
There is a deep dive on the granularity of syncing that hints at why they aren't doing Dropbox file-level syncing: http://inessential.com/2013/11/05/vesper_sync_diary_3_immuta...
It's not quite a Canary, but the privacy policy has the line, "it's theoretically possible for Q Branch to read the decrypted note text or view image data, we don't have a mechanism in place to do that."
Presumably, that line will disappear if they create such a mechanism.
I'm super, super excited about the Vesper update, and can't wait for the OS X app to role out. I use vesper as my sole note taking app on my iPhone - it really is elegant, easy to use, and requires very little cognitive overhead to hop into.
On my Laptop, it's all evernote, but, as much as I use it (2-3 hours a day, all meetings) - I've never really loved it. It's got a lot of crud, and upselling stuff that overwhelms me when I'm trying to just enter a new set of meeting notes.
Love the way the Vesper team does stuff slowly, deliberately, and beautifully. If only all software was crafted with that much deliberation. Artisanal Software.
Presumably, that line will disappear if they create such a mechanism.
I'm super, super excited about the Vesper update, and can't wait for the OS X app to role out. I use vesper as my sole note taking app on my iPhone - it really is elegant, easy to use, and requires very little cognitive overhead to hop into.
On my Laptop, it's all evernote, but, as much as I use it (2-3 hours a day, all meetings) - I've never really loved it. It's got a lot of crud, and upselling stuff that overwhelms me when I'm trying to just enter a new set of meeting notes.
Love the way the Vesper team does stuff slowly, deliberately, and beautifully. If only all software was crafted with that much deliberation. Artisanal Software.
Are there any Vesper users that also used Simplenote?
I'd be curious to know if there is anything significantly better about Vesper, compared to Simplenote. I realize Vesper lets you add photos (cool) — are there other differences?
I'd be curious to know if there is anything significantly better about Vesper, compared to Simplenote. I realize Vesper lets you add photos (cool) — are there other differences?
Image attachments are the biggest difference. Another is that Vesper allows you to reorder notes by drag and drop -- move unimportant notes down, move important ones up. But the biggest difference, we hope, is that Vesper is just plain nicer.
I've used both. Simplenote has clients for major platforms and the web, unlike Vesper's iPhone only setup. This is the main reason I currently use Simplenote - I need a desktop client (web, OS X, or Windows). But when Vesper's Mac version launches I'd like to switch.
Simplenote offers more functionality than Vesper at the cost of complexity. Parts of Simplenote feel arbitrary or difficult to build a mental model for. Vesper is beautifully apparent in how it works & what you can do. I never feel lost or wrestling for control in Vesper.
Simplenote offers more functionality than Vesper at the cost of complexity. Parts of Simplenote feel arbitrary or difficult to build a mental model for. Vesper is beautifully apparent in how it works & what you can do. I never feel lost or wrestling for control in Vesper.
I primarily use Simplenote on my iPhone because it syncs with altNV on my Mac. altNV is my primary note taking tool. I have tried various combinations of replacements for both of these apps, but keep coming back to this combination.
I really love the Vesper interface. I find it much easier to use on the iPhone than any other note taking app. I also find the implementation of the tagging feature to be very easy to use to organize notes and to create work flows. If I only needed notes on my iPhone, I would choose Vesper
I could see myself moving to Vesper if the OS X version lives up to the same UI standards as iOS, embraces the keyboard, and has a good export/import story.
I really love the Vesper interface. I find it much easier to use on the iPhone than any other note taking app. I also find the implementation of the tagging feature to be very easy to use to organize notes and to create work flows. If I only needed notes on my iPhone, I would choose Vesper
I could see myself moving to Vesper if the OS X version lives up to the same UI standards as iOS, embraces the keyboard, and has a good export/import story.
Thanks for all the answers. As a heavy Simplenote/NVAlt user, this tells me I should wait until Vesper has apps on all platforms I use (iPhone, iPad, Mac) and reevaluate then. For the moment, I'll stay with simplenote, but keep watching.
I have no idea what Vesper is and after looking at the website, I still have no idea.
"Vesper is a simple and elegant tool for collecting notes, ideas, things to do — anything you want to remember. Organize your notes whatever way comes naturally to you, without complications. Vesper's focus is on how it feels to use."
https://itunes.apple.com/us/app/vesper-simple-elegant-notes/...
https://itunes.apple.com/us/app/vesper-simple-elegant-notes/...
"Vesper is yet another notetaking app. Money please!"
Vesper is a simple, elegant notes app for the iPhone.
The blog could use a link back to http://vesperapp.co
Even that wouldn't help. It's a contentless landing page.
Interesting timing with WWDC coming up.
Possible that Apple have been listening and present something new to make all these custom jobs redundant.
I'm hoping they do, as a developer who also has rolled a few custom sync solutions to avoid iCloud , we'd all be better off if the OS handled the dirty work properly
Possible that Apple have been listening and present something new to make all these custom jobs redundant.
I'm hoping they do, as a developer who also has rolled a few custom sync solutions to avoid iCloud , we'd all be better off if the OS handled the dirty work properly
Is there a way to export notes from the sync server to an open format?
I don't currently use Vesper, but lack of such functionality would be a dealbreaker for me.
I don't currently use Vesper, but lack of such functionality would be a dealbreaker for me.
My guess, knowing how smart the people behind the code for this app are, is that they're not actually using "salted hashes" to store passwords, but an actual password hash (like bcrypt). Either way: the announcement would be better if it said which one they used.
"Salted hashes" have been obsoleted, and are quickly attackable.
It is possible to build an app like Vesper and not have it be straightforward to be compelled by the authorities to build surveillance into it; with native clients as the only clients, some straightforward cryptography would get them there. I'd hope they'd at some point be interested in talking to cryptographers about how to do that right. But like I said, in the absence of sound cryptography, candor is a great substitute.
There's no OS X app for this yet, is there? I'd use it for personal stuff if there was.