confirmation link should check proper auth

[benadida]

When an email is associated with an account, the confirmation link should just confirm that pre-declared link, and only if the user is properly logged in. If the user is logged in as a different account, that should not work. It also should not work if the user is not logged in at all. In other words, the power of that confirmation link should be very small.

[lloyd]

This will negatively impact usability.

[benadida]

can you say a bit more? Happy to think through potential problems, but it's quite important that we limit the scope of what can be accomplished with that link.

[shane-tomlinson]

@benadida - for the new user flow, the user will not be logged in and in fact will not even have a password until after they click the verification link in their email.

[benadida]

@shane-tomlinson ahah, good point. So in that case we should just make sure it's the same session as the one that initiated the email addition.

[lloyd]

Sorry to have been so terse, my point was that for cases where the browser in which the verification link is opened is not the same one that was used when the link was sent, the user visible failure mode will be lame. In the case where it's an "add email", we'll tell the user "now please provide your password". In the case where it's account creation, we'll say "please open this link in the other browser, the one you were using when you signed in". Both of these are crappy UX, especially the latter.

Now, my intuition tells me that this type of event will be rare. Usually people use one browser, usually it's properly set as their default browser. Typically when signing in on their phone, people will also perform the confirmation on their phone. I wish we had hard numbers (and at the very least we should log when these events occur and track them if we decide to lock this link down).

The other cost associated with this is we have to do the UX and make sure that we're regularly testing these flows.

None of this cost is huge, but it should be weighed against the security benefits of locking these things down. So let me turn it around: Why do you feel this is so important? What types of attacks are we preempting with this change and do you expect they'll be more common than legitimate usage that will be negatively impacted?

This is fun, let's type more.

For the account creation case It seems like the key attack here is one where an attacker cannot intercept your email at will, but happens to remotely capture an account setup email. Having this link, they'd be able to complete the account creation, and the would be able to log in with that email address without having verified it.

If an attacker can read your email at will, then none of these counter measures are effective.

For the add email case, without these countermeasures an attacker who happens to intercept one of your confirmation emails will be able to complete the action you initiated - verifying the email. They will not, however, be able to use this email to log in.

If an attacker can read your email at will, then none of these counter measures are effective.

TL;DR; All this said, the decision seems to be do we want to make the system more complex and introduce a very confusing (but admittedly fringe) bit of UX in order to prevent compromise of an account creation email from allowing an attacker to assume your identity.

A much simpler way to achieve a similar effect might be just to put a conservative time limit on verification links.

[benadida]

@lloyd my design principle here is least-privilege, meaning that, as much as possible, I want to limit the power of that email link. Not because I have specific attacks in mind, but because I'm worried about potential attacks that we haven't fully thought of.

If there were a big UX problem , this would not be reasonable. But given that the UX problem is, as you put it, likely rare, I think we should err on the side of safety. This is, after all, a login system :)

[shane-tomlinson]

@benadida, @lloyd - is this still open for discussion?

[lloyd]

Ok, I've come full circle on this. Sometimes it takes me a while.

How about for user creation we require the user to be using the same browser for initiation and confirmation.

How about for email addition we require EITHER the same browser, OR the user must re-authenticate to browserid?

[benadida]

I think @lloyd's solution is exactly the right balance. I'll implement it that way.

[benadida]

I'm upping the priority on this because I just realized an annoying issue.

Say @lloyd wants to log in as me. He can enter my email address and wait. I see a confirmation link sent to my inbox, and I mistakenly click it, cause I'm clicking-trigger happy. Suddenly, Lloyd is now logged in as me. That's not good.

[lloyd]

+1

[skinny97214]

+++ "A much simpler way to achieve a similar effect might be just to put a conservative time limit on verification links."

We saw mobile users turning to their desktops to auth the email. BrowserID is already a big pain point because of many clicks. I can't imagine adding three more would be acceptable.

http://accounts.usertesting.com/ViewVideo.aspx?file=WfRV8v%2bHpi4%3d http://accounts.usertesting.com/ViewVideo.aspx?file=Lgg6u7wL4Tw%3d http://accounts.usertesting.com/ViewVideo.aspx?file=zTA0l4%2fTEsA%3d

_Spoiler alert_- all 3 got stuck on browserID issues. see my annotations in each video for more details.

[lloyd]

I'm tackling this now, issue #1000 forces our hand:

// in order to complete a user creation, one of the following must be true:
//
// 1. you are using the same browser to complete the email verification as you
//    used to start it
// 2. you have provided the password chosen by the initiator of the verification
//    request
//
// These protections guard against the case where an attacker can send out a bunch
// of verification emails, wait until a distracted internet user clicks on one,
// and then control a browserid account that they can use to prove they own
// the email address of the attacked.

The regression that issue #1000 introduces, is that it makes it so a phishing attack is much more productive.

[benadida]

ok glad you're on it, sorry I'm behind on these issues.

[lloyd]

@benadida I'll want your review on this one.

[lloyd]

Here's what was implemented. We move password selection into the dialog - pre email confirmation. Given that here's the power of verification links:

1. for a confirmation link that creates an account - if you are confirming in the same browser OR you retype the password chosen by the initiator of a request, you can create the account. immediately after confirmation, the initiator will be authenticated and logged into the site, regardless of where the link was confirmed.
2. for addition of an email address to an account - if you are authenticated as the user who initiated the request OR you provide the password of that user, you can add the email to the account. For the initiator, as soon as the email is confirmed, she is automatically logged in.

[lloyd]

nice catch, @jbonacci.