engberg

No problem, sorry for the disruption! We have to enable an SMS fallback option even for people who use Google Authenticator (like I do), since it's too common for the authenticator app to get lost or broken. So the SMS routing is the second line of defense. I know people who have had two-step attacked on other services by people who socially engineer a retail phone company employee, so I was worried about relying on that as the last line of defense. I hope this doesn't happen again, but if it does, we'll consider whether there's a less disruptive option for our two-step users to stay safe.

Fuzzy76 - We discussed this internally to try to decide the right solution for the people whose passwords were matched but protected by two-step verification. Since we knew for sure that the bad guys had a copy of your password, we felt that we definitely needed to notify you (so you could change that password everywhere you've used it). Once your password was compromised, your account was basically in a state of ONE step verification for those attackers ... e.g. if they could get your phone company to switch your SMS delivery to them, they could get in the account. So it seemed like the right thing to do for your security was to expire your password so that you'd get back into a real two-step security configuration as soon as possible. We knew that would be a little annoying and inconvenient, but we felt like it was the right thing to do to protect your data.

flamingFusion - The attackers did not appear to look at the contents of the vast majority of accounts they accessed. It appeared they were just confirming which passwords "worked" and which didn't. But you should definitely think of any other Internet services that use the same password that you used on Evernote. Those are all vulnerable, and you should change them all. (For example, if you used the same password for a social network and your bank, then the password may have been stolen from one of those and could let the attackers into the other one.)

righteousdork - That's a good point. We confirmed that 121 of the accounts which were attacked were successfully blocked because those users had two-step verification enabled. I.e. the bad guys matched the stolen password against the accounts, but then they hit the second-factor code and were blocked. None of those accounts were fully accessed. (We reset the passwords for those users anyway, and sent them an email, since it was likely their password was vulnerable elsewhere.)

David Harvey - Your account was accessed from a web browser on December 30th from an IP address that attempted to log into a huge number of accounts on that date, failing on most attempts.

jakkuchan - We looked at the activity that was sent by the abusers with their stolen credentials. In virtually all cases, there was nothing beyond the login attempt. I.e. they just confirmed whether the stolen username+password pair worked against an Evernote account and then moved on within a second. It's hard to guess the attackers' motivations, but it seems they were using extremely long lists of credentials stolen from another site (or phished from users of another service), and were only bothering to just confirm what other sites matched those credentials.

chocohalic - I checked and don't see that account (chocohalic) on the list that was reset. My best guess is that there may be a different account with a different email address that also routes to you, and you got the notification for that other account. If you open a Support ticket and identify the exact email address that received the notification email, we could confirm what that email corresponds to.

Hi, JaneDoes - Our client applications (e.g. Evernote for iPhone, Evernote for Mac, etc.) are written so they are capable of being used against either the evernote.com service or the yinxiang.com service. Once you're signed in to evernote.com, the application "knows" that you're an Evernote user and should never communicate to the yinxiang.com service. Before you log in (e.g. on a new install), the software reaches out to get some basic configuration information about the different services. This just sends the service a request that says something like "My preferred language is US English". The client gets information about the service, including the correct URL to open Support tickets for that service, whether Twitter posting is enabled, etc.: https://dev.evernote.com/doc/reference/UserStore.html#Fn_UserStore_getBootstrapInfo So that doesn't send any personal identifying information or data, it just retrieves the canned configuration information for the service in question based solely on your OS language preference. Under normal circumstances, most clients will just get all of this information from servers on evernote.com unless your OS language is set to "Simplified Chinese". But if your client can't get information about the yinxiang service from evernote.com for some reason, it may go directly to the source to ask about the configuration settings for the China service. You happened to hit this on Thursday morning, when you launched the Mac client (with no account signed in yet) at the same time we were having a 30-minute service interruption (see http://status.evernote.com/). So your client tried to learn about both services from evernote.com, the servers were unable to reply and the client decided to do a one-time lookup for the yinxiang.com configuration information by asking yinxiang.com servers directly. Now that you've signed in to the client, you should see that the Evernote application never tries to connect to yinxiang.com again. (I've been running Little Snitch on my MacBook for at least a year, and have never seen it.) One thing to note about Evernote and Little Snitch ... most of the time, our application only talks to our own servers. But web clips can sometimes throw that off if you manage to clip a web page that includes a reference to the original image on a remote web server instead of copying and storing the image inside your Evernote account itself. In this case, you may see your client go make a network request to that remote web server to retrieve the image when you view the note. We try to avoid this in our own software by fetching and storing the images at the time of the clipping, but that can occasionally go awry if we don't have permissions to download the image at the time of the clip, or if the HTML snippet is inserted into a note from a third-party application that doesn't do the right gyrations. Thanks, Dave

My pleasure! There's a bit too much on this thread to try to wade in point-by-point on page 9, but I want to make sure everyone knows that we do hear your concerns and take them seriously. While we have a great team who works hard to balance the needs of our 100+ million users, we obviously screw up from time to time and introduce bugs or make UI changes that make some tasks harder (while trying to improve others). We'll keep working to get things right, and the feedback from the forum and from Support tickets is a huge part of that. But we do feel that our top responsibility is to be the best custodians of your life's work. Above all else, we want to make sure your data is protected. Hopefully, this will let you trust us to keep managing the things you write and collect. But we also feel extremely strongly that it's your right to take your information elsewhere if we should ever lose your trust: http://blog.evernote.com/blog/2014/06/03/evernotes-three-laws-data-protection-update/ Thanks

Illustrious - I spent a couple of hours researching your ticket yesterday and this morning to help Terry answer your questions. We take allegations of security risks extremely seriously. While I understand your frustrations, I'm positive that Evernote did not disclose anything from or add anything to your account without your consent (or the consent of someone logged into your account using the web browser on your computer). In both of the cases you mention in June, someone on your computer chose to authorize those third party web services to create notes within your Evernote account. Shortly after each of these authorizations, those services took non-Evernote data and used it to create notes and notebooks in your account. None of your notes were accessed by those services, and none of the data they put into your account came from other Evernote accounts. I say that this came from your own computer because I went through our logs to confirm that the same IP address had been used in surrounding days to access your account from your client, web clipper, and web browser. And the web browsers used in surrounding days was identical (in "User-Agent") to the one that authorized Springpad import to Evernote. Since you deleted the notes that Springpad imported from your account, and since their service is no longer available, I can't rule out the possibility that they pushed notes from the wrong Springpad account into Evernote after your browser granted them access. But it's also possible that the content came from the right authenticated Springpad account. (We heard no other reports of incorrect behavior from any of the people who did the same import.) However, I absolutely agree with your general recommendation that Evernote users should choose carefully which third-party applications they permit to access to their Evernote accounts, just like you should choose carefully what applications should have permission to read your email or access your banking web site. We try to help with this decision by enumerating exactly which capabilities you're granting each application. I.e. some applications have permissions to read your notes, others do not. We encourage developers to request only the permissions they absolutely need, and we've added some safety features (e.g. "Note History") to protect against accidental note damage from third party applications. And we will, of course, terminate the access of any applications that are actually mishandling the data of the Evernote users who have granted them access.

We sent each person an email that identified what information was potentially stolen. (There were four permutations of "with/without password hash" and "with/without DoB") So if the email you received about the breach included the phrase "date of birth", then your account had some sort of DoB on file. (I.e. you used the date picker in the UI at some point.) Only 2% of all accounts did that. We don't know that the attackers actually took the DoB information, but we are notifying users to be as transparent as possible. If the stolen database table included your old (2011) hashed password, then the email you received would have included this line:

erink - If you received an email about having a 2011 forum password, you don't need to change or remove your password on any Evernote site. The passwords have already been purged from the discussion.evernote.com vendor's database. So there's nothing to change there. Your 2011 forum password shouldn't be usable to log into Evernote itself. If your forum password in 2011 was the same as your evernote.com login password, then that password cannot still be used to log in to Evernote. (You either changed your Evernote password to something else last March, or else we invalidated it automatically because you didn't change it within 90 days.) So the only thing you would need to do would be change your password on other web sites if you used the same old password somewhere else important (and you didn't already change those last March).

I wanted to give a bit more specific information about the sequence of events here to hopefully make it more clear what happened. From around 2006 to 2011, Evernote ran discussion forums at forums.evernote.com on one of our own boxes using open-source software called PhpBB. This was a completely standalone server with no integration to Evernote accounts, so anyone who wanted to post had to register for a separate "forums.evernote.com" account. You could choose whatever password you liked for that PhpBB server, although I'd assume a lot of people just chose the same password they used to log in to Evernote itself. PhpBB stored an MD5 hashed representation of your chosen password. This forum software was a frequent target of spammers, scammers, and hackers, so it was a constant game of cat-and-mouse to keep it clean, secure, and fast. In 2011, we decided it was better to move our discussion forums to a company that runs forums for a living, so that they could do a better job with stability and anti-spam. As part of that process, we said that we wanted to remove all password logins from our forums, so that you wouldn't need to create a separate account and we wouldn't have to worry about losing passwords if there was a breach. This "Single Sign On" (SSO) requirement means that you log in to the secure Evernote service, and then we just tell the forum who you are. We met with several vendors and decided on one that was running forums for other large brands who was able to implement proper SSO. In order to preserve all of the old posts (and posters), we did a one-time transfer of the PhpBB database to load it into the new service. This went smoothly, and we were able to flip the switch over to the new discussion.evernote.com in October 2011. Both existing users and new users no longer had to "sign in" to the forum software with a password. Authentication went through SSO on evernote.com, and the forums never touched passwords for registration or login. Unfortunately, we did not realize that there were two specific problems in the integration we performed with the hosting provider: When the vendor imported the old PhpBB database, they stored the "hashed" passwords for the (~40k) accounts that were imported. These passwords were never used by the new forums, so they were just vestigial records that should have been purged. These passwords were frozen in time from the old database.The new forum software allowed people to type various pieces of personal information (like Date of Birth) into their forum profiles. This is just part of the defaults for the software, but we now realize there was no reason to leave this ability enabled.After 2.5 years had passed, some attackers compromised the hosted forum database and pulled out the list of email addresses and passwords from the database. For the 75% of people who first posted after October 2011, their record in the stolen database table included an email address and completely bogus "password" placeholder. People who created accounts on the old PhpBB forums also had a hashed password from that forum in the stolen data. That password can't be used to log in to anything run by the Evernote company, so would only be relevant if it happens to be used on some other important web service. People who typed a date-of-birth into their discussion.evernote.com profile may also have had that leaked along with their email address. We don't know for sure, but we told people who had a DoB on file just in case. When we were informed of the breach, we worked with the vendor to determine which information was lost from which forum contributors so that we could directly inform every affected user. Then we asked the vendor to fix the two problems (above) by deleting all of the ancient PhpBB passwords and any stored dates-of-birth. To be clear: even though this immediate security breach occurred on a server managed by another company, Evernote is absolutely responsible for the problem. Even the disclosure of an email address is a mistake that we need to disclose to our users and prevent in the future. - Dave Engberg CTO, Evernote

There's no easy way to create a note via an "evernote:" URL. We've done a little bit of work using the iOS pasteboard to send native data types to Evernote, but this is not part of our supported API, and won't be a good solution for most developers. In general, we'd recommend either using the full API to talk to the service, or else if you only need to create notes, you could allow users to specify their "incoming email address" and then send notes to their account via email.