Thread

Hey Adam,

Just another quick question, working on mapping out the website here. I noticed there is a group database table, as well as the array defined in the config. In short what’s the difference? I noticed in one of your video’s your adding a user permissions section so I was curious how important that database table is / what it would best be utilized for / its ... uhh.. function in comparison to the array

Hey Adam,

Just another quick question, working on mapping out the website here. I noticed there is a group database table, as well as the array defined in the config. In short what’s the difference? I noticed in one of your video’s your adding a user permissions section so I was curious how important that database table is / what it would best be utilized for / its ... uhh.. function in comparison to the array

At the moment the groups database table isn’t utilised by The Authentication Library. Yet. It’s put there so developers can use it in their applications, just taking a step out of what they have to do.

But as you’ve seen in the screencast I’m adding a roles and permissions section for the ACL - so the groups database will be used.

Thanks.

Awesome, is there an ETA on that release? .. is it something I should consider when mapping out this website, or should I continue ahead as if I don’t know its coming haha

Awesome, is there an ETA on that release? .. is it something I should consider when mapping out this website, or should I continue ahead as if I don’t know its coming haha

Continue ahead as if you don’t know it’s coming. It’s very much a work in progress at the moment and still needs some tweaks and testing.

Thanks.

Just a *bump* of Skinnpenal’s comment #41, think that’s an excellent question = )

I’m curious, does anyone have any thoughts on how secure this auth library is?

I’ve up till now used FreakAuth, which I’m mainly abandoning because it feels so bloated.

Unfortunatly because I’ve still got a lot to learn about security, I can’t judge much from what I see in the code. One point though, is that I see that limiting of login attempts is cookie based only, doesn’t this basically mean that it has no effect on brute force attacks?

In regards to limiting the number of login attempts to 5. A brute force attack is usually an automated process. Therefore a script running from an external resource would not be able to edit the cookie unless a macro was used along with a cookie editor to reset the attempts to 0. The whole point of having the maximum login attempts is to prevent a brute force attack.

In regards to general security. The Authentication Library was built to be simple and to be secure, if you read through the 3 threads on here and the many many pages of user comments, I haven’t had one comment related to it being insecure or the security to be poor. The remember me function uses a somewhat unique way of authenticating the user using a cookie; this was suggested to em by a user of the first “Fresh Powered Auth Library” and has been implemented in this version.

Hopefully I have answered your questions and I can only apologise for not seeing it and replying to it earlier.

Thanks.

In regards to limiting the number of login attempts to 5. A brute force attack is usually an automated process. Therefore a script running from an external resource would not be able to edit the cookie unless a macro was used along with a cookie editor to reset the attempts to 0. The whole point of having the maximum login attempts is to prevent a brute force attack.

Thanks for the reply 😊

What I mean is that I get the feeling that the automated tools has some countermeasures to this type of “security”. If I were to build an automated tool, and knowing many login systems limit attempts with cookies, I’d make it clear the cookie after each failed attempt.

Could logging the attempts into a db table be a strengthening? I don’t know how that could be done well, though. IP-only could block out a huge institution, school, etc. And combining it with user agents it pointless since it could be randomized from the automated tool (?). Well, I don’t know.. like I said, just curious 😊

In regards to limiting the number of login attempts to 5. A brute force attack is usually an automated process. Therefore a script running from an external resource would not be able to edit the cookie unless a macro was used along with a cookie editor to reset the attempts to 0. The whole point of having the maximum login attempts is to prevent a brute force attack.

Thanks for the reply 😊

What I mean is that I get the feeling that the automated tools has some countermeasures to this type of “security”. If I were to build an automated tool, and knowing many login systems limit attempts with cookies, I’d make it clear the cookie after each failed attempt.

Could logging the attempts into a db table be a strengthening? I don’t know how that could be done well, though. IP-only could block out a huge institution, school, etc. And combining it with user agents it pointless since it could be randomized from the automated tool (?). Well, I don’t know.. like I said, just curious 😊

If I took into account everything that could happen, The Authentication Library would become bloated against every single possible security caveat. I have seen many brute forcing tools and none of them have been able to clear a cookie. Of course it’s still totally possible but less likely. I’m sure there will be a way to make this more secure without increasing overhead, and when I find it be sure that I’ll include it in The Authentication Library.

How secure & what would be the overhead of implementing a system that disregards the IP address to prevent problems such school’s, apartments etc when preventing brute force and uses the user name instead and has a failed attempt counter in the database, so after that user fails so many times he’s locked out regardless of which IP it was from, which also secures against bots that are using proxy’s / changing ip’s…

How secure & what would be the overhead of implementing a system that disregards the IP address to prevent problems such school’s, apartments etc when preventing brute force and uses the user name instead and has a failed attempt counter in the database, so after that user fails so many times he’s locked out regardless of which IP it was from, which also secures against bots that are using proxy’s / changing ip’s…

The only problem I can see with this is that when the actual users comes to login and are told they are locked out, they won’t be too happy and they’d also have to contact the site owner to get their account reinstated. Then there is also the fact that in many cases a brute force dictionary attack would be used on many of the usernames, how would you feel if all your user accounts were locked out and you had to put them all back?

If anything comes up that makes The Authentication Library significantly more secure then I’ll implement it.

Hey Adam Why not do also a PHP session check to see how many attempts were made? wouldn’t that also be secure?

Also, dunno if this is fixed yet but

if($system_group === $CI->session->userdata('group_id'))

should be

if($system_group === $CI->session->userdata('group'))

File: auth_helper.php

love your stuff btw, groups and handling profiles are gunna be a bit messy but the login system seems awesome.

Hey Adam Why not do also a PHP session check to see how many attempts were made? wouldn’t that also be secure?

Also, dunno if this is fixed yet but

if($system_group === $CI->session->userdata('group_id'))

should be

if($system_group === $CI->session->userdata('group'))

File: auth_helper.php

 

love your stuff btw, groups and handling profiles are gunna be a bit messy but the login system seems awesome.

Yeah that’s fixed in the Github repo.

Thanks. I’m going to do group handling in one of the next versions with ACL.

Thanks.

I was actually going to code my own auth library until I saw this.. now it’s just getting even better because of the ACL feature (that is one of the features I’d like to see in a auth library). Did you start code the next version yet?

I was actually going to code my own auth library until I saw this.. now it’s just getting even better because of the ACL feature (that is one of the features I’d like to see in a auth library). Did you start code the next version yet?

Yes some of the code has already been written. It’s still going to be a while though because I have some projects that are going to take up quite a bit of my time. But it’s coming and when it’s here you’ll love it!

Thanks.

Okay, thanks - I’m looking forward to it!