805608 - Ensure Marketplace does not accept unverified email state for already verified accounts

Status: VERIFIED FIXED

(Marketplace Graveyard :: Consumer Pages, defect, P2)

Description

[Austin King [:ozten]]

Marketplace will have a state where an account is treated as 'unverified', which can later be promoted to a more trusted state, by the user completing an email verification loop.

The logic that manages this should check to make sure that an account isn't already a "trusted" account (aka Marketplace verified).

It is a corner case, but the Marketplace should reject an unverified email from Persona login, for these already verified Marketplace accounts. Perhaps an error message asking them to check their email, or a second Sign in button which doesn't use the "allow unverified" feature.

Comment 1

[Christopher Van Wiemeersch [:cvan]]

Kumar, do we still need this?

Comment 2

[Kumar McMillan [:kumar]]

it's an edge case but it seems like a good idea. As I recall, we had trouble implementing this only because of devs switching between dev/stage/prod environments with the same email.

Comment 3

[Matt Basta [:basta]]

Is this still a thing?

Comment 4

[Kumar McMillan [:kumar]]

ozten, is this even still possible now that the fxos Persona DB has merged with the main Persona DB? I.E. If an email has been verified, how would someone be able to log in with that *same* email and generate an unverified assertion? It seems to me that once an email is verified, assertions will always be verified from that point on.

Comment 5

[Austin King [:ozten]]

Can someone use Marketplace without Persona?

Marketplace should reject an *unverified email from Persona login*, for these *already verified Marketplace accounts*.

Threat model:
I signup and use Marketplace Desktop. I setup payment, etc. My email is [e-mail]. (I realize desktop payment might not be a thing currently, but it will be)

Someone else signs in via FxOS with [e-mail] in an unverified state. They could [have some] control of a real account via an unverified channel.

Comment 6

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

There are definitely session fixation attacks on unverified emails.  I am hoping we can get away from unverified email one way or another.

The catch with already-verified accounts is that they may be verified via some other primary IdP, no?  With forceIssuer, how can we let you re-auth with your primary?

I think we (Mozilla) are going to have to agree either to use a silo (Firefox Accounts) or to use fully-federated Persona in all our products.  Once we start hitting markets where people are covered predominantly by gmail and yahoo, I'm afraid things are going to become very confusing with the present forceIssuer + allowUnverified mix.

Comment 7

[Kumar McMillan [:kumar]]

ok, I see now. forceIssuer is what messes everything up :) So the main theoretical threat is: 

1. [e-mail] logs into Marketplace desktop using the Gmail bridge (which generates a verified assertion)
2. Some attacker logs into Firefox OS with [e-mail], sets password, sets PIN, and pwns Fred's account using an unverified assertion. This would theoretically work because forceIssuer is set to firefoxos.persona.org.

However, I could not reproduce this. I hit a Persona error: https://github.com/mozilla/browserid/issues/3842

If Persona allows that to happen, this bug is severe. We could address it easily in Marketplace by setting is_verified on the user table and disallowing unverified logins after that is flipped to True.

Comment 8

[Austin King [:ozten]]

> If Persona allows that to happen, this bug is severe. 

From a defense in depth perspective, it's best to not trust Persona to get this right.

> We could address it easily in Marketplace by setting is_verified on the user table and disallowing unverified logins after that is flipped to True.

This is a good design. +1

Comment 9

[Kumar McMillan [:kumar]]

bumping priority based on comment #8

Comment 10

[Kumar McMillan [:kumar]]

Hmm, I actually don't think we can implement this until Persona supports this better. If Persona asks you to create a password on Firefox OS when you log in with a Gmail account for the first time then that means it would generate an unverified assertion.

Comment 11

[Austin King [:ozten]]

The Marketplace receives to classes of assertions. Normal and unverified.

I think you'd set this flag the first time you see a normal assertion.

Is that enough? In the original design, I pushed for "levels of assurance" but we decided to not go down that road, thinking that assertion type was enough.

Comment 12

[Kumar McMillan [:kumar]]

Hiding this hijack scenario because I think it is realistic. See also bug 910938 (fixing the hijack scenario)

Comment 13

[Andy McKay]

Looks like there is consensus that the hole is possible. Currently we are safe and can't fully reproduce this because https://github.com/mozilla/browserid/issues/3842 is still open. We are being saved by an error in Persona.

As a good defensive practice we should do whatever we can to close this hole. Using the plan in comment 7 sounds good.

Assigning to ashort because hes the user guru for when appresource is all migrated.

Comment 14

[Allen Short [:ashort]]

https://github.com/mozilla/zamboni/commit/f15e15d

Comment 15

[krupa raj[:krupa]]

I couldn't reproduce the issue where I was able to use the email id to sign up twice. Calling this fixed.