Welcome Guest, Not a member yet? Register   Sign In
The Easiest Authentication Library for CodeIgniter just got easier.
#51

[eluser]Adam Griffiths[/eluser]
[quote author="Skinnpenal" date="1242510833"]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?[/quote]

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.
#52

[eluser]Skinnpenal[/eluser]
[quote author="Adam Griffiths" date="1242534273"]
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.[/quote]

Thanks for the reply Smile

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 Smile
#53

[eluser]Adam Griffiths[/eluser]
[quote author="Skinnpenal" date="1242577167"][quote author="Adam Griffiths" date="1242534273"]
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.[/quote]

Thanks for the reply Smile

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 Smile[/quote]

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.
#54

[eluser]shenanigans01[/eluser]
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...
#55

[eluser]Adam Griffiths[/eluser]
[quote author="mikem562" date="1242579013"]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...[/quote]

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.
#56

[eluser]Dregond Rahl[/eluser]
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

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

should be

Code:
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.
#57

[eluser]Adam Griffiths[/eluser]
[quote author="Dregond Rahl" date="1242581668"]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

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

should be

Code:
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.[/quote]


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.
#58

[eluser]IamPrototype[/eluser]
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?
#59

[eluser]Adam Griffiths[/eluser]
[quote author="IamPrototype" date="1242600877"]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?[/quote]

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.
#60

[eluser]IamPrototype[/eluser]
Okay, thanks - I'm looking forward to it!




Theme © iAndrew 2016 - Forum software by © MyBB