Authentication example using a secure hash (password_hash)

[John Ranson]

I came up with a solution for using password_hash and password_verify for authentication. It is a bit of a kludge, but it seems to work so far. (I've made a few cleanup edits, but I don't think I've introduced any typos.) I thought I'd share so that other people can benefit from it or point out issues.

Any thoughts?

--John

<?php

class tables_users {

function password__serialize($password) {

   if (empty($password)) return "-"; // Possibly unnecessary

   $query = "SELECT password FROM users where username='".$_POST['UserName']."'";

   $result = xf_db_query($query,df_db());

   if ( !$result ) throw new Exception(xf_db_error($app->db()));

   $line = xf_db_fetch_array($result);

   xf_db_free_result($result);

   $tmp_hash = password_hash($password, PASSWORD_DEFAULT);

   if (empty($line['password'])) return $tmp_hash; // Possibly unnecessary

   if (password_verify($password, $line[password])) return $line['password'];

   return $tmp_hash;

}

}

[Steve Hannah]

Looks good.  Thanks for sharing.  You might also want to refer to this doc

http://xataface.com/wiki/Authenticating_Against_the_Joomla%21_Users_Table

Which uses a similar approach to authenticate against the Joomla users table.

Steve

--
You received this message because you are subscribed to the Google Groups "Xataface" group.
Visit this group at https://groups.google.com/group/xataface.
To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/566a5f61-d1da-4e06-aa7b-fed81eff000b%40googlegroups.com.

--

Steve Hannah

Web Lite Solutions Corp.

[ge...@77webtechnology.co.uk]

This is good timing - it may be a kludge but I've recently had to upgrade to PHP 7 and my Joomla auth solution started throwing a deprecated warning concerning the fixed salt (extracted from the stored hash) used in the manual comparison. This solution gets around this by (properly) using the 'password_verify' function with a nice bit of lateral thinking on getting it working with the existing Xataface functionality. I have incorporated it into my script as mine also copes with older Joomla hashing routines - probably not necessary but a 'belt & braces' for those people that haven't had their password re-hashed via logging into Joomla first.

I would say the one PHP warning I was seeing wasn't so bad, but this was suddenly on top of over 50 Xataface core files needing fix-ups to prevent their own PHP7 generated 'Methods with the same name as their class will not be constructors in a future version of PHP' warning, which was creating large error logs (I don't have control over the granuality of error reporting on my production server). Anyway, these two fixes have meant all warnings have gone (for the time being!).

If anyone wants more on either of these issues, feel free to get in touch...

[Steve Hannah]

If you update Xataface to the latest from the github master, it should get rid of the PHP7 warnings.

--
You received this message because you are subscribed to the Google Groups "Xataface" group.
Visit this group at https://groups.google.com/group/xataface.

To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/897fe80f-bf67-4a16-812f-c4237daa0f22%40googlegroups.com.

[ge...@77webtechnology.co.uk]

Hi Steve,

I used what I thought was the latest master from Github as a base for an overall PHP upgrade (ver 2.2.0 4805?) in order to avoid as many problems as possible, but the class name/constructor warning is prevalent. I found a simple '__construct' renaming of the function is part of the solution, but it was quite a game getting the most commonly called scripts changed (example attached).

[Steve Hannah]

Please post any warning messages you get so I can fix them.

To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/7012283f-0cd3-449e-8f9a-2a9fe538638e%40googlegroups.com.

[ge...@77webtechnology.co.uk]

So this was the warning:

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; foo has a deprecated constructor in example.php on line 3

referred to here:

http://php.net/manual/en/migration70.deprecated.php

On Friday, June 30, 2017 at 2:39:04 PM UTC+1, John Ranson wrote:

[Steve Hannah]

I need exact warnings to see where they occur to fix them

--
You received this message because you are subscribed to the Google Groups "Xataface" group.
Visit this group at https://groups.google.com/group/xataface.

To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/3913893c-3b76-47e0-941c-fa1c78da5668%40googlegroups.com.

[ge...@77webtechnology.co.uk]

I think this error log shows most I initially encountered. For completeness, the other file lists the file edits I did to eliminate the errors.

On Friday, June 30, 2017 at 2:39:04 PM UTC+1, John Ranson wrote:

[Steve Hannah]

Does that xataface_edits.txt file suggest that you have already fixed those files locally?  If so, can you share?  (ideally, submit a pull request - but if not, just providing the changes some how).  

Best regards

Steve

--
You received this message because you are subscribed to the Google Groups "Xataface" group.
Visit this group at https://groups.google.com/group/xataface.

To view this discussion on the web visit https://groups.google.com/d/msgid/xataface/95567e33-ac8d-433b-a797-fd272706cbc3%40googlegroups.com.

[ge...@77webtechnology.co.uk]

I've used a fork from Github and pushed the edited files. Not done this stuff for a while so please forgive any gaffs. I see some possible versions diffs, but I've only changed the initial function statement (where same as class name) of each file...
PS Obvious point is that these are only the files that have been called by my apps - no doubt others. Also there's one file in module depselect which I can follow up

On Friday, June 30, 2017 at 2:39:04 PM UTC+1, John Ranson wrote: