Lets make it a complete Package

[pushpinderbagga]

Hello Ben

I've been reading a lot and everyone seems to be very happy with Ion Auth's simplicity but wish it had more featured.

Lets discuss features that can be added and collaborate to make Ion Auth the best Authentication Library ever. I suggest the below features

1. Choice of Encryption with AES etc
2. Segregating Profile Information from Login Information
3. Better protection against Brute Force and XSS Attacks
4. Enhanced ACL with Administrative Dashboard
5. Encryption of all fields in Login Table

What else? Lets discuss, finalize a few and implement for everyone to use!

[benedmunds]

Sounds good to me.

1. Adding a different encryption should be easy enough, we already have bcrypt and sha.
2. How so? Just separate tables? V1 had that but I don't feel that it's worth the performance hit.
3. Definitely up for suggestions here.
4. This is definitely a good idea.
5. Not sure how useful this is but up for discussing it.

[damko]

about 4. being Ion Auth a library to plug inside other projects, providing an Administrative Dashboard could be unwilled. I mean, on one side is good to think about improvements on the other one there is the risk to build up a too rigid structure.

[benedmunds]

Yea agreed, I think it would be good to make it a separate project that someone could pull down if needed but it would work with Ion Auth out of the box. I've always wanted to create different modules and integrations so this would fit well with that.

[pushpinderbagga]

Interesting. More suggestions...

1. Ion Auth to be installed as HMVC. So its more manageable and installable with its own Libraries, Config, Helpers etc.
2. User data may be 15-20 columns, either keep all in one table or just separate it from the Users table. Its always useful to keep a Users table and another Users_Profile table for safekeeping on structure. One could not allow people to fiddle with Users table but if we have a separate profiles table - it can be open access to development / testing teams.
3. Sequentially increased delays in multiples of number of failed login attempts for stop brute force attacks.
4. Why not encrypt everything in the Login tables - it will be beneficial only to everyone - I wonder who would not love encrypted data?
5. Let it be simple enough to install with all features configurable through a config file but it should be awesome enough to safe guard the web application against almost all attacks.

Lets discuss more...

[delay]

On 2. I prefer just having one table for the user data. If you have 2 you are just adding complexity to your DB queries, code, etc. If you really need two separate tables for some reason it would be easy enough to just write custom code that handles this and stores that data separately. You already have a way to add additional fields to your user table easily.

On 3. I think that's a good idea.

On 4. If you decide to do that please make it an option as it would make a lot of tasks harder and more expensive. There wouldn't be an easy way to tell whether a user already exists or to find a user quickly if everything is encrypted.

[benedmunds]

1. I prefer it to be generic so everyone can use it, it's pretty simple to use it with HMVC if needed.
2. I also prefer one table and this is the reason v2 only has one table.
3. Definitely a good idea.
4. I could see making a config option for which fields should be encrypted... I don't really see this as having many use cases though, can you convince me?
5. That'll definitely take some discussion, balancing power/flexibility and security is always difficult.

[pushpinderbagga]

For the moment - all I can make out if that we can focus on the below points.

1. Delay for Brute force attacks. May be a redirection to another page after say like 20 failed attempts (No use putting additional load on the server by really long delays)
2. Encryption Fields as a Config option
3. AES as Encryption Option

If we use HMVC and have to install just a folder - we can also make it as an installer. Like give options on a page and ask the use to submit after selecting those - which on submit makes the necessary tables etc - err - like Wordpress?

[benedmunds]

I really dont like the idea of an installer, just makes it much more complicated than it needs to be. If you guys want to make one I'll be glad to create a branch for it or link to it in the readme though.

1-3 I'm definitely down for. Let's get rolling!

[pushpinderbagga]

@benedmunds - any way to send an alert or email to people who are already using Ion-Auth? They could give in more inputs in regard to the changes/improvements they seek.

Also, lets first tackle Brute force attacks. I suggest the below

Track the attempts per IP and not just the username. The attacker could use multiple usernames and as many passwords. To trigger the security the below can be considered

Case 1. (X) failed login attempts per IP Case 2. (Y) failed login attempts per Identity

(X, Y are configurable via config file)

Case 1 should trigger a Ban on the IP and the user to be redirected to a configurable page elsewhere on the server. Atleast for 1 hour.

Case 2 should definitely introduce an incremental Y*(2 second) delay and along with it a Captcha (Delay and Captcha configurable). If more than a particular maximum (configurable) value - should skip to Banning the IP.

Just suggestions - might be too strict or wrong, am more than willing to discuss and learn from the community.

Also I read that xss_clean is weak in Codeigniter - we should introduce a better xss_clean because attackers generally try injection than brute force where possible?

[benedmunds]

There's not really a way to contact users...

I'm not sure if we should care about IP since you can't really bruteforce effectively if you are constantly changing the username. Thoughts?

[pushpinderbagga]

I believe attackers take logically generated usernames or dictionary references and random passwords for brute force attacks. With advanced cards - even an amateur hacker can try more than 200,000 attempts per second...

Pretty sure about it...

If we are doing it - then why skip a loophole?

[benedmunds]

Good point, why not have more security. Let's do it, I would say we add progressive timeouts and after X attempts (configurable) we can lock them out for 24 hours or something like that.

[damko]

Wow this became a long and interesting thread :)

About Hmvc module I think that being ion_auth also a spark solves all the problems

Personally I think that Ion Auth should just a plain and simple spark without any imterface because I guess that most of its users are developers embedding it in their own projects for which they can surely provide an interface..

About the users table fields probably an orm would do the trick and developers can add all the additional data they want. In this way the basic users table can contain a minimum amount of data (for instance using Contact Engine I don't need to collect any user's data in mysql)

Even if I don't think that an orm is necessary especially considering the cost of the operation I have to say that I recently got used to redbean and I think it's awesome.

I also like the proposal against brute force.

My 2 cents :)

[pushpinderbagga]

I did put a tiny snippet to cater brute force in my controller - I know its very simple but it can sure be modified etc...

$attempts = $this->example_model->get_attempts($ip);
sleep($attempts*2);

Cheers!

[benedmunds]

Thanks for sharing!

[pushpinderbagga]

I also have a suggestion of keys for encryption and decryption...

Lets not just only use a salt but a combination of 3 keys to encrypt and decrypt the password etc... Why not use the password itself as an additional key to encrypt it?

$key = $salt . $password . $environment

Just a thought - it would not affect the user as Ion-Auth would still be easy to implement and simple to use but way more secure!

[benedmunds]

At some point it's not really making it any more secure. Using a salt and hashing is pretty much just as secure.

If you're worried about security I'd definitely recommend you switch to bcrypt.