auraphp / aura.auth Goto Github PK

Hi, I am trying to use Aura.Auth (v2.01) for a little project of mine. I use it to authenticate against AD.
I have setup a test page to try Aura.Auth and everything is great BUT for the logout function.

Apparently the logout is successfull, but then if I try to resume the session I find I am still authenticated.
I don't know what I'm doing wrong.

I am NOT using any session management on my own, I leave it to Aura itself, as per the documentation.

Does anybody else have this issue? Or am I doing something wrong?
My test code is here.

Thank you in advance.
Cris

I think we should update and better document the various default timeout values, presently set to zero, 1440 and 14400 (forever, 24 minutes and 4 hours respectively). They're kind of cryptic and probably are not really good defaults, anyway.

The 1440 value comes from the original PHP 4 sessions, back when the value was minutes, not seconds. 1440 is one entire day in minutes (24 times 60).

I'll be happy to make a pull request for the changes. Just wanted to start a bit of discussion on what good default values might be.

Consider the scenario:
1- User logs in into the system successfully: auth->isValid() is true.
2- An entity changes the password in the database
3- Check auth->isValid() is also still true. But since the password is invalid, the session should be invalidated.

I was going through the post https://blog.engineyard.com/2014/password-security-part-3 and it was mentioning about

• $2a$ — Potentially buggy
• $2x$ — Known buggy hash
• $2y$ — Using the corrected version

So I am wondering whether we need any change for

$str = substr($hashvalue, 0, 4);
if ($str == '$2y$' || $str == '$2a$' || $str == '$2x$') {
    return password_verify($plaintext, $hashvalue);
}

Hi,

I noticed the adapter is touched when using ResumeService.

On one hand it is good, but on another hand it seems bad.

Eg :

1. PdoAdapter , though there is not much thing the PdoAdapter have to do with Resume, it touches the database to be connected.
2. Oauth : It may be good in the case to refresh the token.

Is there something better we can do so that the database is not connected ?

I am still thinking..

Thank you.

Hi Paul,

I am wondering why not we can implement the Aura\Auth\Auth can call the session_start on any call to Auth methods rather than using a service like Resume and asking to start manually by users ?

Also most of the adapters are not having a logout method and in the wake of it may be we should think of having accepting the adapter being null also.

So users don't need to create the adapter objects ( especially something like PDO ) and pass to it.

Thanks!

Hi Paul,

If you look at broadway they are doing constant releases even though it is marked as not stable.

When a 0 is there 0.X.Y it says things can break. Can we make some versions like that so it can be used without the fear of change in api .

So users still can use the version on their composer.json ?

Thanks

Could we get some up to date releases tagged? I've been using 2.x-dev for a long time. ;-)

The code here at ResumeService::resume() says the method returns a boolean indicating whether the session still exists. But the method does not return a value at all.

Should the docblock be updated to not mention a return value, or should the code be corrected to actually return the documented value?

