Jump to content

Two step authentication (e.g. via Google authenticator) and encryption


Recommended Posts

  • Level 5

If you're locked out of your Evernote account, you won't be able to get to it, eh? :)

 

Kind of like if someone stores their password manager data in a cloud & they don't remember the password to get to it to restore it.  :o  

That can happen but I don't get why.

When you can give up remembering and typing all your other passwords an only have one to remember, and you use it everyday, how it's possible to forget.

And with two factor authentication it doesn't have to even be that horrendously difficult password (or need to be changed frequently).

Link to comment
  • Replies 443
  • Created
  • Last Reply
  • Level 5*

If you're locked out of your Evernote account, you won't be able to get to it, eh? :)

 

You could always create a second account ;)

Actually, I do have a 2nd non-premium account.

 

I am not worried of being locked out. I have it on the web, my local Windows client, Windows Phone, iPhone and iPad. I'd imagine the confluence of events to make all of those inaccessable at once would be so bad, I wouldn't care about my Evernote account.

 

But, I decided on LastPass. And with a touch of irony, Google Keep as a secondary backup.  :D My Google account is 2FA protected too.

Link to comment
  • Level 5*

If you're locked out of your Evernote account, you won't be able to get to it, eh? :)

 

You could always create a second account ;)

Don't forget to set up 2fa for that as well! Oh, and a third account... Agghhh, I've gone down the rabbit hole. The LastPass suggestion is excellent. I wouldn't store passwords in your Evernote account at all unless they are throwaway ones.

Link to comment
  • Level 5*

Minor glitch. For grins I signed out of Skitch and back in on my iPhone. I got 2 (two, dos, deux) codes. It was actually the same code, but came from two phone numbers - the 0034 and 0498 number.

Link to comment

Minor glitch. For grins I signed out of Skitch and back in on my iPhone. I got 2 (two, dos, deux) codes. It was actually the same code, but came from two phone numbers - the 0034 and 0498 number.

 

Did you set up...two numbers? 

 

(EDIT: wait, are you talking about the same code from two different numbers?  The verification codes will come from a bunch of different phone numbers. It's not always the same number.)

Link to comment
  • Level 5*

Minor glitch. For grins I signed out of Skitch and back in on my iPhone. I got 2 (two, dos, deux) codes. It was actually the same code, but came from two phone numbers - the 0034 and 0498 number.

 

Did you set up...two numbers? 

 

(EDIT: wait, are you talking about the same code from two different numbers?  The verification codes will come from a bunch of different phone numbers. It's not always the same number.)

Same code from 2 numbers. I only set up 1 phone number in my settings. Your system just sent the same code to my phone from two different sources. Didn't present a problem for me, just thought you should know your system is belting out duplicates. I have unlimited texts, so don't care,but some people, and some countries, don't.

Link to comment
  • Level 5*

I have to say, this was very well thought out. Very feature rich, at least on par with Google's 2fa, which has best in class IMHO. Google authentication supported, multiple phones, app specific passwords, offline recovery, etc.

 

Top notch. 

Link to comment

Thanks for the report.  We'll see if we can chase down why a duplicate text would have been sent, I've already reported it.

 

Thanks for the kind words, too.  We've been working quite hard at it, and didn't want to release until we definitely got it right, because there's a lot riding on a well functioning Two Step system.  The Premium/Business rollout is also part of that staged process--from a support and volume perspective, we want to make sure things are working smoothly, and that gives us a smaller cohort to work with.

 

Just in case the keyfobs/hardware tokens come up, those will not presently be supported, because the system we're using (industry standard, time based one time password) doesn't work with hardware tokens.  Google Authenticator (or any other app that handles generation of TOTP) is supported, however.

Link to comment
  • Level 5*

Just in case the keyfobs/hardware tokens come up, those will not presently be supported, because the system we're using (industry standard, time based one time password) doesn't work with hardware tokens.  Google Authenticator (or any other app that handles generation of TOTP) is supported, however.

Yup. Already several asking for Yubikey in the comments to this morning's blog report. Always room for improvement, but it looks like you nailed what 99.999% of people can currently work with.

Link to comment

OK looks good.... BUT stupid question.

 

If I turn on 2fa will I be able to issue an application password so I can continue to use EN version 4.4.0 on IOS?

 

Not a dumb question.  It should work.  Holler back here if it doesn't.

Link to comment

OK looks good.... BUT stupid question.

 

If I turn on 2fa will I be able to issue an application password so I can continue to use EN version 4.4.0 on IOS?

 

Not a dumb question.  It should work.  Holler back here if it doesn't.

 

Works. Very polished, what I hoped for, but didn't expect!

 

Well done.  :)

Link to comment
  • Level 5*

2 quick issues:

 

  1. It is a bit much to require 2fa authentication to open a support ticket IMHO.
  2. When I did log into the browser, it only offered to "remember this computer for 30 days." It is my browser. It should never ask again (until I clear cookies or something), but minimally it should remember it for a year. I hope I am not going to have to log in and get a code every 30 days.
Link to comment

2 quick issues:

 

  1. It is a bit much to require 2fa authentication to open a support ticket IMHO.
  2. When I did log into the browser, it only offered to "remember this computer for 30 days." It is my browser. It should never ask again (until I clear cookies or something), but minimally it should remember it for a year. I hope I am not going to have to log in and get a code every 30 days.

1 LOL

2 I think this is expected behaviour, probably waste 5 minutes a year though! :)

Link to comment
  • 2 weeks later...
  • Level 5

 

2 quick issues:

 

  1. It is a bit much to require 2fa authentication to open a support ticket IMHO.
  2. When I did log into the browser, it only offered to "remember this computer for 30 days." It is my browser. It should never ask again (until I clear cookies or something), but minimally it should remember it for a year. I hope I am not going to have to log in and get a code every 30 days.

 

1.  I'm not sure about that.  I'd want to know that it's much more difficult for someone to spoof me in a support ticket and reset a password.  Plus some percent of the user base will use a simple to type password, perhaps re-used, feeling secure with 2fa.  If the support ticket system didn't use the 2fa, then their use of 2fa makes it easier than before to potentially have a fraudulent account change request.

 

but I do get your point that there's a difference between an account change support ticket, and a feature request support ticket.

I'm sort of in the camp of in for a penny in for a pound though.  If you're going to authenticate (stringently asserting a particular identity) at all, then you may as well authenticate usefully.  A user name and password just can't do that.

 

2.  Google after some time, added a check box to trust the device rather than keep prompting every 30 days.  So maybe that's something to come later.  

I'm more comfortable with the 30 days.  In my use case, I have EN clients on my work and home desktops, plus a client in a profile on my wife's macbook, and one on the imac at the cabin.  The point being, there are some distributed infrequently used clients.  And I don't have direct control of them like I do my primary devices.  I may not know when and if they've been compromised, or lost, in a timely fashion.  Particularly on those, if I haven't used them in 30 days, I do in fact want a two factor challenge to pop up rather than unrestricted use, to anyone who may have obtained access.

Link to comment

The point being, there are some distributed infrequently used clients.  And I don't have direct control of them like I do my primary devices.  I may not know when and if they've been compromised, or lost, in a timely fashion.  Particularly on those, if I haven't used them in 30 days, I do in fact want a two factor challenge to pop up rather than unrestricted use, to anyone who may have obtained access.

 

Yup.  And with such a distributed set of apps, ideally the added application and access history tabs in your settings should allow for more control and transparency into the activity of your distributed devices.

Link to comment
  • Level 5

From the UI/functionality side, I'll add to the nod of complete and well done.  Check marks and gold stars all the way down.

 

gbarry, can I be so bold as to inquire if the parts we can't see are also getting the benefit attention to detail?

I'm wondering if the TOTP key strings for each account are secured sufficiently that they can't be lifted in similar fashion as a stored password hash?  And/or the in situ protection has been fortified since the hack?

Link to comment
  • Level 5*

 

2 quick issues:

  • It is a bit much to require 2fa authentication to open a support ticket IMHO.
  • When I did log into the browser, it only offered to "remember this computer for 30 days." It is my browser. It should never ask again (until I clear cookies or something), but minimally it should remember it for a year. I hope I am not going to have to log in and get a code every 30 days.
1.  I'm not sure about that.  I'd want to know that it's much more difficult for someone to spoof me in a support ticket and reset a password.  Plus some percent of the user base will use a simple to type password, perhaps re-used, feeling secure with 2fa.  If the support ticket system didn't use the 2fa, then their use of 2fa makes it easier than before to make an account change.

 

but I do get your point that there's a difference between an account change support ticket, and a feature request support ticket.

I'm sort of in the camp of in for a penny in for a pound though.  If you're going to authenticate at all, then you may as well authenticate usefully.  A user name and password just can't do that.

 

Wouldn't matter. If I have 2fa enabled, they can change my password all day long and they still cannot get in. If I don't have 2fa enabled, then I woudln't have 2fa authentication to the support desk. I have 2FA on a number of systems, and EN is the first I've seen to require it to open a support ticket, and password resets are handled automatically anyway, not by contacting support.

2.  Google after some time, added a check box to trust the device rather than keep prompting every 30 days.  So maybe that's something to come later.  

I'm more comfortable with the 30 days.  In my use case, I have EN clients on my work and home desktops, plus a client in a profile on my wife's macbook, and one on the imac at the cabin.  The point being, there are some distributed infrequently used clients.  And I don't have direct control of them like I do my primary devices.  I may not know when and if they've been compromised, or lost, in a timely fashion.  Particularly on those, if I haven't used them in 30 days, I do in fact want a two factor challenge to pop up rather than unrestricted use, to anyone who may have obtained access.

If you are telling EN to trust devices you don't have control over, that is your decision.

Like any system, if you make it so hard to keep secure, people just stop using the extra security features. A great security measure would passwords that needed to be 30-60 chars in length and changed every 24hrs. No one would use it though. If I have to tell en to trust my ipad (regular and beta client, plus Skitch), iphone (regular and beta client, plus Skitch, Food and Hello), computer at home, computer at work (plus skitch) every 30 days, I may disable 2fa. THat is 11 clients by my count, so I'd be doing 2fa every 3 days on average.

Link to comment
  • Level 5

1.  My assumption is that once you've convinced support that you're the owner of an account (legitimately or fraudulently), the master key has been obtained, 2fa or no.  Look at the Mat Honan debacle.  The difficulty support has is rebuffing clever social engineering.  Being as helpful as possible to the rightful account owner, while also resolute and unbreachable to a fraudster.

Their hands are hopelessly tied behind their backs in most cases to make a value judgement of friend or foe.

2fa moves the goal posts a long way to that end.

 

2.  That is true that you can secure the usability right out of a product.  There is a cost to using security, though not as costly as not using it. Is once a month really that frequent though?  I think there's also some learning curve value of nudging the user base into actually using the 2factor for a bit, rather than simply turning it on, logging in once, and forgetting it's there.  If nothing else, EN doesn't then get much consumer satisfaction payoff.  But I can see for those users with one machine they use every day, there's some value to a trusted PC checkbox.  On the other hand, that user, statistically may be more likely to be less savy about knowing how and when to revoke trust.  Automatic expiry of trust tokens works to save those users from themselves, though they'll never know that they need it, or are in fact benefiting from it all along through thwarted breach attempts.

 

For me, I enjoy pulling out a yubikey or Google authenticator when I log in.  It's my virtual middle finger swung round in a full 360 for all script kiddies and brute force bots to see, each time I log in. (for context, I perhaps spend more time in server logs and firewall reports than others, and perhaps have a heightened sense of awareness of their pervasive presence).  A 2 factor f art in their general direction, so to speak.

 

