v10 new login & cookie system Reply to topic

Hi all,

finally after months/years of work we now finally have a new login system.
Currently only the new cookies and DB authentication should work.
Please report any errors encountered!

About the (DB) login:
We want to support SSO logins through other services like XRI, OpenID, Facebook, LDAP, IMAP, etc. etc.
While DF can't store the passwords of these, there must be a different way to detect who-is-who.
Therefore i've created an authentication system that allows a user to connect mulitple SSO's to a single DF account.
The auth_identities table manages all identies hooked to a user_id.
For example you can login using Database, XRI, Google and Facebook, so if you forget one you can always login with one of the others.

The Database passwords are not MD5 anymore. I always wanted to change that but it made upgrading or converting from another system (Coppermine, php-nuke, phpbb, etc.) a nightmare as everyone needs a new password.
So instead the system now stores "algo:password" inside the database.
When you login it will verify your password with the defined algorithm.
And when you change your password it will use bcrypt by default.
If you can't use bcrypt for unknown reasons you can change that in the config_custom db table.
For example: auth | default_pass_hash_algo | sha256


About the new cookies:
The old cookie was: base64_encode("id:secure:password");
Problem with this cookie is that a man-in-the-middle attack could easily base64_decode the cookie and decode the password md5 hash.
Another issue is SSO (they don't provide passwords).

Now the cookie doesn't have the password anymore and contains: user_id, IP address.
Then you say: oh wait a minute, that is easier to read and hack.
Yes you are right, but atleast they don't have your password!
So, to secure the system it encrypts the cookie data using a website random algorithm and unique encryption key (no website has the same).
This way a cracker needs to figure out the algorithm used AND the key.

Admin and user cookie both use their own algorithm and key so even if someone cracked the user cookie, they can't create an admin cookie (they can only login as different user).

Still todo: Modify "admin -> main settings -> cookie" to allow modifying the new cookie settings.

Admin settings are pushed to code.google.com

Only one thing remaining which i overlooked (after making the admin settings).
cpg_member::__construct keeps verifying the cookie on every request.
This should be disabled and rely on $_SESSION (to allow websites not using cookies at all).

will their be admin option to disable each sso that we do not want to use

yes, eventually that will be possible as well

Done
Here's a screenshot:

Looks very enticing! Thanks for the hard work!!!

Frontend Login module created. More info:
dragonflycms.org/Forum...25224.html

It may be more secure but continuing logging in is nauseous. Few times already I've lost my replies because internet dropped, session logged me out or other unexpected issues.

Moreover there are few more issues:
1. I reply, view the reply, go back to last posts search and my own post already viewed still shows as a new post.

2. Same as before but I enter and read the post again to finally mark as read. Login from another device and it still shows as unread.

... continued ...

3. When I login back again from the first device my own posts still shows as unread.

Did comeback again with the same device at step 3 (browser never closed and no need to login again) but this same post still shows as unread.

It's now possible to hook your facebook and google+ login.
You can manage them here:
dragonflycms.org/Your_...tails.html

When activated you can login with one of your options to the same account