Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vesper 2.0 and Vesper Sync

vesperapp.co

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Vesper 2.0 and Vesper Sync

#41

Post by jafitc »

gress wrote: post #25
jafitc wrote: post #22

Earlier quoted context omitted.

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-…

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 Dro…

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)

Re: Vesper 2.0 and Vesper Sync

#42

Post by ghshephard »

jhh wrote: post #39
tptacek wrote: post #17

I admire the clarity of Gruber's writing, and I'm very happy that Vesper is honest about their capabilities w/r/t/ decrypting notes stored on their server, but "salted and hashed" was an unforced error. 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 w…

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.

Re: Vesper 2.0 and Vesper Sync

#43

Post by atmosx »

> 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.

Re: Vesper 2.0 and Vesper Sync

#44

Post by supercoder »

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

Re: Vesper 2.0 and Vesper Sync

#45

Post by tptacek »

zaroth wrote: post #36
jgruber wrote: post #20

Earlier quoted context omitted.

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...

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... )

If by "bitten by this" you mean "had their security reduced by 1 bit", then sure.

Re: Vesper 2.0 and Vesper Sync

#46

Post by tptacek »

ghshephard wrote: post #42
jhh wrote: post #39

Earlier quoted context omitted.

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.

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).

Re: Vesper 2.0 and Vesper Sync

#47

Post by tptacek »

SeoxyS wrote: post #38
tptacek wrote: post #17

I admire the clarity of Gruber's writing, and I'm very happy that Vesper is honest about their capabilities w/r/t/ decrypting notes stored on their server, but "salted and hashed" was an unforced error. 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 w…

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 e…

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.

Re: Vesper 2.0 and Vesper Sync

#48

Post by jhh »

ghshephard wrote: post #42
jhh wrote: post #39

Earlier quoted context omitted.

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.

So what is their primary essence?

Re: Vesper 2.0 and Vesper Sync

#49

Post by gress »

jafitc wrote: post #41
gress wrote: post #25

Earlier quoted context omitted.

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 Dro…

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 a…

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.

Re: Vesper 2.0 and Vesper Sync

#50

Post by zaroth »

tptacek wrote: post #45
zaroth wrote: post #36

Earlier quoted context omitted.

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... )

If by "bitten by this" you mean "had their security reduced by 1 bit", then sure.

I remember it feeling like a bigger deal reading about it at the time, but as you say, you're just throwing away half of the stretching, reducing attack cost by half.
Post reply on HN