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.

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.

That's correct. Searching is always done over either the entire account ("all notebooks") or within a particular notebook, and this is reflected in the way that the UI presents the search results on the client. Since notebooks are modal (single-selection) in our UI, our search grammar matches that for consistency.

Aw, shucks. My day job trying to keep up with the growth of the service has been eating up a bit too much time lately. It turns out that when you're running hundreds of servers, there are lots of obscure ways that things can go wrong... We're still hiring like crazy, however. We had four people start on Monday alone, including another senior sysadmin. I know that Phil is recruiting for a "community" person who will be able to spend more time with the forum and other such channels. Mmmmm soup.

Or do it yourself on the Settings page of your account: https://www.evernote.com/User.action