Hacker News new | comments | show | ask | jobs | submit login
Evernote hacked (evernote.com)
343 points by tlogan 1728 days ago | hide | past | web | favorite | 210 comments



I'm kind of annoyed they didn't send an email, just flagged my password. So I couldn't use the iphone/mac apps and had to login via the web interface to reset. Which I didn't know because they didn't send an email, just got an invalid password error.

Their lack of encryption and lack of 2 factor auth just became a much bigger issue for me...


I have a lot of respect for the Evernote team. They've done a great job of improving the product over the last couple of years but it's puzzling that they've recently rolled out a version of Evernote targeted at business without addressing 2fa. It's a very serious gap in their offering.


And add poor performance of their app on iPad. They are present everywhere but except Windows client, all other apps feel very very slow!


Seriously, who doesn't do 2fa for something like this in 2013? Or 2012, or even 2011?


Apple, Microsoft, Yahoo (at least non-US), etc. ...

I'm not sure if there are any bookmark services that actually support this, though it'd be a decent selling point.

It was a big deal, when Google finally assed themselves to implement it for Gmail, but companies have been embarrassingly slow in following their example. Especially when they provide e-mail services.

Twitter hired TFA specialists a few months back, but they are taking their sweet time about implementing the system. I've wondered for a long time why social networks aren't on top of implementing this.

It's the SSL discussion all over again.


Google Chrome does bookmark sync using user-provided passphrase, so I'd consider that bookmark service with client side crypto and 2fa.

Crappy consumer services not supporting 2fa is somewhat understandable. No one uses Apple or Yahoo web services for business. People do seem to use Evernote in business contexts. Google Apps for your Domain is a fairly legitimate business option, as is Google Docs.


Right, forgot Chrome. I only thought of Opera, when it comes to browser-backed bookmark sync - at least on paper, since it doesn't work at all for me.


Rackspace doesn't support 2fa in 2013. Or multiple users on an account, for that matter... (much to my shock and dismay)


It's kind of funny that a lot of services which have decent general security have lax internal/admin user or account-management.

The weakest link at every hosting provider seems to be the customer admin panel/provisioning interface. This is one thing AWS does relatively well vs. other providers (now); IAM is pretty featureful, but few people actually use it to even 5% of what it can do.


Everyone?


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.


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.


> 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


I'm not a technical person, but how would they be able to search and index the items if everything is encrypted?


They wouldn't be able to do this on the server side. However their native iOS, Mac, Windows clients could just create&update the search index locally and sync the encrypted version. With HTML5 localStorage this also works in Web Apps.

Of course there's a tradeoff, but for me that's easily worth it.


The "tradeoff" seems to be "make the server into a dumb store for encrypted data." At which point, you don't have Evernote (an API for fuzzy-matching clippings punted into it from various devices), you have Evernote (a set of fat client programs each of which must maintain an entire copy of the dataset--notably, stored necessarily alongside its own decryption key on the client side, increasing attack surface--and do manual synchronization) plus a POSS (Plain Old Storage Service, like S3.) The resultant workflow sounds like it would have more in common with several people trying to edit the same Word document over SMB, than with making web requests.

[EDIT: clarity about client-side encryption]


  The "tradeoff" seems to be "make the server into a 
  dumb store for encrypted data." At which point, you
  don't have Evernote (an API for fuzzy-matching
  clippings punted into it from various devices),
  you have Evernote (a set of fat client programs)
  plus a POSS (Plain Old Storage Service, like S3.)
  In fact, the workflow sounds like it would have more
  in common with editing a Word document over SMB than
  with making web requests.
Not at all. Fuzzy-matching can be done client side just as well as server-side. The constraints are a bit different, but not too much (E.g. on the server-side: Make it scale --> conserve CPU, on the (mobile) client-side: Make it fast --> conserve CPU)

Otherwise, yeah most Web Apps are nothing more than editing stuff over the network and visualizing it differently.

The #1 competitor or a SaaS isn't some other SaaS but rather Word/Excel: http://www.startupcfo.ca/2011/05/the-1-competitor-for-saas-v...

Edit: Also there's no reason to believe the client-side store wouldn't be encrypted. That'd be exceedingly stupid.


I don't think you got quite what I'm trying to say--the whole point of Evernote is that all your data is "there", and the collated index for finding this or that is "there", and so any individual piece of data doesn't need to be on this device or that device. When you insert a new piece of data, all you need is that piece of data. You send it off to Evernote, and they stick it into your database. Then, later--still without any local state--you search the server to find out if anything you've sent in matches some arbitrarily-complex query--and if there are results, then you temporarily download [the newest version of] them from the server. The collation itself--not the storage, not the UX, but the ability to immediately put something into device X and then find it using device Y--is what you're paying them for.

Without that, what you have is a OneNote notebook stored in your Dropbox.

> Edit: Also there's no reason to believe the client-side store wouldn't be encrypted. That'd be exceedingly stupid.

It's encrypted with a key that's stored on the client, which is the same as the server being encrypted with a key stored on the server: effectively about as secure as DRM (i.e. not.)

To put it another way: presuming you have a motive to gain access to just my data--with this hypothetical service, if you steal my phone, you have my data, and the key to decrypt it. Or if you steal my laptop, or my desktop, or any other device the service is synced to. Or if you hack into them. All you need after that is the passphrase I (hopefully) set to unlock my encryption key--and for a single target, social engineering (or lead-pipe cryptanalysis) can get that right quick.

Meanwhile, there is only one thing people can do to steal my Evernote data: hack into Evernote's servers. If you just want my data, that's a whole lot more effort than it's worth, compared to just palming my phone.

