Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 7 of 7
  1. #1
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts

    Persona PHP script but how to securely access the DB?

    I recently picked up again on the Persona project, and found a very nice PHP script pack, that verifies the visitors email address, creating and ending a browser session.

    Anybody wishing to examine it, the zip pack is here

    The issue I'm addressing now is:
    How to securely connect to the DB, and store the email as the userID.

    The difficulty for me researching this is that all the docs I see refer to a password being placed in the table, and any visitor is asked for the password, and if it matches, then the account records are accessible.

    Easy to understand, common sense logic.

    However, in this case, the DB must trust the email as presented to it.
    ie. here is the email..... it matches a record set...... okay you have access to those records.

    I noted: http://dev.mysql.com/doc/refman/5.1/en/user-names.html

    "you cannot make a database secure in any way unless all MySQL accounts have passwords. Anyone who specifies a user name for an account that has no password is able to connect successfully to the server."
    So how can the verified email be used, without a password, using PHP and MySQLi?

    Here is the front end code, that launches the scripts and recieves the email variable $email.

    PHP Code:
    <?php
    error_reporting
    (0);
    include 
    'my_login_php_config.php';
    $login_content $email NULL;
    if (isset(
    $_POST['assertion'])) {
        require_once(
    $browserid_php);
        
    $result json_decode(Verifier::verify($_POST['assertion'], $_POST['audience']));
        
        if (
    $result->status === 'okay') {
            
    $login_content "<p>Logged in as: " $result->email "&nbsp; <a href='javascript:navigator.id.logout()'>Logout</a></p>";
            
    $email $result->email;

    //HERE IS THE VERIFIED EMAIL ADDRESS.
    //I NEED TO QUERY THE DB TO SEE IF IT EXISTS
    //IF IT DOES, THEN THAT ACCOUNT IS OPENED
    //IF NOT THEN A NEW ACCOUNT CREATED


        
    } else {
            
    $login_content "<p>Error: " $result->reason "</p>";
        }
    } elseif (!empty(
    $_GET['logout'])) {
        echo(
    "<script>
        <!--
        location.replace($login_page_php);
        -->
        </script>"
    );
    } else {
        
    $login_content "<button id=\"signin_button\" onclick=\"javascript:navigator.id.request()\" ><img src=\"plain_sign_in_black.png\" alt=\"sign in with Mozilla Persona\">&nbsp; (Test the login system for yourself)</button>";
    }
    ?>
    Last edited by Ace.....; 03-18-2013 at 02:50 PM. Reason: Changed code tags to PHP tags

  • #2
    Regular Coder Arcticwarrio's Avatar
    Join Date
    May 2012
    Location
    UK
    Posts
    721
    Thanks
    20
    Thanked 84 Times in 84 Posts
    it cant, you need an encrypted password hash stored in the db and not the password itsself.

    anyone could type an email address in, of course only the owner could validate it
    There are 10 types of people on CodingForums,
    Those who understand Binary and those who dont.
    Get Cloud Hosting now from only£59 / month

  • #3
    Regular Coder Arcticwarrio's Avatar
    Join Date
    May 2012
    Location
    UK
    Posts
    721
    Thanks
    20
    Thanked 84 Times in 84 Posts
    there might be something in your file require_once($browserid_php);

    that hold the persona id from the browser, in which case it would only work on the pc you registered the email address from
    There are 10 types of people on CodingForums,
    Those who understand Binary and those who dont.
    Get Cloud Hosting now from only£59 / month

  • #4
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Thanks for the input.
    I'll explain a bit more about this Mozilla project.

    The Mozilla Persona Principal Is:

    Your email account is secure...... you're stuffed anyway if it isn't cos even using the old style password storage method, the account confirmation is by email.

    The difference here is that Mozilla provides an intermediary layer, whereby, when you register for a Persona account, you enter the email address of your choice and your chosen password (as normal).
    Also as normal, you then get a clickable email.
    On click confirmation, your persona account is created on mozilla servers, and your email is strongly encrypted in your browser.
    Note: if you use 3 browsers, you will do this 3 times.
    When you then log on in future, to any Persona enabled site, you can simply click your email, and your logged in.

    The site developer has no hassle or risk, from storing user passwords... the primary security layer is handled by the mozilla persona system.
    The site user has no fear that their password will be compromised by hackers, or by a dodgy site owner.

    Clearly this is potentially a huge leap forward over what we have now.

    To fully understand this process, I believe the best way forward would be to click the link here, and simply log in, by clicking the persona button.

    Not only will you test the system for yourselves, but at the same time, you will gain a Persona account.
    You will also be able to download the system pack, and install it on your web site.

    To implement the scripts will take around 3 - 4 minutes, but it's possible in under a minute.

    Download the zip file 3 seconds
    Unzipping 6 seconds
    Open Filezilla 30 seconds
    Upload the directory to your website root directory 20 seconds

    Point your browser at that directory, and you'll have you're own persona enabled site.

    If you upload the directory to a sub directory of your root dir, then simply open:
    my_login_php_config.php
    and modify the basepath variable with the name of your sub dir.
    Note: there is a read_me_first.txt but the files are commented.
    ***********

    Okay, that was quick and easy, and you can probably see why Mozilla are putting in this effort.

    However, their effort is in the Persona system, currently in beta and apparently working fine...... but it seems we're supposed to know how to take advantage of this apparent step forward in security.

    Perhaps a bit like getting into ubuntu and finding that, not only don't you know how to launch terminal.... but..... you don't even know what terminal is.

    LOL

    Do you remember that... cos I do. LOL

    The difference is that we've got a huge community to turn to (here).

    But with the persona system, we don't have any 'direct' reference to help docs, cos any php, mysql, user account, help-docs ALL refer to password protection - cos they were all written before persona existed.

    However, there is a way to use this verified email, to interface with a mysql DB.
    Ie. We know that the person who has requested to log into our system, is the person who controls the email account.

    The question is:
    How do we use this verified email as the key to that individuals account?

    It is probably very simple....... but because I don't know the questions to ask, I don't know the answer.
    And sadly most people are in the same boat cos they've learned the basics of password verification.

    That's where we're at.
    But get on the test site, register, and download the files, so that you're up to speed with this new development.

    Hopefully by then a super php bod will have come on the thread, and put us out of our misery

    Good project though, no?

  • #5
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    It appears to be the case that a fairly complex additional script is required for server authentication.

    The current script sets up the browser session with a verified email address.
    However, as this is open source development, different people have worked on different elements (in different ways).

    I've found 2 scripts, and will post back after contacting the authors.


  • #6
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    Following discussion & further research:
    There are six primary layers of security, that have been identified by Mozilla.

    Layer 1

    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

    Layer 2

    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.
    Do not trust an explicit parameter sent by the user's browser, but generated by your JavaScript using, e.g. document.location.
    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.

    Layer 3

    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.

    Layer 4

    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.

    Layer 5

    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.
    Deliver the CSRF token to the browser by either embedding it in JavaScript or HTML as a hidden form variable.
    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.

    Layer 6

    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:

    Remove inline javascript: 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().
    Allow https://login.persona.org 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

    Last edited by Ace.....; 03-20-2013 at 03:13 AM.

  • #7
    New Coder
    Join Date
    Nov 2012
    Location
    France
    Posts
    78
    Thanks
    20
    Thanked 0 Times in 0 Posts
    This is the link to a fairly comprehensive library of security scripts relating to the previous post:

    https://github.com/Falco20019/php-br...ive/master.zip


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •