SitePoint Sponsor |
|
User Tag List
Results 26 to 32 of 32
-
Aug 4, 2009, 13:18 #26
- Join Date
- Sep 2004
- Location
- Norway
- Posts
- 1,198
- Mentioned
- 4 Post(s)
- Tagged
- 1 Thread(s)
We do not really know how Cups handle the system.
Keeping in mind what we know about similar systems, its very simple to create a major security issue using an approach like that.
The user logins in with his user details and get assigned a cookie. Then the user will need to enter the pin number. We also know that if the user has the cookie already set he will just need to enter the pin number.
This leaves a potential huge security hole if someone get a hold of the cookie from a user, which depending of course can be simple enough depending on how the site works etc.
Lets say someone has managed to get a hold of an users cookie. They can now populate it and try to enter a pin number. The entire security issue lies in how the system handle the failure if the user enter a wrong pin number.
If the system just deletes the cookie, then there is nothing stopping me from applying a low key brute force system and have the real pin code in less than a day or a do a normal brute force and have the real pin code in a hour or two as long as the server dont crash. Of course a low key brute force system is what I would have gone for due to the chance of someone noticing that is very slim.
The only way this kind of a system can work is, in the event you add a custom "IV" that is randomly populated each time you create the cookie and stored in the users row in the database. By using the initialization vector together with the username for example to create an hash (md5 is fine for this, its fast and more than secure enough in this case) that you store in the cookie.
This hash is again used to "notice" and let your users bypass the first login process, but if they fail to enter the correct pin you change the IV and by that make the cookie invalid.
It would be nice if you could elaborate and explain a little on how you have set this up Cups.
-
Aug 4, 2009, 21:16 #27
- Join Date
- Jul 2009
- Location
- Toronto, Canada
- Posts
- 9
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think that Using MD5 with salt is very secure.
-
Aug 4, 2009, 21:41 #28
- Join Date
- Sep 2004
- Location
- Toronto
- Posts
- 795
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
One thing that I do is setup the admin folder as
/---admin---/
Then, obviously, password protection is also used. Since the subfolder is prefixed with a hyphen, in the robots.txt file, I then set a rule like so:
Disallow: /---*I can't believe I ate the whole thing
-
Aug 5, 2009, 01:20 #29
- Join Date
- Oct 2006
- Location
- France, deep rural.
- Posts
- 6,869
- Mentioned
- 17 Post(s)
- Tagged
- 1 Thread(s)
Hi,
I originally set this up for an intranet and it proved really popular because people hardly ever got their pin number wrong.
I evolved it so that just one wrong PIN attempt kills the cookie, so then users have to go back to the 3-token input screen.
The fatal flaw you have helped me identify is that IF someone were to have their cookie stolen, then even if the attacker did get the first attempt wrong, they could go on and send in spoof headers unabated.
So imagining I have killed the cookie is not enough I should set a flag on the backend which changes the password and effectively locks the account if the cookie is submitted more than once.
That'll be pretty easy to do as I already have a bad_logins table.
-
Aug 5, 2009, 06:55 #30
- Join Date
- Apr 2002
- Posts
- 2,322
- Mentioned
- 3 Post(s)
- Tagged
- 0 Thread(s)
at the risk of appearing a complete moron, what's wrong with apache's built in standard password mechanism?
-
Aug 5, 2009, 13:18 #31
- Join Date
- Oct 2006
- Location
- France, deep rural.
- Posts
- 6,869
- Mentioned
- 17 Post(s)
- Tagged
- 1 Thread(s)
In my case passing the authentication test also provides access control to applications, albeit very simple.
-
Aug 5, 2009, 15:46 #32
- Join Date
- Mar 2008
- Posts
- 1,149
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I don't name the folder "admin," for one.
What I do have, and not just for admin logins, is a max number of tries before a CAPTCHA is shown, and after another threshold, there is a lockout.
Bookmarks