[Now, if you want a bunch of random people's data, this is where using passphrase-locked + per-account-salted encryption-keys server-side is actually relevant to security. If it takes O(N) time to crack N accounts, there's much less incentive to do it than if it's O(1).]


Nonsense.

If your imaginary attacker can social engineer your local encryption password out of you, he can just as well engineer your Evernote password out of you. There is no difference.

The real issue is that today someone who hacks the Evernote servers will gain access to all users notes. With end-to-end encryption they'd have to target each user individually.


Also, you can store keys in something like the IOS keychain (which I assume is fairly secure) and then further require a pin code or password when you open the app.

Thinking off the top of my head:

priv_key = AES_DECRYPT(PBKDF2(pincode,salt),iv,RSA_key_from_keychain)

aes_key = rsa_decrypt(priv_key,encrypted_aes_key)


You could build an index in the client (perhaps as documents are edited), store the encrypted search index, and then do the search locally.

You could also have some files server-searchable (and accessible via a web UI -- there would be a way to download a client each time with the web ui, in js, to do client side crypto in the browser, but that has its own security vulnerabilities).

You might have 3 tiers -- client side encrypted and non-searchable, client crypto and client searchable including a javascript client, and server-searchable (and thus encrypted only using keys held by Evernote, just as a way to keep drives from getting cleartext on them).

The trick would be educating users and making a clear UI for this.


Evernote's value precludes a zero-knowledge model. Effective search, slicing by tag, OCR, etc. are all server-side.


(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


That's why I don't use any fancy services for my notes, which usually contains sensitive data. I simply use Notational Velocity which encrypts my notes and stores it locally. It does provide a synchronization option with SimpleNote but they can't even be bothered with using SSL.


amen to that. I stopped using evernote awhile ago because of this and once I started using NV I never looked back. Clearly they don't take security seriously enough, which is a shame for those who don't know any better.


NV?


Notational Velocity :)


we have found no evidence == "we really don't know"

Sorry, I'm sure the Evernote tech team is competent, but clearly some marketing spin has been put on this announcement.


Sorry, I'm sure the Evernote tech team is competent

What exactly leads you to this assumption?

They designed a service that stores sensitive user-data in an obviously insecure fashion (no end-to-end encryption).

If that's not incompetence then the only other explanation would be criminal negligence?


If they said, within hours, "We know they took nothing", they'd almost surely be lying, intentionally or otherwise.


I managed to reset my password to the same that it was before. I changed it again right away of course, but there should definitely be some protection against that.

(FWIW I didn't get the email so I was simply locked out and used their "forget password" form instead of trying to log in, which may have a different reset process).


This morning I tried to use the same password and it wouldn't let me, so maybe they fixed this issue.


Service currently unavailable. Here is their latest tweet:

    Important: Evernote just implemented a service-wide
    password reset. Please read our post for details and
    instructions
Said post is unavailable by the look of it.

Can someone post a paste of the blog post in here?


They aren't down (anymore), but in case you are still unable to read it:

-----

Evernote's Operations & Security team has discovered and blocked suspicious activity on the Evernote network that appears to have been a coordinated attempt to access secure areas of the Evernote Service.

As a precaution to protect your data, we have decided to implement a password reset. Please read below for details and instructions.

In our security investigation, we have found no evidence that any of the content you store in Evernote was accessed, changed or lost. We also have no evidence that any payment information for Evernote Premium or Evernote Business customers was accessed.

The investigation has shown, however, that the individual(s) responsible were able to gain access to Evernote user information, which includes usernames, email addresses associated with Evernote accounts and encrypted passwords. Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.)

While our password encryption measures are robust, we are taking additional steps to ensure that your personal data remains secure. This means that, in an abundance of caution, we are requiring all users to reset their Evernote account passwords. Please create a new password by signing into your account on evernote.com.

After signing in, you will be prompted to enter your new password. Once you have reset your password on evernote.com, you will need to enter this new password in other Evernote apps that you use. We are also releasing updates to several of our apps to make the password change process easier, so please check for updates over the next several hours.

As recent events with other large services have demonstrated, this type of activity is becoming more common. We take our responsibility to keep your data safe very seriously, and we're constantly enhancing the security of our service infrastructure to protect Evernote and your content.

There are also several important steps that you can take to ensure that your data on any site, including Evernote, is secure:

Avoid using simple passwords based on dictionary words Never use the same password on multiple sites or services Never click on 'reset password' requests in emails — instead go directly to the service Thank you for taking the time to read this. We apologize for the annoyance of having to change your password, but, ultimately, we believe this simple step will result in a more secure Evernote experience. If you have any questions, please do not hesitate to contact Evernote Support.

The Evernote team


I find evernote tremendously helpful and I pay the $5 per month for a premium service, REGARDLESS, a google of https://www.google.com/search?q=evernote+two+step+authentica... says little good about how Evernote respects me or their many many other customers whom have repeatedly asked for two factor authentication.


Let me be the first to say: HA-HA! </nelson>

Over the past few years I've told everyone to refrain from using Evernote. I told them that Evernote doesn't use end-to-end encryption and that eventually this would happen.

Hardly anyone would listen ("You're just paranoid", "I don't store anything private in there anyway, except.. oh").

For once I take cruel pleasure in being "that guy". The general public needs to learn this lesson.


I note that when Twitter released their breach notice on a Friday afternoon there were comments accusing them of trying to "bury" the news:

http://news.ycombinator.com/item?id=5154502

While there are (so far) no such comments about Evernote releasing this stuff on a Saturday morning. I think security breaches are just discovered at inconvenient times.


In the post, they say:

"The investigation has shown, however, that the individual(s) responsible were able to gain access to Evernote user information, which includes usernames, email addresses associated with Evernote accounts and encrypted passwords. Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.)

While our password encryption measures are robust, we are taking additional steps to ensure that your personal data remains secure. This means that, in an abundance of caution, we are requiring all users to reset their Evernote account passwords. Please create a new password by signing into your account on evernote.com."

What it doesn't say is how the passwords were dumped in the first place, or what they're going to do to ensure it doesn't happen again (outside of taking "additional steps"). I understand that not all users of Evernote are technical, but I'd like some peace of mind that a similar thing is less likely to happen in the future.


The following blog post is also being sent to all Evernote users as an email communication.

Evernote’s Operations & Security team has discovered and blocked suspicious activity on the Evernote network that appears to have been a coordinated attempt to access secure areas of the Evernote Service.

As a precaution to protect your data, we have decided to implement a password reset. Please read below for details and instructions.

In our security investigation, we have found no evidence that any of the content you store in Evernote was accessed, changed or lost. We also have no evidence that any payment information for Evernote Premium or Evernote Business customers was accessed.

The investigation has shown, however, that the individual(s) responsible were able to gain access to Evernote user information, which includes usernames, email addresses associated with Evernote accounts and encrypted passwords. Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.(http://en.wikipedia.org/wiki/Salt_(cryptography) ))

While our password encryption measures are robust, we are taking additional steps to ensure that your personal data remains secure. This means that, in an abundance of caution, we are requiring all users to reset their Evernote account passwords. Please create a new password by signing into your account on evernote.com(https://www.evernote.com/Login.action).

After signing in, you will be prompted to enter your new password. Once you have reset your password on evernote.com, you will need to enter this new password in other Evernote apps that you use. We are also releasing updates to several of our apps to make the password change process easier, so please check for updates over the next several hours.

As recent events with other large services have demonstrated, this type of activity is becoming more common. We take our responsibility to keep your data safe very seriously, and we’re constantly enhancing the security of our service infrastructure to protect Evernote and your content.

There are also several important steps that you can take to ensure that your data on any site, including Evernote, is secure:

Avoid using simple passwords based on dictionary words Never use the same password on multiple sites or services Never click on ‘reset password’ requests in emails — instead go directly to the service Thank you for taking the time to read this. We apologize for the annoyance of having to change your password, but, ultimately, we believe this simple step will result in a more secure Evernote experience. If you have any questions, please do not hesitate to contact Evernote Support(http://evernote.com/support).

The Evernote team


Your blog post says:

> "Avoid using simple passwords based on dictionary words"

And yet your password algorithm rejects highly secure pass phrases:

> "New passwords can contain letters, numbers and punctuation."

Disallowing spaces is particularly annoying for a company with a strong security requirement, as passphrases are simultaneously far more secure and far more memorable than the monkey rules your validation demand.

It gets worse.

If I type a long sentence without spaces such as "thisphraseisdefinitelynotinthedictionary", you give me an orange warning checkmark and suggest:

> "Try using a combination of letters and numbers"

If I replace that long phrase with "abcde1", just 5 lowercase letters and a digit, you give me a green checkmark! Same green checkmark for "abc123", the third most popular password online.

Have whoever wrote your validator needs to go read http://xkcd.com/936/ and really internalize the idea.

EDIT: See also:

1. How people choose passwords: http://www.troyhunt.com/2011/07/science-of-password-selectio...

2. Top 25 passwords: http://www.prweb.com/releases/2012/10/prweb10046001.htm

3. Twitter banned passwords: http://securitywatch.pcmag.com/none/284196-the-twitter-banne...


Anyone using this comic to imply that a passphrase is more secure than a short random password hasn't done the math. This is comparing a passphrase drawn from four of the 2048 most common words against not a random password, but one based on a mutated version of one of the 65536 most common words.

The example passphrase does have the equivalent of 44 bits of entropy:

log_2 (2048^4) = 4 * 11 = 44

However, if we take a random password formed by just seven of the 95 printable ASCII characters, we already have a password four times stronger than such a passphrase:

log_2 (95^7) ≈ 45.99

XKCD is great and all, but I wish Randall had been more clear that this comparison does not touch on the strength of a random password, because I have since seen an infuriating number of people point to it to claim that passphrases are more secure than random passwords. They are not.


The problem with your argument is that you are equating entropy with password strength. While entropy is a valid measurement of password randomness, it is not a direct measurement of how strong a password is. Take the password "vvvvvv.vvvvvvvvvv7vvvvvv" which has terrible entropy yet is very unlikely to be cracked. Why? because a cracker does not know that your password contains only three distinct characters and would still perform a brute force attack based on an assumption of higher entropy.

If you are talking about short passwords, entropy is critical in determining the strength of the password, but the true measure of a password's strength is the permutations required to perform a brute force attack. While range of character sets determine permutations, so does the password length. You can make up for one with the other, which is why "vvvvvv.vvvvvvvvvv7vvvvvv" is a very secure password.

That aside, I did address more of the math of the XKCD comic here: http://xato.net/passwords/analyzing-the-xkcd-comic/


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 calculations. It finds 10k common passwords, common American names and surnames, common English words, and common patterns like dates, repeats (aaa), sequences (abcd), and QWERTY patterns.

Sample results (including Tr0ub4dour&3 and correcthorsebatterystaple) and a demo can be found here:

http://dl.dropbox.com/u/209/zxcvbn/test/index.html


I also ported zxcvbn to python for those of you looking to integrate it into things that don't have javascript support (a native app or something--that was the original motivation for it).

https://github.com/rpearl/python-zxcvbn/

I am a bit slow at pulling patches (sorry, I just get super busy) but I do get to it eventually.


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


Pretty cool tool! My passphrases (omitting spaces between words) get a score of 2. But if I drop the vowels, the score goes to 4 and crack time to 'centuries'.

I wonder if this is a good way to create passphrases. Anybody want to chime in?


Originally was going to chastise you for typing your actual passwords into a random demo version that could have been modified in whatever way. But since it's all js I guess it's a simple matter to verify it's not transmitting anything. Although I guess it could be some really devious thing where it saves the info in a cookie to be snagged later or some such. Did you check the JS code? ;)


Don't use phrases. Use one really strong password that you can remember with a tool like KeePass. Generate random long passwords (30 characters) for everything and store them in KeePass.

I've recently converted all my accounts to that - my passwords are practically unbreakable, at least with the current tech. I feel way more secure than with the shit I had to memorize before.


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.


zxcvbn is great. We actually use it for people registering on https://www.tinfoilsecurity.com


>"I have since seen an infuriating number of people point to it to claim that passphrases are more secure than random passwords. They are not."

It appears you have assumed all passphrases must take the same methodological route as outlined in the xkcd comic.

However, 'noozle stroodle' has an entropy of 69.303 [1]

The above quotation, is a passphrase, and it's more secure than any 7char printable ASCII password.

While I accept your argument that not all pass phrases are necessarily more secure than seven lettered passwords, one cannot rightly make the antithetical claim either.

The correct judgement is: It depends

[1] According to the JS tester, http://dl.dropbox.com/u/209/zxcvbn/test/index.html


> to imply that a passphrase is more secure than a short random password

I noted to internalize the idea, the entropy idea versus human "random" passwords which aren't random at all. "Normals" are using their name with a 3 instead of an E, or some word with a 1 on the end. This tends to put them in rainbow tables or easy attacks. See my link #1 in GP comment for reference.

That's why I said "pass-phrases are stronger than monkey rules".

Meanwhile, "random" passwords don't necessarily come up stronger. Forget just seven. Let's use 1Password's random sixteen (16) char generator as an example[1]:

    2Fro%7gMfQbwBktm : 85.3 bits of entropy from 72 char set
    [xNyCHZc44RzPeMJ : 85.1 bits of entropy from 82 char set
Meanwhile, going by length and charset alone and ignoring whether the characters are words (using my passphrase from GP comment):

    thisphraseisdefinitelynotinthedictionary : 153.7 bits of entropy from 26 char set
The thing is, when you're attacking Evernote's database, you don't know someone's using XKCD's idea. So you're not looking at (2048^4) [2]. You're looking at (using the XKCD password):

    correct horse battery staple : 104.2 bits from 27 char set
If as an attacker we magically know "thisphraseisdefinitelynotinthedictionary" is words without spaces, and even assume they come from the 2048 word set (though neither "definitely" nor "dictionary" are in that 2048 word set), then by your formula:

    log_2 (2048^8) = 8 * 11 = 88 bits of entropy
markedly stronger than your example random password's 45.99 bits. And as I noted, "far more memorable", meaning such a phrase could be used by regular folks.

1. Quick entropy check: http://rumkin.com/tools/password/passchk.php

2. Manual entropy check: http://www.wolframalpha.com/input/?i=log_2%282048%5E4%29


Respectfully, you are flat out wrong. This "entropy check" doesn't prove what you think it does.

This password strength test is attempting to estimate the entropy of given passwords under the assumption that it is a word roughly obeying the character distributions of English text, using Shannon's approximation. It does not apply to randomly generated passwords, which violate these assumptions, as described in Appendex A of the NIST plublication linked on that very site.[1] As that document describes, the entropy of a randomly (not user!) selected password is not estimated in this manner, but calculated according to the same formula I provided: H = log_2 (b^L), where b is the number of letters in the alphabet (95) and L is the length of the password. (If the password had any less entropy than that, then by definition it would not have been pseudorandomly generated!)

Additionally, the algorithm employed by this site does not take into account that an intelligent password cracker is capable of exploiting the construction of passphrases.

In other words, you've taken an algorithm designed to approximate the entropy of a user-selected password and misapplied it to both randomly-generated passwords and user-selected passphrases. The fact that the algorithm is able to give you a number for these inputs does not mean it is any valid indication of how difficult such a password or passphrase would be to crack.

[1] http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1...

EDIT: But you're right that passphrases can be easier to use by people. I personally think a password manager like keepass / lastpass / etc. is a better choice than trying to select a memorable password, though.


First, all this is beside the point. Evernote hasn't understood the concepts of either entropy or human chosen passwords. Rejecting my passphrase and accepting "abc123" is wrong. That's my original post, and that's what you objected to. Computer generated random passwords that nobody's going to use on their mobile phone Evernote client, simply don't figure into normal human use.

Our job is to recommend things that can help real people use tech more safely.

> "the entropy of a randomly (not user!) selected password is not estimated in this manner, but calculated according to the same formula I provided: H = log_2 (b^L), where b is the number of letters in the alphabet (95) and L is the length of the password"

Yes, I'm aware of that. Using that site's check, "correct horse battery staple" comes out weaker at 104.2 bits, so I listed that weaker "lower bound"[1] for that phrase. I'm happy to use whatever formula comes up with less entropy for reasons discussed in [1].

I also don't care when sharing with less technical users if it's exact. I care if I can point them to a URL that gives a reasonable approximation, which that "quick check" does. For users who want to do math, I listed both approaches:

> 1. Quick entropy check: http://rumkin.com/tools/password/passchk.php

> 2. Manual entropy check: http://www.wolframalpha.com/input/?i=log_2%282048%5E4%29

The "manual" check is pre-filled with your suggested formula. It's interesting to compare the entropy check to http://www.passwordmeter.com which I think users will "solve" as if it were a password meter puzzle, in very predictable ways.

Meanwhile, to an attacker trying the whole character space, "correct horse battery staple" is log2(27^28) or 133.1 bits of entropy. And if you use H = log_2 (b^L) on the passphrase that Evernote wouldn't accept, it comes in at 188 bits of entropy.

In any case, the approximation is a more conservative "lower bound" than the formula you're suggesting as applied to character set ^ length.

> I personally think a password manager like keepass / lastpass / etc. is a better choice than trying to select a memorable password, though.

I agree. And I use 1Password and generate random passwords.

Btw, the two truly random passwords from 1Password (equivalent of keepass, lastpass, etc), if working with the H = log_2 (b^L) formula, give only 98 bits and 101 bits. Again in their case, the "quick entropy check" URL gives lower numbers, meaning it's a remains a reasonable "lower bound" check for casual users who don't grok formulas.

I tell non-technical family members and friends who can't be bothered with password minders to use sentences meaningful to them and unlikely to be in a book.

    This phrase is definitely not in the dictionary! : 227 bits or 286 bits
That's a pretty good password that my Mom can remember.

--

1. lower bounds: http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-i...


While "This phrase is definitely not in the dictionary" is true, every component is. If this sort of password became popular brute forcing passwords would just start using whole word combinations when cracking passwords. i.e a word becomes the equivalent of a character (though from a larger set of characters).

Also wouldn't a hash of a long passphrase be longer? (I am completely ignorant the details of hashing algorithms)... so if I'm cracking a table of hashed passwords, I could set a "passphrase" cracker on hashed passwords of above average length?


No, the hash is always the same length, a single character and a 4GB movie will generate a hash of the same length (using the same hash algorithm (md5, sha512, etc). I've casually read about it, I think that is the point of the hash, to take an input of any size or length and represent it as a fixed size.

The problem with this is hash collisions, weaknesses found in hash algorithms can make it so attackers could generate files to match another files hash (or password or w/e). I think the idea is that they create a harmful file, then add null characters or w/e so the hash algorithm will generate/assign the two different files the same hash.


The key idea behind any hashing algorithm is to take inputs of any length and turn them into an output of a fixed length.

Different problem domains have different additional requirements: password hashes want to minimise collisions (multiple inputs hashing to the same output), checksums want to make similar inputs produce wildly different outputs, hashtable/dictionary/map key hashes want to create an even distribution of outputs etc. But the thing common to all hashing algorithms is the output is the same size.


When cracking passwords attackers don't just use brute force. The most effective attacks are ones that exploit human patterns such as leet replacements, capital first letter, punctuation at the end, etc. Concatenated words in all lowercase with no spaces is another pattern that can easily be added to their list and probably already is there, so yes, you can assume that that they will be looking at the space of 2048^4 such passwords.


> The most effective attacks are ones that exploit human patterns such as leet replacements...

I think you missed my first paragraph, where I made that point:

"Normals" are using their name with a 3 instead of an E, or some word with a 1 on the end. This tends to put them in rainbow tables _or_easy_attacks_.

Also, my example passphrase that I was annoyed Evernote wouldn't let me us isn't log2(2048^4), but ~ log2(5000^8) even assuming you know it is words.

This thread is getting of on the tangent of debating XKCD's particular formula. XKCD is not the point.

My original post asked Evernote Team to please grok the idea of that cartoon, which it's obvious they had not given their clearly wrong tips and rejection of a very strong password and acceptance of one of the weakest.


I agree with you, but that's not how Randall got the entropy for the comic. His entropy numbers come from NIST SP 800-63[0], for "correct horse battery staple" spaces included. But NIST SP 800-63 has been shown to be invalid in metric for entropy, making the comic's numbers incorrect in real application.[1]

[0]: http://en.wikipedia.org/wiki/Password_strength#NIST_Special_... [1]: http://reusablesec.blogspot.com/2010/10/new-paper-on-passwor...


This assumes that it is known that the password is four random words. The security of this method hinges on the fact that that information is not known.


That's not the case, though. Even knowing the general manner in which the passphrase is constructed, if the four words are randomly selected then the best an attacker can do is to brute force the space of 2^44 possible phrases, which is difficult enough to be considered secure. The very same can be said for the seven-character random password: the best an attacker can do, knowing how the password is constructed, is to brute-force a space of about 2^46 possible passwords, which is secure enough.

And this must be true in order for passphrases to be a reasonable choice. Because if people start using passphrases commonly, then this formulation will immediately be added to password cracking toolchains along with all the other common types of password.

On the other hand, the passphrases's actual "entropy" is probably lower than the advertised 44 bits, because patterns like the appearance of an adjective ("correct") before a noun ("horse") are common enough in the English language that they, too, could be factored into a smart password cracking tool.


Exactly. In a thread about "900gage!@#" being cracked in a few hours[1], this same discussion came up. It's worth reading for those who are wondering about passphrases vs. complex passwords.

[1] http://news.ycombinator.com/item?id=4545893


This is, again, not about a random password, as moxie explains in that thread. And as he continues, with regard to the comic: "I think that's totally on the right track, but if people start to do that, chances are that they'll start to create exploitable patterns again".

Any password cracker smart enough to exploit the patterns in "900gage!@#" is also smart enough to exploit the construction of an English language passphrase. The passphrase is still secure enough (probably), but it is not more secure than the random password. And if there is any one thing to take away from that thread, it should be that it's foolish to assume the obscurity of your passphrase's formulation gives you any extra security whatsoever.


Thanks for your reply, Niten! Sorry, I didn't mean to imply that "900gage!@#" was random, but many people would (wrongly) consider it complex. Users who are not generating and storing random passwords (with KeePass or the like) may make safer password decisions when thinking in terms of a phrase rather than a "complex" word. Of course, they'd be far safer still by using a good password manager and long, truly random passwords.


Passphrases are more secure than random passwords when you factor in the human element. A 64 character passphrase is more memorable than a 64 random character string and less likely to be written on a post-it note.


Be careful -- you're starting to argue a slightly different point than what your parent made. You're not wrong, but you also haven't done anything to dismiss his claim. He's talking about a 7 character password vs a 4-word passphrase. Not equal sized, 64 character passwords.


>Disallowing spaces is particularly annoying for a company with a strong security requirement, as passphrases are simultaneously far more secure and far more memorable than the monkey rules your validation demand.

I just don't understand the logic behind some of these password rules. Wouldn't it require more effort to explicitly disallow certain characters? Like, they wrote code somewhere that is specifically making sure your password doesn't have a spaces, and other arbitrarily chosen characters.

It doesn't make sense to restrict anything in passwords other than length (and of course testing that is meets certain complexity/length requirements-- smartly). Just set your DB field to be 30 characters, accept any character, and be done with it.

There must be some logical explanation behind why companies implement these rules. And banks are the worst. Because people far more experienced than me at programming (e.g. Evernote devs) make these decisions, so there must be some reason. Is the decision a defense against SQL injection techniques? Since injections usually contain spaces. But then again, this is 2013 so you think they would use prepared statements, or something.

Madness!


My understanding is that banks have these weird rules because of the legacy systems that they interface with. I've even heard of new systems built on top of old ones by writing an interface layer on top of the green-screen UI of the old system (i.e. automating the green-screen interaction / screen scraping).


I used to have an account with New England Merchants Bank. My ATM PIN was seven digits. But I noticed that the ATM screen would flash after the first four. A little trial and error revealed that that was all I needed to enter! Comparing notes with friends (this was before the internet) revealed that this little secret was common knowledge.

Subsequently, NEMB got subsumed by successively larger banks, until, finally, Bsnk of America took over. Suddenly, my ATM card wouldn't work! It turned out that they had kept my full PIN on file through the whole chain of acquisitions, but only with B of A did they start comparing ATM PIN entry against the full PIN! My card still worked with the full PIN (which I still remembered, it being an old phone number).


Some banks have IVR systems that allow users to log in to their account via telephone, so they only allow characters that can be entered via the touch-pad.

When you first create your password they translate the characters to the numerals on the phone and then hash it.

In my experience that is the most common reason why you'll see password for policies like: "Your password must be between 6 and 20 characters and only contain upper and lower case letters."


Since you're only going to store the hashed value, there's no practical reason to limit the maximum length of the password.


"Since you're only going to store the hashed value"...

Look fellas, we've got an optimist over here!


netteller (I think was the name?), an online banking system used by many smaller banks, including the bank I used to bank at in Tennessee, used to require passwords be exactly 6 alphanumeric characters. This didn't change until just a year or two ago. Scary.


See also: Steve Gibson's "Password Haystack" https://www.grc.com/haystack.htm

  > everyone has always believed or been told that passwords
  > derived their strength from having “high entropy”. [...]
  > But [...] when the only available attack is guessing, 
  > that long-standing common wisdom is not correct!
(Practical advice for normal users seems to be Steve's raison d'etre; I would be glad to hear anyone share their concerns about his recommendations.)


seriously though, its 2013, is there any reason to enforce character sets allowed in a password? I should be able to use any kind of character i want.


I don't think UnoriginalGuy actually works for dropbox -- that first line is on the actual blog post too.


Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.(http://en.wikipedia.org/wiki/Salt_(cryptography) ))

That's great. But to really reassure people they would do best to reveal the algorithm. After all, DES-based password hashes are both 'hashed and salted' but are easily broken with JtR.


Curious, if the attacker knows what the encryption algorithm is, does it help them at all in breaking it? I.e., does it potentially delay breaking it by not revealing it?


For public service like Evernote attacker can usually create own accounts with known passwords before stealing database and then try to found algorithm and salt by brute force hashes against known password.


In theory, yes, in practice it is fairly obvious how something is hashed just by eye. Different hash algorithms produce different output (lengths, starting character, and spread).

So with some experience you can often tell (or guess and test) what something is hashed with.


I would say that's not really true. The output hash will look the same if I apply a simple salted SHA-1 with a salt or if I apply 500 MD5's followed up followed up with 200 SHA-1's, each salted differently. I'm not a security expert, but I think this is closer to best practice these days.

That said, revealing the exact algorithm would basically be throwing people with weak passwords to the wolves while really only supplying the rest of us with a false sense of security (because it will probably be cracked anyway).

We'd also be better off if they didn't announce the algorithm if the passwords get leaked (like with LinkedIn).


For practice, see if you can't identify the hashing algorithm for the following stored passwords:

    $6$AhHvI8ay$I0ED2wWVU9eheJKvCxzcbc/ZYRoN60q5XNHruYp8yFlQvEOjJ1WtIHUwjG6L4ZGntf3ei8osB7s2GYdkN01gx1
    dGhpcyBpcyBzdHVwaWQKCg==
    286755fad04869ca523320acce0dc6a4
    some_salt:ac01346ad1553221506dd091800a1974
    c8fed00eb2e87f1cee8e90ebbe870c190ac3848c
    6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4e
    /5L0cR/wpFqSA
Note how they don't look the same, so it's quite easy for an attacker to tell the difference.

Want to see how you did? Here's the answer key, in base64:

    MTogTW9kZXJuIGNyeXB0LCBsaWtlIHRoZSBraW5kIHlvdSdkIGZpbmQgaW4gL2V0Yy9zaGFkb3cK
    MjogSnVzdCBiYXNlNjRpbmcgdGhlIHJhdyBwYXNzd29yZCAoc3R1cGlkKQozOiBVbnNhbHRlZCBt
    ZDVzdW0KNDogbWQ1c3VtLCB3aXRoIHNhbHQgcHJlcGVuZGVkCjU6IFVuc2FsdGVkIHNoYTFzdW0K
    NjogVW5zYWx0ZWQgc2hhMjU2c3VtCjc6IE9sZCBVTklYIGNyeXB0KCk=


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.


No, it's usually known by the format, or even stored together with the password

Example: crypt stored the password in the format: $id$salt$encrypted


But this is why we do one or both things: strip obvious things from hashed password and store them separately or add a trivial character reshuffling algorithm. The point is that hacker would not only have to steal your hashed passwords, but also steal and understand your code. Makes it more complicated.


No

The security of your system can never depend on an attacker not knowing the implementation.

Or: Security through obscurity (is no security)

Using gimmicks like for example shuffling some characters in the hash may delay some attacks. But the problem is that these techniques are usually done on systems that have no sufficient security.

Have a big salt and use PBKDF2 or Bcrypt and you know the exact difficulty of getting the passwords.


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 instead makes it another thing to figure out by an attacker. At worse, you slow them down a bit, allowing you to do things like mass-email everybody affected.

Security is about depth, not putting 100% of your trust in a single algorithm. Even if that algorithm is well trusted. It's simply not an either/or.


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 requires far more work and far slower cracking.


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.


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 (or already has) an account, for which the password is known. So he goes and compares it trying to figure out your encryption mechanism

It's slightly more difficult than the guy that just used MD5 to hash the passwords (let's assume that's the minimum security people use - "in theory")

So, it's all fine and dandy until you have another 'increase the security' idea that actually decreases the security. And this is more common than you think.

Example: taking the hash and encrypting it (for some choices of hash and encryption)

(Not to mention when people think that because they use this 'improved security scheme' that they invented they can be lax in security elsewhere in the chain)


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.


Indeed, the assumption is that attacker has limited window of opportunity to grab the data. Taking that as a base assumption, it would make sense two store parts of the hashed password in two separate databases on two separate machines. Hacker would have to gain access to both. My initial alternative was to add some trick inside of the code, like a simple shuffling of characters. Assuming that code is not stored on the same machine as DB that should increase security considerably. But either concept would work. Of course it does not remove the need for higher degree of difficulty for hashing itself.


If you need a citable name, taking the transparency of the cryptosystem as an assumption is called Kerckhoffs's principle.


Using a big salt is essentially the same as using a secret character shuffling algorithm. The difference is that the salt value is thought to be on the 'data side' and not in the code side, so it's allowed to be secret. The distinction is pretty arbitrary, though.


If someone can steal your passwords, doesn't it follow that they'd more than likely also have stolen your code?


It's MD5 with a salt.

"Since the hashed password is never exposed outside of our data center, we don’t think that the differences between MD5 and SHA-1 are relevant. I.e. the risks for MD5 are about producing two inputs that match the same output. In the case of a purely back-end MD5 hash, any hypothetical attacker doesn’t have access to either the output (the MD5 hash) or the original input (the user’s password and our salt), so there really isn’t any productive attack based on MD5 vulnerabilities.

Of course, if someone has your original password and our salt, they might be able to come up with a SECOND synthetic password that hashes to the same value. (Since we constrain password characters that we accept, that might not be possible, but let’s assume it is…) The attacker could theoretically use this second password to access your account. But that same attacker could just use your original password, so I don’t see a real-world attack that would be improved with SHA1.

(Before Evernote, I spent five years building high-end cryptographic systems for government customers [e.g. http://www.isto.org/ose-site/file-fix/Public/corestreet-secu..., so I get to make use of my old crypto knowledge from time to time…)"

http://blog.evernote.com/tech/2011/05/17/architectural-diges...


Agreed, it would be nice to know they are using something reasonable, like bcrypt.

Their description would satisfied by a simple MD5 + salt, which wouldn't be very good for password storage.


From the Evernote support pages:

What type of encryption does Evernote Use?

If you encrypt text within a note, we derive a 64-bit RC2 key from your passphrase and use this to encrypt the text. This is the longest symmetric key length permitted by US Export restrictions without going through a complex process to gain export approval.

We do not receive any copy of the key or your passphrase, or any escrow mechanism to recover your encrypted data. I.e., if you forget your passphrase, we can't recover your data.

User authentication (i.e. username + password) is always performed over SSL when you communicate with Evernote. This uses 1024-2048 bit RSA keys and a symmetric session key that's negotiated between your client/browser and our server.

The data in user notes is also transferred via SSL.

Several of the company's founders come from a strong encryption background (founders of CoreStreet, recently acquired by ActiveIdentity). For Evernote's consumer product, the current encryption algorithms are chosen more for exportability under the Commerce Department rather than strength, since our software permits the encryption of arbitrary user data with no escrow.

We'd be interested in offering something stronger in the future when we have the staffing to fight the lengthy export battle, but Premium users can currently use an external encryption solution to encrypt important files and then add these encrypted into Evernote.


That still doesn't tell you how the password is hashed though.


Can anyone tell me why they're using RC2 and not AES? Does the export restriction even disallow that? Seems a bit disingenuous if that is the case.


Your average user has no idea what a hash nor a salt is. There's really no reason for them to include their hashing algorithm in an email like that.


Technology-savvy users want to be informed and assured as well. Why would they not include it?

Situations like these specifically call for not leaving things up to the users' imagination.

The recent Facebook incident (well, one of them) created a big scare. Better to control the narrative, before others decide to tell their version of the story.


Also the email doesn't talk about the time-frame: when exactly did Evernote discover this activity and how long might they have been compromised for.


Where 'their version' == some made up bullshit that sounds good.


It doesn't really matter what they used, as hashing speeds improve so quickly. You have to assume that the password you were using on evernote will be cracked, so to be safe you have to change it everywhere you were using it. Given that most people reuse passwords i expect a lot of follow-on exploiting of other systems with the passwords retrieved from evernote.


If this were true, there would be no reason to hash passwords.

There are hashing algorithms (bcrypt, scrypt, PBKDF2) that are specifically designed to be slow to prevent these attacks.


PBKDF2 is not memory hard, so even with known technology it can be broken relatively easy. Bcrypt seems secure for now, but you shouldn't rely on security through obscurity, which is essentially what putting faith in the irreversability of a hash is. The reality is that if a hashed password leaks, you should assume it will be broken. It's like with bank vaults. They're not designed to withstand attack, just to delay it. Well-hashed passwords delay attack, but they do not prevent it.


Hashes are mathematically proven to be irreversible except through rainbow tables (easily beaten with salting) or brute force. There's no faith needed (well, I suppose that non-mathematicians like myself have to put faith in the math, but I trust the hundreds of independent studies of these algorithms quite well), and it's not anything close to "security through obscurity".

That said, you are right. You should always change passwords that are leaked. This, however, is due to the poor security practices of most companies, not some bizarre distrust of hashes.


Brute force was exactly what i was talking about. It doesn't matter whether a hash is broken through a mathematical flaw, or through improvements in the brute forcing process, if in practice it still gets broken. Once a hash is leaked brute force becomes possible in theory, and what is possible in theory is usually possible in practice with sufficient dedication.

There have been such huge improvements in hashing through tools like hashcat and hardware implementations that i don't think it's unreasonable to distrust hashes. Once a hash is leaked you're essentially hoping that brute forcing it is too high of a cost. Given the history of order of agnitude improvements in hashing speed, i consider it unreasonable to believe that any password database remains safe indefinitely once leaked.

I find your trust in the difficulty of brute forcing a hash just as bizarre as you seem to find my distrust of hashes.


IANASE (I am not a security expert): Would the following service work:

Assume a central account/profile service. This service would allow you to have a single login to this service, with a directory of pretty much any/all sites and services online.

The external services would receive a hashed token of your account/authorization. They would check for the validity of the token each [interval|day|time-the-service-was-accessed] to determine if the token/auth is still valid.

They would also be able to tell the central service whether or not they require an updated token/auth, for circumstances just like this.

Further, form data could be stored on the central service, like mailing, shipping, billing, etc info. A log of all sites/accounts that request/require/use this information is kept.

Access to this and all other profile information can be reviewed/revoked by the user at any time.

Groups and layers of account information would be something that could alternately be added to the central service. I.E. - you could have a first level login to get to your dashboard, but additional security could be required to change various portions of your profile details (one passwd for address info, another for accounts)....

Avatar galleries would be available and you could tell each service which avatar to associate with what.


While it would work in the sense that compromising the other systems wouldn't compromise anything else. It does leave that central service as a very very very big and attractive target. It introduces a single point of failure (security wise) that lets someone compromise everyone at everything all at once. It would also make it a good target for warrants and subpoena to be sent to gather information about people without their knowledge (less of an issue, but still a concern for privacy).


[deleted]


This is not accurate. If it were, what would be the point of hashing at all?

Password hashes like scrypt, bcrypt, and PBKDF2 are specifically designed to be slow, such that breaking them takes not weeks but many years.


> Please create a new password by signing into your account on evernote.com(https://www.evernote.com/Login.action).

and

> Never click on ‘reset password’ requests in emails

Is sure to confuse a lot of people.


I didn't even get an e-mail, not even as of now March 2 14:03 AST, I saw this on HN first.


Huh. I just went to their site to reset my password, and instead of logging in I just used the standard way which sent me and email. Now I'm not so sure I should have trusted that email. Seems like they should have just emailed everyone with new passwords immediately.


I've yet to receive an email so I just went to their site.

Upon logging in with my (presumably) exposed password, I was given the option to enter a new password immediately. Their password reset should fire off an email instantly, not using a batch delivery process, with a confirmation link that then logs me into their system with a one-time key, forcing me to change my password only then.

Yes, that is marginally more complicated, but it's miles more secure. They just gave a free password reset form to whoever is sitting on their database dump for any trivial dictionary passwords they're able to bruteforce. Not doing a mass password reset would have had the same effect.

FWIW, I've also yet to receive any confirmation email that my password has been reset, another potential security problem.


Especially since if you hit "Forgot Password" you are sent an email with a big "Reset Password" button in it. A bit of poor wording.


I haven't received such an email, wonder why.

Anyway Evernotes android client wasn't very good and it was far too slow to start.

And now the have been hacked. Anybody know a good alternative?


FWIW, but this is what I use MS SkyDrive and DropBox for. Setup your notebook txt or rtf (or odt or whatever) files and get all the same sync. Save a webpage using your browser and get much of the web clipping functionality. Not exactly the same, but clients on all the platforms and also some functionality that Evernote doesn't have.


OneNote is pretty great. It uses SkyDrive, but is available for free on most mobile platforms (Iphone,Android,Win8 Phone) and any platform with a moderately up to date browser. (Via the web app on Skydrive)


Seconding that request but for a local app. I would not ever want my notes to be available to strangers under any circumstances.


What phone and Android version? Evernote was slow but usable on my Optimus V (600mhz, Android 2.1). On my Nexus 4 it's fast.


I've heard good things about pocket


catch.com incredibly simple + fast + easy to capture. no notebooks though only "spaces"


"Please create a new password by signing into your account on evernote.com"

I dunno, isn't logging into a site that has just been hacked exactly the thing I don't want to do?

For that matter, linking to a hacking announcement on a hacked site seems like a bad idea, too.


I never received this email.

I only found out about the hack because my evernote client kept on bugging me saying my password had changed.

Curious as to why I found out the cause via Twitter.

Email is way too slow for these sorts of things


Me neither - I wonder if in fact Evernote's website was hacked instead ...


> "Never use the same password on multiple sites or services"

As long as we're stuck with passwords, this is the single best practice for protecting your accounts. Services WILL be compromised, again and again, and attackers have made a pattern of compromising a poorly-secured service as a side channel to get credentials for a more critical service.

Props to Evernote - it seems like they've done the right thing with password salting and hashing and hopefully this breach won't result in actual plaintext password reveals. But every week on HN we read about another shitty web app that is storing passwords in plaintext or with weak / unsalted hashes - when those services are breached, at least you'll know that the attackers don't have a credential they can use elsewhere.


As long as we're stuck with passwords, this is the single best practice for protecting your accounts.

This would be easier if non-critical password cookies didn't expire. Why does my Slashdot or HN password cookie need to expire? Answer: it doesn't, but the fact that it does means that I have to write down dozens of different passwords... and carry them with me if I expect to use those services on a mobile basis.

Life would be a lot easier if password cookies didn't expire (or even if - gasp! - the user was given a choice in the matter). Whenever I'd find myself locked out due to the use of a different browser or platform, I'd request an email reset and keep track of the resulting new password only long enough to update all of my browsers.

If I try to use this strategy now -- and I have -- I'll spend an hour every other day doing nothing but resetting password cookies that didn't need to expire in the first place.

Christ, passwords are stupid. Somebody fix this shit.

/rant


My HN cookie is scheduled to expire in 2038.

I'm comfortable with that level of forced inconvenience.


Yeah, I wonder if I'm blaming the HN case on a Safari oddity. It never seems to expire on my desktop PC running Firefox, yet I have to log in almost every time I access HN on my iPhone.


And if you specifically mouse over the links contained in the email received, the domain looks like it could even be a phishing scam:

e.g.:http://links.evernote.mkt5371.com/ctt?other_params_removed

I just went straight to the site instead of following the email links in order to confirm the legitimacy of this mail.


> Even though this information was accessed, the passwords stored by Evernote are protected by one-way encryption. (In technical terms, they are hashed and salted.

Were the attackers ables to access the salt ?


Of course, every password should have a large individual salt to prevent rainbow tables.

A hidden salt that is used across all passwords is useless on a public service, because that becomes the password to hack.

The attacker takes an account that has a known password and brute forces the salt from that.

Salt and hash are good for protecting well chosen passwords, but because the speed they can be processed mean the hacker can try billions of different passwords a second. These days choosing a cryptographically hard (memory hard) is the best bet to extend the time from a breach to password discovery so the majority of the users can change their password.


Most implementations store the salt with the hash itself. Take Django's storage of "password" for example:

    pbkdf2_sha256$10000$rdfyoPhMNhnC$3QEJ9hp0Qe68/p8+b1tVsYmNqVHiFrhmpWizXq+xQoo=
Which of course stores it as:

    algo $ iterations $ salt $ hash
Salts simply protect against rainbow tables and force CPU cycles to be re-spent on each password individually.

But to answer your question: I'm not sure, but probably.


"One-way encryption" is a peculiar choice of phrase.


No, it is an accurate choice of phase. The passwords are "hashed" which is literally one-way encryption, since the encryption is lossy - the information to reverse it literally doesn't exist in the output.

The only way to "break" correctly working hashes is to encrypt tons of passwords (+salt) and see if the lossy output is identical to the output you got from the previously hashed password.

Which is a very time consuming and computably expensive process (in particular when using something newer/better than MD5/3DES).


If the output is lossy and doesn't contain all the info needed to reverse it, is it possible to guaranteeing that each each output is unique? Or could two different inputs theoretically create the same lossy output?


Each output is NOT unique. Since it can take in an almost unlimited amount of data and output a set length string we know for a fact collisions will eventually occur.

The question is - can we predict these collisions or guestimate when they might occur without having to actually try every combination? If the answer is "yes" then the hashing algorithm is broken (see MD5).


It depends on your hashing function. What you're talking about is a https://en.wikipedia.org/wiki/Collision_(computer_science)


"hashed and salted" is not necessarily time consuming, it really matters what process they used. Their post gives no confidence that the passwords cannot be trivially cracked.


People are going to argue with you semantically, but you'll all generally be in agreement (except 3DES is a block cipher, not a hash function).


3DES is a black cipher but block ciphers can be used for hashing. 3DES in particular was used on UNIX/Linux based systems quite extensively.

http://www.freebsd.org/doc/handbook/crypt.html

See this: http://en.wikipedia.org/wiki/One-way_compression_function#Co...


Yeah, in retrospect I should have realized that (especially with bcrypt, also made from a block cipher, being the current standard for password storage). I didn't know DES was actually used for hashing though (perhaps unfortunately revealing my younger age and naiveté :)


All cryptography is fundamentally transposition and substitution of "symbols" (across a combinatoric space, an "alphabet"). Hash functions can be made from block ciphers, but really, symmetric and asymmetric crypto is just moving around some letters, but in interesting, deterministic ways.


It's easier to understand by lay persons than hashing.


Meh, it's a PR person who probably had it explained 10 minutes before. They explicitly state that they are hashed and salted, so I'm not super concerned.


Someone should write a boilerplate "we've been hacked" blog post with parameters for the kind of hashing and factors of authentication used, and what they know - or don't know - was compromised.

I can't blame companies for not having one such on hand to begin with, but I'm sure they'd appreciate that someone with the unfortunate experience crafted a draft for them in stressful times like these.


Depending on how they're hashed, that may or may not be an effective countermeasure.


[deleted]


An oxymoron is two words which mean the opposite but yet the two combined words form a new expression which remains "true."

For example "bitter sweet." Bitter and sweet mean two different opposite things, but the two words together are "true" because something can be both bitter and sweet.

Encryption means simply to convert information into a form which cannot be easily read by an unauthorised party. One way or lossy encryption is not a contradiction of that.


Encryption implies that an authorized party can also decrypt/read the encrypted data. In that sense, "one way" + "encryption" is an oxymoron.

Further, "one way encryption" appears to only exist so nobody has to explain to regular users (and a lot of developers apparently) what is actually being done with their passwords.


"One way encryption" == hashing. Maybe not the best term, but it's pretty obvious what they mean.


How is it an oxymoron?


It goes to efficient write-only memory.

Or the author is not qualified to do security, or thinks readers are ignorant.


> we have found no evidence that any of the content you store in Evernote was accessed

This depends on how hard they looked - do people believe content wasn't accessed?

Is it fair to ask them for a technical post about why they don't think content was hacked? I'd love to know how they separate auth from content, and how they ensure that a hacked auth node can't view notes


"Please create a new password by signing into your account on evernote.com(https://www.evernote.com/Login.action). After signing in, you will be prompted to enter your new password."

Why couldn't an attacker do that at this point?


Blog was down. Google cache of blog post: http://webcache.googleusercontent.com/search?q=cache:http://...


Frustrating, I thought they would have done security better than most given the type of information stored here.

Does anyone know a decent password keeper? I have a list of logins/passwords for my key sites in a word .doc file stored locally, but given I have a work mac, home mac, tablet and iPhone it really is a pain to access the locally stored file.

I thought about saving this file on google drive, but their 2-factor auth doesn't seem to apply for drive (only gmail).

How do others do this - is there a way to store an encrypted file somewhere online, then typing in a known password to unencrypt / open it when I need to access it?


LastPass offers everything that you're mentioning, plus 2-factor auth that integrates with the Google Authenticator app if you want. It's free if you use it on desktop with browser extensions, but costs $1/month for mobile. I would highly recommend checking it out.

www.lastpass.com


>I thought about saving this file on google drive, but their 2-factor auth doesn't seem to apply for drive (only gmail).

Huh? All of Google's logins are through their single-sign-on. TFA protects everything.

Also, please, just use LastPass. I don't know why everyone has it in their head that password managers are a hassle. It's literally easier than using the same password for everything AND more secure.


whew, i was shocked when my evernote client asked me to enter my password because i did not recieve the e-mail. It seems like this was a precautious step as nothing was 'really' hacked, or was it?


Their blog is down now, but they did say that attacker had access to usernames and encrypted password but nothing else.


So the content within the accounts was safe then?


And email


i didn't get the email, and my original password still works, it just took me directly to change password screen.

i guess they're counting on compromised passwords not being used individually to create new ones?


according to bbc "It said user names, email addresses and encrypted passwords were accessed"

so i guess since passwords were encrypted they weren't fully compromised and a simple change should be enough.. at least that's what Evernote appears to think.

http://www.bbc.co.uk/news/technology-21644317


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)


Good they're being proactive here, but two things:

1) I'm sick of going through this password reset crap every month or so. Please lets get rid of passwords.

2) Could Evernote please look at some sort of oauth based signin for mobile devices? I have to enter this unique and very long password multiple times on every device I own.

It'd be nice if my linked phone and tablet didn't need me to use the same login system as a human.


I filed a ticket this morning after I was unable to login to the Mac client. Here's their response:

"Dear Valued Customer,

We're truly sorry for the inconvenience this has caused you this morning. We are attempting to contact our entire userbase about this matter, but we feel that immediate action in these cases is the most prudent course."

The rest of the email contained the contents of their blog post.


Funny enough, logging in to Evernote was the first thing I did after laying in bed spending 1hr+ watching this amazing video about http/https man-in-the-middle attacks using sslstrip http://www.thoughtcrime.org/software/sslstrip/ . Not a good way to start my morning.


They've never really been focused on security in the past. Honestly, I love the service, but their lack of concern about keeping it secure has never sat well with me.

I wrote up a post with some of my security concerns. http://news.ycombinator.com/item?id=5311010


I got the email and reset my password (web browser on desktop). I then launched the MaxOs client app and it asked me to enter the new password, however the iOS app shows its initial loading screen but then just crashes. It never gets around to asking me for the new password. Anyone know a solution to this?


An updated iOS app is available since yesterday. After updating I was able to enter the new password and am back up and running.


I'm wondering how they perform the password reset.

Surely, you must know more than the username. But they cannot rely on the old password either, because the whole thing was set off by assuming that the old password is hacked. And they advise their user to ignore instructions per email.

So how do / could they do it?


It contradicts their instructions, but I'm assuming using the password-reset received email immediately following my request for this email is the "right" way to do this. I believe the intent of what they warned against were common phishing emails .


I didn't get an email (yet) so I visited the Evernote Forum. I was a bit surprised to see that I had to sign in with the same username and password of my Evernote account. It's convenient, but I prefer seperate accounts, especially since they're using third-party forum software.


And following the announcement, the blog it's down and emails didn't arrived yet. Well done, Evernote.


Anybody considered the zendesk link http://m.techcrunch.com/2013/01/08/zendesk-evernote-25k/

Twitter, tumblr, Pinterest hacks are all having zendesk connection

People on Dropbox have issues too


I just got an email from "Evernote" with links pointing to http://links.evernote.mkt5371.com/

Please, be very careful, people. Of course, this won't reach the people who need to hear it :(


For anyone who is as puzzled as I was about how to change the password in the Android app, the answer is you can't change it in the app. (!)

Instead, you have to tap the "authentication failed" notification. Then you can change the password.


Yeah apparently they will deploy updated versions of the apps to address that issue though. (It says so at the bottom of the article.)


I finally made the switch to randomly-generated passwords for everything, so for once I can finally not care at all that this happened. It's just a reminder that I need to close my Evernote account.


Not cool. I use evernote for throwaway email passwords. And storing some usernames, without passwords. Just to remember usernames.

I wouldn't lose anything, it would be just inconvenient for me.


Maybe use a more appropriate tool? That would be your life way easier anyway? LastPass? 1Pass, etc?


I don't understand why they don't offer encryption.


Encryption on /what/? Point to point or content encryption? Also if your password has been compromised and that same password is used to encrypt your data then what exactly would encryption do?


Data encryption with a private key that the user holds. Evernote, like Dropbox, etc. have your crypto keys, and thus will always be subject to hacking and such. If I, and only I, had the keys it would be up to me to keep them safe, and my data would not succumb to a hack of their database, etc.


But password resets would quite literally be impossible.


Encryption on the notes. Who would ever promote using the evernote login to encrypt?!


Passwords are typically not used for encryption, since you don't want to re-encrypt data when user changes the password.


Yes they are, just in a more complicated way. You don't have to re-encrypt if the user changes their password. FDE would be pretty useless if so.


You can encrypt notes.


How do you encrypt a complete note? AFAIK the official Evernote client only allows encrypting text content within a note.


Yes, as far as I know that's all you can do. I wish you could do pictures as well:-\


Why not share more about the hack detail? Is it another attack from China? As a (paid) user, I'm a bit concerned about my data security.


And another example of how badly Wordpress scales.


I am impressed by how well this is handled. Much better than I've seen from other companies!


Anyone know a good Skitch replacement?


You can actually download Skitch 1.XX here: http://update.skitch.com/skitch.html I have been using it since they completely messed up Skitch with the 2.XX update. It requires absolutely no connection to evernote and works great.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: