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

Evernote hacked

blog.evernote.com

Post reply on HN
Print view View original

211–220 of 220 posts

Re: Evernote hacked

#211

Post by cschneid »

raverbashing wrote: post #202
cschneid wrote: post #123

Earlier quoted context omitted.

IMO, you should be doing both. People should use strong bcrypted passwords, with a salt, then ALSO a 'secret' pepper value (long value stored in app code). This adds additional security in the case of a db-only dump being released, and doesn't harm the strength or a full code+db release at all either. Stripping off identifying info from hashes like talked about in this thread doesn't weaken the hash in any way, but i…

Let me try to explain this better Suppose you're doing the byte shuffling right? Or you split the hash value in two and you concatenate them in the reverse order, something like that. Now here's the thing: if you have a determined attacker, they will figure out your code does that. So you gain no extra security from it For a casual attacker this may be a bigger deterrent. Now, this casual attacker may try to create (…

You're right. Throwing shit at the wall can screw things up, and you must still be using a proper full-strength hash, and not just throw crypto primitives at it.

What I'm suggesting is that secrecy is a useful layer on top of a valid cryptography approach.

What you can do is that you can have the inputs to your hash function come from several places. User password, a salt per-password to protect against rainbow table attacks, a pepper forces an attacker to get both the application code, AND the database dump.

So it's bcrypt(password + salt + pepper). If you don't know the pepper, all of a sudden you have a 128+ character totally random password to break, instead of the user's totally insecure '12345'.

And in the case that you have the application code broken (ie, attacker gets the production code), well, then you're still using bcrypt, so no problem.

That step would protect against the common "db dump stolen off a dev's laptop" attack. Since the pepper only exists in production.

So yea, you're right that you can't just make shit up and hope for the best. But separating the data that needs to be stolen strengthens your overall defense.

Re: Evernote hacked

#212

Post by reyan »

gcr wrote: post #183
reyan wrote: post #149

Earlier quoted context omitted.

The definition of a symmetric cipher requires the cipher text to be (practically) indistinguishable from random. Length is not particularly useful (multiple blocks, different block ciphers with equal block length).

Lots of developers who read "Learn PHP in 24 Hours" and similar texts use md5 (32 chars) or sha1 (40 chars). If you're an attacker and see a hex string that's 40 chars long, that gives you a great place to start since you know it's likely to be a naïve SHA1 hash.

If Evernote is not using a key derivation function, I don't know what to say.

Re: Evernote hacked

#213

Post by miles »

patrickaljord wrote: post #209
miles wrote: post #166

Earlier quoted context omitted.

Thanks for igniting this discussion, Niten. While digging around, I stumbled onto this tool which others might find helpful: https://github.com/lowe/zxcvbn zxcvbn, named after a crappy password, is a JavaScript password strength estimation library. Use it to implement a custom strength bar on a signup form near you! zxcvbn attempts to give sound password advice through pattern matching and conservative entropy calcul…

If I enter the first 10 characters in regular order of my French azerty keyboard that are &é"'(-è_çà)= I get a top 4/4 score :). Not very good for security.

The author of zxcvbn acknowledges this weakness (and others) here:

https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-s...

zxcvbn currently only supports English words, with a frequency list skewed toward American usage and spelling. Names and surnames, coming from the US census, are also skewed. Of the many keyboard layouts in the world, zxcvbn recognizes but a few. Better country-specific datasets, with an option to choose which to download, would be a big improvement.

Re: Evernote hacked

#214

Post by mbreese »

cynwoody wrote: post #200
miles wrote: post #166

Earlier quoted context omitted.

Thanks for igniting this discussion, Niten. While digging around, I stumbled onto this tool which others might find helpful: https://github.com/lowe/zxcvbn zxcvbn, named after a crappy password, is a JavaScript password strength estimation library. Use it to implement a custom strength bar on a signup form near you! zxcvbn attempts to give sound password advice through pattern matching and conservative entropy calcul…

Interesting. xyzzy scores 'instant'. My B of A pass phrase, Jer1m1ah Cl4rke, scores 31 years. Should I change it? https://dl.dropbox.com/u/209/zxcvbn/test/index.html Edit: I just checked 9223372036854775808L, and it answered 'centuries' with a suspiciously round crack time in seconds. Don't think so.

You should probably change it now...

Re: Evernote hacked

#215

Post by jimktrains2 »

Ensorceled wrote: post #182
jimktrains2 wrote: post #56

Earlier quoted context omitted.

What lack of encryption?

Oh, sorry. I was under the impression that Evenote stored my files in plain text. Do you have information on what encrypted storage format the are using?

Oh, I thought you were referring to their storing of passwords or in transit. I don't think they can store notes in an encrypted format because they do ocr on images, which is actually one of the selling points for me.

I just with their built-in text encryption was better.

Re: Evernote hacked

#216

Post by cschneid »

pixl97 wrote: post #186
cschneid wrote: post #123

Earlier quoted context omitted.

IMO, you should be doing both. People should use strong bcrypted passwords, with a salt, then ALSO a 'secret' pepper value (long value stored in app code). This adds additional security in the case of a db-only dump being released, and doesn't harm the strength or a full code+db release at all either. Stripping off identifying info from hashes like talked about in this thread doesn't weaken the hash in any way, but i…

With publicly creatable accounts by the potential hacker, a pepper is just another password. Leaving identifiable bits in the hash makes it easier to do things like if pass_type ($1$) { on_logon $upgrade_to_pass_type$6$) > At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected. If you ever know at all. Better to use 'not fast' hashes like bcrypt, scrypt, or PB(something) that…

Re pepper: It's a STRONG password. It turns '12345' into 64 random characters + '12345'. Meaning that you can't brute force against a dictionary, unless you have that pepper value. Which is only stored on the production system. This turns a well-known attack vector of "developer loses a data dump" into something that won't expose passwords.

Re hash: yeah, use a strong hash function. Never advocated otherwise.

Defense in depth is awesome, and not to be ignored. Just like we secure the database with a password, in addition to securing the server (with ssh keys), in addition to keeping software up to date, in addition to rate-limiting online password attempts, in addition to... well, you get the idea. Protect at every level. Make the attacker work as hard as possible.

Re: Evernote hacked

#218

Post by ncryptedcloud »

tlrobinson wrote: post #171

Any suggestions of migration paths to more security conscious alternatives? I'd even be happy with an encrypted disk image on Dropbox if there's a good way to OCR scanned docs, then be able to search them.

(Disclosure, I work for nCrypted Cloud)

Since you ask and since you appear to be a Dropbox user looking for more security, check out www.ncryptedcloud.com It is a Privacy, Security and Collaboration app that layers on top of dropbox (Skydrive and Googledrive soon)

Re: Evernote hacked

#219

Post by ncryptedcloud »

quinndupont wrote: post #74
jpdoctor wrote: post #12

Earlier quoted context omitted.

> to adopt real security. Won't happen until it's perceived that the lack of security is costing them money.

Personally, I've complained to them that as a premium user I should be given the option to fully encrypt a notebook (zero-knowledge style, so only I have the keys). This prohibits all the social network-type sharing stuff though, so they are uninterested in doing this (same with Dropbox). It's a fundamental issue, but I hate that these companies think they should put "sharing" ahead of "security".

(Disclosure I work for nCrypted Cloud)

The FREE product is still in Beta but the Pro version (due out in two months) WILL allow you to request zero knowledge and there will be no Recovery key. I know that you know that this means that if you ever forget your password, there is no helping you but I say it so that others reading this understand the dangers of this.

Why are we going to supply this functionality then? Because users keep requesting it

Re: Evernote hacked

#220

Post by ncryptedcloud »

MartinMond wrote: post #5
rdl wrote: post #3

I've never really understood the security model for Evernote. It's "an exocortex" -- your personal notes, which are likely to be more security sensitive than general documents, email, etc. And yet they have even less security than Dropbox, themselves not exactly an exemplar of robust security. They've got competent people operating the service; it's just not well designed for security.

Yeah, Evernote really should have been zero-knowledge end-to-end encrypted. Recently https://crypton.io/ was released and my hope is that lots of new SaaS offerings will use it and that this will in the end force even the big names (Dropbox, 37signals, etc) to adopt real security.

(Disclosure I work for nCrypted Cloud)

Zero Knowledge will be an option with the pro version due out in about 2 months but as I have commented before, if the password is forgotten, there is no accessing that data

Post reply on HN