So for those services that enable things like strong encryption, and usefully secure authentication, they get a payoff of customer satisfaction, when there's a warm fuzzy moment on login.

 

For those blissfully in denial, having never been hacked, or without much buy-in (information/life hording) on evernote and are in the camp of "what do I care if someone reads my evernote stuff", then those people will just not ever turn on the two factor, and never be annoyed.

 

Many of those who turn it on, are in full on "Bring it!" context.

30 days seems luxurious, when most of my other authentications are 24 hours or each and every time.

 

On the mobile clients, are you sure you'll see that 30 day burden?

I haven't sussed that info yet.  But what I've observed is that none of my 16 EN ipad/iphone apps required any re-authentication when I turned 2factor on, except Egretlist (Evernote hasn't updated that for OAuth) for which I supplied an Application Password to resolve.

 

My guess would be that you'd only provide 2 factor authentication in a mobile client when logging into an account.  That provides you with an OAuth Token.  The token is then what is used for authentication, and that expires in a year, not 30 days.

 

Have you seen evidence to the contrary EdH?

Link to comment

The rationale here is: if Two Step is turned on for an account, you will need to use it for all aspects of Evernote, including support.

 

If you don't have access to your Two Step codes, contacting Support wouldn't help because we cannot assist you in Support anyway, as we cannot give you your codes back nor get you into your account. (This is spelled out pretty clearly during the sign up process, and in the Knowledge Base on the subject.)

 

All validation with Two Step  is in the user's hands, not Support. Thus there is no chance for mistaken identity on our end.

 

It's very similar to encryption - if you lose your encryption key, we cannot get it back for you.

Link to comment
  • Level 5*

The rationale here is: if Two Step is turned on for an account, you will need to use it for all aspects of Evernote, including support.

then can you consider adding a "support" link to the Evernote web menu? Having Support links outside of your account and requiring separate 2fa authentication is overkill IMHO. And we should be able to open support tickets right from our EN Web account anyway. That is how most other companies do it.

Link to comment

 

The rationale here is: if Two Step is turned on for an account, you will need to use it for all aspects of Evernote, including support.

then can you consider adding a "support" link to the Evernote web menu? Having Support links outside of your account and requiring separate 2fa authentication is overkill IMHO. And we should be able to open support tickets right from our EN Web account anyway. That is how most other companies do it.

 

Have you heard of the Amazon and Apple support account hacks?  Trust me, you don't want a hacker to call support on your behalf.  Read this article- http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/

it's chilling and these exploits have not been fixed.  Try searching webpages like http://radaris.com/ or http://www.spokeo.com/ your information is already out there.

Link to comment
  • Level 5

 

Have you heard of the Amazon and Apple support account hacks?  Trust me, you don't want a hacker to call support on your behalf.  Read this article- http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/

That is nearly a year old and those have been fixed. Nothing to see here. Move along.

 

 

But how was it ultimately fixed?  2 factor authentication, with the same rigid rules as Evernote.

http://support.apple.com/kb/ht5570

 

Come on down now Ed.  Your horse is starting to look a little high.

Link to comment
  • Level 5*

But how was it ultimately fixed?  2 factor authentication, with the same rigid rules as Evernote.

http://support.apple.com/kb/ht5570

 

Come on down now Ed.  Your horse is starting to look a little high.

It was fixed immediately by not allowing service reps to make password changes. A very low tech solution that works.

Link to comment
  • Level 5*

 

OK looks good.... BUT stupid question.

 

If I turn on 2fa will I be able to issue an application password so I can continue to use EN version 4.4.0 on IOS?

 

Not a dumb question.  It should work.  Holler back here if it doesn't.

 

 

I don't want to make any assumptions.  Does 2fa work with all previous versions of Evernote, like EN Mac 3.3.0?

Or, would I have to upgrade EN Mac to the latest version of 5.x to use 2fa?

Link to comment
  • Level 5

 

 

OK looks good.... BUT stupid question.

 

If I turn on 2fa will I be able to issue an application password so I can continue to use EN version 4.4.0 on IOS?

 

Not a dumb question.  It should work.  Holler back here if it doesn't.

 

 

I don't want to make any assumptions.  Does 2fa work with all previous versions of Evernote, like EN Mac 3.3.0?

Or, would I have to upgrade EN Mac to the latest version of 5.x to use 2fa?

 

I won't speak for EN, but what I think you'll find based on the theory, and what I've experimented with on mobile clients, is that you wouldn't be able to "work with 2 factor".  You'd get an authentication failure.  You'd instead, generate and use an Application Password in the 2 factor settings, and use that instead of your account password.

 

So you aren't getting any of the 2 factor benefits with that particular client, but it's functional insofar as the feature set it had when it was released.

 

If you found out otherwise, you'd merely log in and turn 2 factor back off in your account.

 

Strictly speaking, I would also say that each generated Application password, is a small [edit] hole (apparently the word police find -c hink in the armor- metephors too "racy")  in the protection offered.

It's a set of alternate credentials that are exempt from the protection that 2 factor offers.

 

If the implementation is vulnerable to the same abuse as Google's is, should that Application Password leak out in any fashion (low likelihood but there are several ways), then that Application Password could be used by other clients to side-step the 2 factor.

 

In that case, you audit if that's happening in your account settings.

 

Under the "access history" tab, you'll find the name you gave to the generated Application Password, with the date and IP address.

 

[edit] Er nope.  Tweaking a little highlights that it's the internal name of the application that's listed there, not the reference name you gave the Application Password.

So if you had the same app on two different devices, and generated two unique passwords with two unique reference names, you'd still only see one entry in the Application History.

 

So then it takes some sleuthing.  The IP address shown is only the most recent access.  So if you're actively using one client, you'll over-write the access IP for the other same named client, and there's no real way to see evidence of it's use.

 

moreover, just before I create a ticket, am I alone in not being able to revoke an application password?  Seems like dead links in Chrome.

 

[edit] though it's not 4pm pst yet, a support chat revealed my account is under maintenance so I'm waiving off any further tests for now.

Link to comment
  • Level 5

Even though there's individual Revoke links beside each password?

 

Currently while my account is in maintenance, viewing source code shows "fake-link" under each, so the functionality is completely disabled.

Link to comment
  • Level 5

 

But how was it ultimately fixed?  2 factor authentication, with the same rigid rules as Evernote.http://support.apple.com/kb/ht5570

 

Come on down now Ed.  Your horse is starting to look a little high.

It was fixed immediately by not allowing service reps to make password changes. A very low tech solution that works.

Be honest now.

That was an immediate and temporary fix.  Many sources said they suspended over the phone resets for 24 hours.

 

Apple PR *actually* said:

"Apple takes customer privacy seriously and requires multiple forms of verification before resetting an Apple ID password […] we found that our own internal policies were not followed completely,” they said in a statement. Apple has since reported that it has frozen over-the-phone password resets while it evaluates a better long-term solution."

That solution was 2 factor authentication.  And turning over the burden of authenticating to the account holder.

Link to comment
  • 2 weeks later...
  • Level 5

@cwb I think you have to revoke all the application passwords not just one.... Which is a pain.

 

Revoking in my account is fixed now.

single passwords can be revoked.

Link to comment
  • 9 months later...

I've lost my phone and currently I have a new one.

I try to setup 2 step authentication but I have not received sms code yet.

I used this feature in old phone (using Google authenticator). Could you tell me what's happen with my account

Many thanks

Link to comment
  • 1 month later...
  • Level 5*

I have 2FA setup...but I have a new phone...How do I 'move' Google Authenticator to this new device to keep my evernote account safe?

 

If it were me, I would disable 2FA for a few minutes, get my new device set up, then re-enable.

 

This though, is why I use SMS whenever possible vs Google Authenticator. If I lose my phone, I can get any new phone and the SMS will still go there once the carrier has ported the number to it. With GA, you might have issues, especially since some services require a 2FA login to get to the 2FA settings themselves once set up.

Link to comment
  • 5 months later...
  • 5 months later...
  • Level 5

I'd like to use 2-factor authentication for increased security, but the possibility of a mistake and messing up the procedure and losing my data is too much of a risk for me to take.

Link to comment
  • Level 5*

I'd like to use 2-factor authentication for increased security, but the possibility of a mistake and messing up the procedure and losing my data is too much of a risk for me to take.

 

I've been using 2FA onEN since day one, and on a dozen other services - a combination of Google Authenticator, and SMS. No issues yet, except PayPal, which required you to use it every. single. time. you. logged. in. and wouldn't remember your PC as secure. I turned that off. If someone can steal that $100, they can have it.

Link to comment
  • 3 months later...
  • Level 5*

 

I have 2FA setup...but I have a new phone...How do I 'move' Google Authenticator to this new device to keep my evernote account safe?

 

If it were me, I would disable 2FA for a few minutes, get my new device set up, then re-enable.

 

This though, is why I use SMS whenever possible vs Google Authenticator. If I lose my phone, I can get any new phone and the SMS will still go there once the carrier has ported the number to it. With GA, you might have issues, especially since some services require a 2FA login to get to the 2FA settings themselves once set up.

 

 

FWIW, I had to move EN back to Google Authenticator. Evernote's SMS is very slow and wholly unreliable. When i got a new machine and was trying to set it up, I was getting SMS message 5-6 minutes after requesting. Useless. ANd you have to wait for them too. If you go eat lunch and come back to it, the code will have expired and you have to start over.

Link to comment
  • Level 5

Not only do I find the SMS slow and unreliable, it does not provide as strong security.  SMS flaws allow interception and monitoring.

http://bgr.com/2015/08/18/call-text-messages-bugging-ss7-hack/

 

In the case of loss/replacement of a phone, my steps are 3 fold:

  1. 2factor TOTP methods, including Evernote generate one time codes you can stash away.  Which I put in an encrypted note in LastPass
  2. When I program google authenticator, I add it to the authenticator on my wifes phone at the same time.  And or store the QR code image in an encrypted note in LastPass
  3. The 3rd party google authenticator I use, gets restored to a new device from icloud backup should I lose and replace a phone.

Lastpass may seem like a weak point, but it too has 2 factor (a hardware YubiKey - 3 different keys actually), and GEO-IP login restrictions.  And the email link to temp bypass LastPass multi-factor (can't quite bring myself to turn that off), goes to a Gmail account which also has multi-factor on it.

Link to comment
  • Level 5*

Not only do I find the SMS slow and unreliable, it does not provide as strong security.  SMS flaws allow interception and monitoring.

http://bgr.com/2015/08/18/call-text-messages-bugging-ss7-hack/

 

In the case of loss/replacement of a phone, my steps are 3 fold:

  1. 2factor TOTP methods, including Evernote generate one time codes you can stash away.  Which I put in an encrypted note in LastPass
  2. When I program google authenticator, I add it to the authenticator on my wifes phone at the same time.  And or store the QR code image in an encrypted note in LastPass
  3. The 3rd party google authenticator I use, gets restored to a new device from icloud backup should I lose and replace a phone.

Lastpass may seem like a weak point, but it too has 2 factor (a hardware YubiKey - 3 different keys actually), and GEO-IP login restrictions.  And the email link to temp bypass LastPass multi-factor (can't quite bring myself to turn that off), goes to a Gmail account which also has multi-factor on it.

 

How do you enable your wife's phone with Google Authenticator? When I set up GA on my iPhone, then on my iPad as a backup, there mere act of establishing the iPad as a valid 2FA device deactivated my iPhone. Enabling it again on my phone automatically disabled the iPad. It seems to me you can only have one device at a time act as a GA device for a given service.

I see what you are saying about SMS. Still, chances are very very small.

I actually have my secondary codes in Evernote in encryped note text except my Evernote secondary codes. Those, like you, are in Lastpass.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...