Hi Llyod,
What do you envision the assertion based keyA recovery
to look like?
One such mechanism I can think of is
1. User visits forgot key / reset page
2. Is user logged into Persona?
yes) User sends signed assertion + user certificate
to keyserver
no) User signs in with Persona
3. keyserver verifies assertion (email matches email for
account, validity of assertion, etc) and returns keyA
4. Client magic retrieves keyA and stores it
vs an email based flow
1. User visits forgot key / reset page
2. Keyserver emails user a unique reset link
3. User visits the link
4. Client magic pulls retrieves keyA and stores it
My primary concern is reuse of the assertion. An
email workflow can enforce single use recovery
links.
If an attacker can capture an assertion+certificate
request, then they can retrieve keyA for the lifetime
of the assertion. This is partially mitigated through
the generation of short-lived assertions and SSL
between the client and RP. However a XSS attack on the
keyserver may result in the client sending the assertion
+certificate to another server. This doesn't affect
the security of Persona but would have implications
for an assertion-based recovery process.
CSP and other secure coding best practices would make
the above unlikely.
My other concern is the "introduction" of IdP
dependencies. I use quotes since PiCL will already talk
to IdP, but IdPs would be something which is added
compared to an e-mail flow. An IdP compromise would
result in the ability to retrieve user's keyA. However
this could be put in the same class of attacks as
compromise of gmail, yahoo or any other email provider.
For the email based retrieval mechanism, we are
relying on the security of the intermediary servers.
A worst case scenario is a rogue server capturing all
the recovery links and keyA as a result. Given that
email has been the standard for password recovery,
I don't this is a huge concern.
David
----- Original Message -----
> From: "Lloyd Hilaiel" <[email protected]>
> To: [email protected]
> Sent: Monday, August 12, 2013 6:55:23 AM
> Subject: Reducing the security of class A data
>
> Now that some of the other challenging threads have died down, let's have
> another one.
>
> As I think deeply (at least as deeply as I am capable of) about how users
> will log into different firefox products, and how we can really achieve a
> high level of integration, I am reminded just how challenging this problem
> is. I'm at the point in my meditation where I have distilled things down to
> a single most important question.
>
> What are the cons of reducing the security of recoverable class A data such
> that it could be accessed with a persona assertion asserting ownership of
> the email address stored in your account?
>
> Note:
> I realize that we've taken some shortcuts in email verification, and that a
> verified email address in firefox accounts isn't as rigorously verified as
> one in persona. Ignore that for now. Think just about the security delta
> from competing products and our current design.
>
> /me braces self
> lloyd
> _______________________________________________
> Sync-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/sync-dev
>
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
