Following discussion & further research:
There are six primary layers of security, that have been identified by Mozilla.
With the verified email created within the browser session, the variable can be placed in a $_SESSION, and the DB can be accessed at level one security.
This carries the risk of a malicious user locally injecting code and subverting the Script.
There is no specific data available, on 'how hard to achieve' this is, or the likelihood of your site being breached.
Mozilla documentation implies that the risk is mitigated, by verifying the assertion remotely (discussed below) - the script we're using does 'verify remotely'. But..... there is still a 'category' risk.
The threat is probably best considered in terms of 'data value', or 'high value target'.
The key is to understand that there ain't no password being stored (that could open up more valuable vaults).
But with such a potential malicious attack, you wouldn't want your bank account details stored at this level.
The script presents layer 1 level of security
Explicitly specify the audience parameter and verify it.
audience: The hostname and port of your website.
You must hardcode this value in your backend; do not derive it from any data supplied by the user.
Do not trust the Host header sent by the user's browser.
If you trust the user's browser to tell you the audience, then it becomes possible for a malicious web site to reuse assertions for its web site to log into your web site.
The script provides for this - layer 2.
Pass the assertion to the server.
"When a user tries to log into a website, their browser generates a data structure called an assertion - essentially a cryptographically signed email address. The browser sends this assertion to the web site, which must verify that the assertion is valid before logging the user in."
This provides the direct handshake between the verified email & the server.
Like...... sending a letter long distance saying "this is from me", or standing in front of the guy, and saying "this is from me".
The latter.... there is no chance of interception, therefore eliminating the risk outlined in layer 1.
This level is still in beta.
The scripts are available, but simply not recommended for live use as yet.
I need to clarify what exactly this means, and when they can be used.
Verify SSL certificates
To verify an assertion, you may issue a POST request to https://verifier.login.persona.org/verify
. You must ensure that your HTTPS request verifies the certificate sent from the server against a trusted root certificate. If you don't, then an attacker could pose as verifier.login.persona.org and issue false verifications.
Check that the library you are using to make the request verifies certificates correctly, and that you are initializing it with the appropriate root certificate(s).
I've seen the code for this, uploaded a few days ago.
So this is up for inclusion.
Implement CSRF protection
In a CSRF (Cross-Site Request Forgery) login attack, an attacker uses a cross-site request forgery to log the user into a web site using the attacker's credentials.
CSRF login attacks, and potential defenses against them, are documented more fully in Robust Defenses for Cross-Site Request Forgery (PDF). They're not specific to Persona: most login mechanisms are potentially vulnerable to them.
From The variety of protection techniques (in that document), one approach is to create a secret identifier in the server, shared with the browser, and require the browser to supply it when making login requests. For example:
As soon as the user lands on your site, before they try to log in - create a session for them on the server. Store the session ID in a browser cookie.
On the server, generate a random string of at least 10 alphanumeric characters. A randomly generated UUID is a good option. This is the CSRF token. Store it in the session.
Ensure that the AJAX submission or form POST includes the CSRF token.
On the server side, before accepting an assertion, check that the submitted CSRF token matches the session-stored CSRF token.
Also seen the code for this.
Content Security Policy (CSP)
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware.
If you use CSP on your site, you may need to tweak your policy to enable Persona. Depending on your policy, you may need to:
: URIs and replace them with code loaded from an additional script file. The file can look up elements based on their ID, and then attach to the element by setting onclick or calling addEventListener().
as both a script-src and frame-src so that your site can load the remote include.js file and that file can communicate with the fallback Persona implementation.
An example Apache configuration might include:
Header set X-Content-Security-Policy: "default-src 'self'; frame-src 'self' https://login.persona.org
; script-src 'self' https://login.persona.org"
For a new build site, this would be automatic.
For a large site, all further scripting would be to the new policy, and then roll through the older files.
All included, this should be a very secure sytem, with the benefit that this can be 'out of the box', allowing for differing DB structures.
I'll sort out the files & links tomorrow, to allow examination, and to determine how they might be implemented.
Much of the above was gleaned from https://developer.mozilla.org/en-US/docs/Persona