Home Page | Roadmap | SVN Server ( Requires Registration ) | Submit Ticket

PM me with your email address so I can add you to the SVN server.

So, what’s Redux Authentication 2 about?

The point of Redux Authentication 2 is to build upon Redux 1.*, but have a more stable, feature filled and generally better authentication library.

At the moment version 1 has some bugs with the method returns and has some other niggling issues such as forcing you to use an “email” as the login handle, not having a remember me, etc ...

Version 2 will fix those issues and go farther as to include a ready made website with administrative back-end, the ability to pick and select what columns you want to use to login with, an installation controller for fast set-up, Access Control Lists and integration with phpBB, Vanilla and other popular web applications.

I would love to hear what you think about Redux Authentication 2’s future plans and if you any feature requests I would love to hear them.

You can view the Road Map and see what is planned

Kind Regards,
-Mathew Davies.

Sounds great.

Hurry up then….

Thanks audiopleb.

SVN is now available. Topic Updated

Great news for me! Thank you for the release and waiting eagerly for the final version.

Thanks a lot!

“integration with phpBB, Vanilla and other popular web applications.”

You have my mouth watering. If you can integrate with Wordpress logins - that would be extremely awesome!

I think the best thing that could help would also be a example site that we can quickly learn how to use the auth library.

Yes please, some kind of tutorial!!

Unlike version 1, version 2 will use one dynamic salt. This would be enough protection against rainbow tables and would have one less configuration option to deal with. The hash column in the users table is going to removed and I will use a value such as the date registered as the dynamic salt.

Please don’t do this. That is the ONLY reason that I am using your auth system! 

Can you explain to me why 1 dynamic salt is bad practice?

At the moment, the salt is the first 10 characters of the hashed password. When entering a password into the database for the first time the salt is randomly generated and pre-pended to the hashed password.

It’s basically doing the same thing as before, but without the hashed column in the table. This saves on table space.

Popcorn - 22 September 2008 04:32 PM

At the moment, the salt is the first 10 characters of the hashed password. When entering a password into the database for the first time the salt is randomly generated and pre-pended to the hashed password.

It’s basically doing the same thing as before, but without the hashed column in the table. This saves on table space.

True, for 1 million users it would take about 40MB more space - but at that point I don’t think it would matter. 

Maybe you could keep a smaller VARCHAR(10) salt so that users with matching passwords would still get different hashes. Any extra step you can add to hashes is worth it.

Users with matching passwords still have different hashes. Maybe you mis-understood the new concept?

Popcorn - 22 September 2008 05:35 PM

Users with matching passwords still have different hashes. Maybe you mis-understood the new concept?

quite possible

If you are using 1 salt only:

A) You are using a salt for each user - so if the database table is stolen they will have the salt for the user - and the user password hash it’s self.

B) you are using a global site salt - users with matching passwords will have the same hash.

That is why I would encourage you to keep the user and site salts as they both help protect things.