« Nexus 7
PHPSESSID Brute force
The Humble Indie Bundle V »

MultiformeIngegno

  • Posts: 1,337
Re: PHPSESSID Brute force
« Reply #15, on August 22nd, 2012, 10:53 PM »Last edited on August 22nd, 2012, 11:12 PM
Quote from Arantor on August 22nd, 2012, 08:58 PM
I'm not sure, though, whether the same risk is also applicable to session_id() or not, if it is there's a much bigger problem.
It is according to the words of the guy who gave me that link.
Quote from Arantor on August 22nd, 2012, 08:58 PM
That's what I mean. If someone brute-forces in the manner you're thinking, they're going to generate an obscene number of requests and even the most inept host is going to notice that. But with this technique, session stealing is potentially within the region of requests where hosts may or may not notice it.
It's not a solution or a thing to be reassured of. Security can't rely on actions taken by other persons (maybe).

What's the /dev/urandom thing?

EDIT: Ok, I read about urandom.. seems it's the maximum security method, but it's very likely slow, isn't it? It gathers all environmental data + the use of PRNG..

nend

  • When is a theme, no longer what it was when installed?
  • Posts: 165
Re: PHPSESSID Brute force
« Reply #16, on August 22nd, 2012, 11:08 PM »
Quote from Arantor on August 22nd, 2012, 10:52 PM
Quote
Can't you just check the IP address and see if it matches the one in the session
For the second time... no.

Take one IP address, a couple of time stamps, md5 the lot. Now please tell me how you extract the IP address from this.
You can always save it in the session vars. :whistle:
SI Community

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Pandos

  • Living on the edge of Wedge
  • Posts: 635
Re: PHPSESSID Brute force
« Reply #18, on August 23rd, 2012, 10:27 AM »
So what about the php build in session_regenerate_id() funktion?


Perhaps not the perfect solution but it will be more difficult to fix an session.


What do you think?
# dpkg-reconfigure brain
error: brain is not installed or configured

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #19, on August 23rd, 2012, 02:51 PM »
I already actually hinted at this in my thoughts above. The session id is still generated in the same manner and is thus still vulnerable.

There are certain actions that already call session_regenerate_id() exactly as it should (logging in, logging out, admin validation) but there's only so frequently you can call it before things get messy and you end up with session timeouts.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: PHPSESSID Brute force
« Reply #20, on August 23rd, 2012, 03:06 PM »
Quote from Arantor on August 22nd, 2012, 10:52 PM
For the second time... no.

Take one IP address, a couple of time stamps, md5 the lot. Now please tell me how you extract the IP address from this.
Going to play dumb here...

- We have the last login IP in the members table
- We have an associated PHPSESSID, right...? (If not, we can record it.)
- We know that some people might want to break the ID... But they don't have the same IP. Why not force IP changes to confirm the password or something?

Pandos

  • Living on the edge of Wedge
  • Posts: 635
Re: PHPSESSID Brute force
« Reply #21, on August 23rd, 2012, 03:09 PM »
Sometimes poeple have the same IP:
like Proxys and Networks (AOL)...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #22, on August 23rd, 2012, 03:18 PM »
^^ This. The IP should not be trusted for any such thing.

The best one is for intranets where potentially every user has the same IP address.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: PHPSESSID Brute force
« Reply #23, on August 24th, 2012, 12:43 AM »
Still reduces chances of session hijacking by 99%...
We don't need a solution for everything. We just need stuff that helps.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #24, on August 24th, 2012, 02:29 AM »
Using IP binding might stop 99% of session hijacks. It also just happens to screw up a significant proportion of legitimate users too, enough that you don't want to have to deal with the 'it's broken' support reports.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: PHPSESSID Brute force
« Reply #25, on August 24th, 2012, 08:10 AM »
Why would they be screwed I we just ask them to confirm their password, like in the admin area?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #26, on August 24th, 2012, 02:34 PM »
Because you'll have users whose IP changes pretty much every request. Which means every other page they see will be a password confirmation one... yay.

Then you'll get complaints of 'it's not remembering my password', which means people will be throwing bugs left and right when it's working entirely as designed, but that doesn't mean it's the *right* design.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: PHPSESSID Brute force
« Reply #27, on August 24th, 2012, 06:21 PM »
Again, you party pooper :P

- We don't give a damn about guests having their PHPSESSID stolen, of course.
- There remains the issue with members...
- Can you quote a single case where someone would change their IP all of a sudden while browsing? It would definitely disrupt more than one site...
- How 'bout accepting an IP change in the same range?
- And if we provide this as an option, disabled by default, it's a win-win situation...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: PHPSESSID Brute force
« Reply #28, on August 24th, 2012, 07:42 PM »
Quote
- We don't give a damn about guests having their PHPSESSID stolen, of course.
Correct.
Quote
- Can you quote a single case where someone would change their IP all of a sudden while browsing? It would definitely disrupt more than one site...
AOL users. Mobile users. People intentionally changing their IP address to fool stupid proxy blockers or some types of ban.
Quote
- How 'bout accepting an IP change in the same range?
Depends on the range. Some of the above need different sizes of range to others.
Quote
- And if we provide this as an option, disabled by default, it's a win-win situation...
I don't think it is a win-win situation. There are enough people that mess around with harmless settings in SMF and cause trouble and need support. Give them something that could potentially lock them out, that they can only fix by phpMyAdmin? No chance.

Nao

  • Dadman with a boy
  • Posts: 16,080
Re: PHPSESSID Brute force
« Reply #29, on August 25th, 2012, 12:14 AM »Last edited on August 25th, 2012, 07:55 AM
- Range can even be country-based... (Or continent-based if you want. I already rewrote the list of all these IP ranges a couple of months ago for the IP tracker page, we could reuse that for IPv4 IPs!)
Since most spammers are from a different country than the 'expected one', it could be an okay solution. After all, do you know of many people who would move to another continent while their session is opened..? :P

- Thing is, you tend to go a bit much these days for what seems to have become your favorite Wargames quote (and yes it's also one of my cult movies :P), I'm sure you know what quote I mean, but if we keep deciding not to do something, we'll just end up doing nothing at all... SMF died out for years because people were too afraid to rework it!

I'll whip up a quote of my own then...
It's better to have coded and gotten bugs[1], than never to have coded at all.

:edit: Oh come on, that oneat least warrants a Like! :P
 1. I'm not talking about crabs, you naughty naughty boy!
« Nexus 7
The Humble Indie Bundle V »