Is there a reason no error messages are include with thrown exceptions (ie: "Exception\PasswordIncorrect" or "Exception\UsernameNotFound"? Is it an i18n concern?

There is problem with AuraAuth in PHP 7.4.

The algorithm is no longer integer. Now it's a string.

So to fix the warning hash(): Unknown hashing algorithm: 2y in (...)\aura\auth\src\Verifier\PasswordVerifier.php on line 57 I have changed this method:

    public function verify($plaintext, $hashvalue, array $extra = array())
    {
        if (is_string($this->algo)) {
            return hash($this->algo, $plaintext) === $hashvalue;
        } else {
            return password_verify($plaintext, $hashvalue);
        }
    }

this way:

    public function verify($plaintext, $hashvalue, array $extra = array())
    {
        return password_verify($plaintext, $hashvalue);
    }

Is any official update possible?

Hi,

It looks good to me to pass messages when throwing exceptions.

Eg : throw new UsernameMissing("Username is missing"); .

Reason I was using try catch and it was hard to debug what the exception have caught until I recognized the message was missing ?

What do you think of adding message when throwing exceptions ?

Hashing is already possible. Only thing is not interchanged hashing for different users.

Like md5, password_hash, sha etc in a single file.

So I feel this makes the fact that we are done on this.

Hi Paul,

It seems that it will be good to update the password making use of http://php.net/manual/en/function.password-needs-rehash.php .

Else the problem is developers probably will never make use of rehashing and will forget about it.

For the sake of good to happen I feel it is good to make use of the rehashing at the library level .

Thanks

Recently I had to think of a way to persist the authentication tokens(basically sessions),
but I don't see why everyone is about using the $_SESSION. Now I know it's easy to use,
but isn't it bad for performance?(While some may say we can use SQL, storing a blob object in there is ugly). So why do we need to use $_SESSION - we also have the problems of read/write sync as well, since sessions are like mutexes and we must explicitly close them to allow multiple concurrent requests.(No streaming data otherwise either).

So, since we have a database anyway, isn't it better to just put our sessions in there? But if we put them there - there is the limitation, we have certain fields and we don't just serialize objects and mash them up. Bad for performance, unmanageable and ugly. Even worst - if our user has been changed, we must first get our $_SESSION and then ask the database about it. Bad.

So my idea is - to add an authentication that is a mix of both Session and Remember me - a normal cookie whose value references a session in our database. So when logging in - if a user selects remember me, we can just set a field in there to true. So if he is inactive for a long time, the system may boot him out, but we can still get his data from the session and autofill his username/etc.

But when using an Rest API, rather than depending on a cookie, we should make it so that a header can be used.(which will save us from XSRF and Cors attacks if Cors is enabled). For normal, non-rest api based applications, forms can contain a hidden XSRF field.
But then again - perhaps for a Rest API - one should just use a stateless authentication sending the user and pass plus a nonce every time(kinda like WSSE).

Probably via a RememberInterface injected into Auth, or perhaps by moving the "resume" functionality into an extensible ResumeInterface.

Will also need a new status to indicate the user is "remembered" and did not pass credentials, along with related methods.

The cols

$cols = array(
    'username',
    'password',
    'id',
    'email',
    'fullname',
    'website',
    'twitter'
);

$from = 'users';
$where = 'active = 1';

$pdoadapter = $auth_factory->newPdoAdapter(
    $dbh,
    PASSWORD_BCRYPT,
    $cols,
    $from,
    $where
);

assumes the array first and second value is username / password. That is a wrong assumption . May be we pass an associative array and don't use $cols[0] and $cols[1] in

Hari, Brandon, Paul: shall I go ahead and make the first release on the 4.x branch?

HashVerifier may need to check if salt is passed in data

Currently the assumption is salt is always same for all users. When we do it via di container there is no way to pass different salt.

So a way for better implementation seems, can send a PR.

public function verify($plaintext, $encrypted, array $extra = array())
{
    $salt = isset($extra['salt']) ? $extra['salt'] : $this->salt;
    return hash($this->algo, $salt . $plaintext) === $encrypted;
}

This package hasn't been significantly modified since well before August, and yet it's still in beta. This prevents using minimum-stability: stable in Composer. When is this package expected to be released?

Currently, the Timer object passed in isn't cleared (or even reset) as a part of the logout process. I'm happy to update the behavior, but I want to be sure on an approach.

I see the Auth::forceLogout unsetting the other properties (initial, active, etc), does the timer need to be handled the same way? Or would it be beneficial to just call a "reset" on it when the logout happens. It seems like the reset option would allow it to be reused for the anonymous+idle check.

I see that the SessionDataInterface instance passed in to the Auth class is used to store user information, but it's definitely possible that there's more context in the current session than just the user information (permissions, roles, etc). Is the goal of the session handling in this case to track that other information? If so, does the Auth class need to be flexible enough to pull that information from the session?

Maybe thinking some kind of repository or collection where data could be pulled with a "get_" method where the "_" is the property name...thoughts?

It would be nice if Aura.Auth was "plug compatible" with Aura.Session, so that the included session management could be easily replaced and enhanced by the more featured Aura.Session.

Need to document better way to handle the brute force attack.

http://www.reddit.com/r/AuraPHP/comments/2r285m/authentication_with_auraauth/cnbysbb

/ cc @assertchris

Hey Paul,

Was trying to test, and found the session is not getting resumed.

<?php
require __DIR__ . '/vendor/autoload.php';
$dsn = 'mysql:host=localhost;dbname=auraauth';
$user = 'user';
$pass = 'password';
$dbh = new PDO($dsn, $user, $pass);

echo " Session ";
var_dump($_SESSION);

$auth_factory = new \Aura\Auth\AuthFactory();
$user = $auth_factory->newUser(
    $_COOKIE
);

$user->resumeSession();

echo " Is annonymous ";
var_dump($user->isAnon());

echo " Is idle ";
var_dump($user->isIdle());

echo " Is expired ";
var_dump($user->isExpired());

$cols = array(
    'username',
    'password',
    'id',
    'email',
    'fullname',
    'website',
    'twitter'
);

$from = 'users';
$where = 'active = 1';

$pdoadapter = $auth_factory->newPdoAdapter(
    $dbh,
    PASSWORD_BCRYPT,
    $cols,
    $from,
    $where
);
$cred = array(
    'username' => 'harikt',
    'password' => '123456'
);

$pdoadapter->login($user, $cred);

echo " Is vlaid ? ";
var_dump($user->isValid());

echo " Session ";
var_dump($_SESSION);

echo "Cookie";
var_dump($_COOKIE);

Per the PHP docs ldap_close is an alias for ldap_unbind. But, when calling LdapAdapter::bind, after the bind succeeds both ldap_unbind and ldap_close are called on the LDAP resource, which emits a PHP error when attempting to close the (now-closed) resource the second time.

I could start working on documentation if needed.

Let me know if you feel we can start on updating the docs.

Thank you

It is considered good practice to have ldap authentication libraries first bind using a service account, then run a search for the user and finally try to bind (and thus authenticate) using the provided credentials.

As an added bonus, that would enable supports for multi-level user trees, which the current implementation does not support.