Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arantor
2896
Other software / Re: More thoughts on SMF 2.1
« on August 23rd, 2012, 04:07 PM »
Yup, everything goes in cycles.

Arial looks good right now, though I do understand exactly what you're on about with fonts getting boring. I'm not a designer, so I don't really know what to suggest.
2897
The Pub / Re: Getting ready for an alpha release...
« on August 23rd, 2012, 03:24 PM »
I'd leave database changes for now, ultimately. You're right that it's very complicated.

As far as upgrading goes, I really wouldn't bother worrying about it for the alpha. Anyone that uses an alpha should be prepared for anything and everything, including manual DB changes, and shouldn't be using it on a production site anyway.

I'd suggest just committing the changes to Aeva and Subs-BBC. Most things work as expected at this point in time. (Though it would be nice if we can get Aeva to use the no-cookies version of the YT embed code, and ideally using the iframe method rather than a Flash object)
Quote
Do we want to encourage competition for people to get more likes..?
That is going to be dependent on the community. There was a thread on AAF discussing the fact that I had a lot less posts than Shawn and yet more likes. If the community notices enough to care, they'll figure out whether they want to make it competitive.
Quote
- shall I count theme users per skin or per theme in the Skin Selector page? It only involves replacing "id_theme" with "id_theme, id_skin" in the SQL query for that -- but it might not help when it comes to performance...
Change it, that's cool. We can worry about performance later.
Quote
- shall the board icons be set to 'New' status if there are new topics in the corresponding board, or new topics in the corresponding board *and* its children...? Currently it's the latter, but I think the former would be best, if only because sub-boards have their own 'New' label...
That makes sense. It would solve a lot of troubles.
Quote
- just for the record: I'm currently reworking (quite heavily) the layouts for the Search page and Media page (homepage mostly). And I'm totally not happy, and I totally need to commit before we go alpha...
That's the beauty of being an alpha, it doesn't have to be ready in any fashion.
2898
Off-topic / Re: PHPSESSID Brute force
« 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.
2899
Off-topic / Re: PHPSESSID Brute force
« 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.
2900
Off-topic / Re: PHPSESSID Brute force
« on August 22nd, 2012, 11:13 PM »
Not in Wedge you can't.
2901
Off-topic / Re: PHPSESSID Brute force
« 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.
Quote
but maybe you can ignore the session information and create a new one like if they didn't have a session to begin with.
Sure you can but that's not really the point.
2902
Off-topic / Re: PHPSESSID Brute force
« on August 22nd, 2012, 08:58 PM »
OK, here's the deal. If an application relies on PHPSESSID to handle sessions for anything of any 'security', you're screwed because you can spoof a user's session - right up to taking over a user's session while they are logged in.

In our case, PHPSESSID is only used for guests, so should a session be spoofed, there's no immediate risk.

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.
Quote
But the thing is, once you get a forum up and running... Are you spending your time checking for weird session behavior? I would bet not...
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.
Quote
Well, it's useful for me: (1) spotting what could be a bot
Unless you've hacked it to also display the user agent, the odds of being able to tell a bot just by what they're 'browsing' are going to be slim.
Quote
(2) spotting links that shouldn't be accessible to guests and yet are being accessed,
Have you noticed any?
Quote
(3) generally determining whether my host is cutting my access because I have too many regular users (like, was I mentioned on a high-profile blog?)
I suppose there is some merit to that, but you don't need to do that by tracking sessions. Using the access log will give you the same general information.
Quote
Well, I'm certainly accessing the Who's page more often than the intrusion log.
Yes, but what does it actually tell you?
Quote
At minimum I usually have four to six servers handling request. I also wonder how these sessions work in this setup. Is there some sort of syncing going on between them that they somehow look like one system.
I don't know how your system is set up, but the conventional way to set this up is to push the sessions to a single shared resource, and load/save sessions from there, for example I've done this in the past using MongoDB to be a session store, across multiple systems.
Quote
No matter, it looks like session ids are predictable. What does this actually mean being able to guess a session?
If you can guess a session id, you can theoretically spoof that session. It's a form of session fixation bug.
Quote
Thinking about hijacking sessions even if your able to spoof another networks IP address the server isn't going to send you anything back and plus you don't have a cookie.
That's the point: you do not have to spoof the IP address. The IP address is merely a component of the hash, you don't have to actually be on that IP address, because it's a *hash* and thus the IP address is not recoverable.

This is why it's important: spoofing a session just relies on you being able to figure out the session id. Creating a cookie is a piece of the proverbial, it's just a header attached to the request. Fortunately in Wedge's case you do need to know what the contents of that cookie are, and it's a bit more than just the session id, so it is physically harder to spoof. But not impossible.
2903
The Pub / Re: RSS feeds (Was: Some admin options required)
« on August 22nd, 2012, 08:26 PM »
Quote
But, if the boards are inaccessible, surely the links are as well...? (Unless you mean they're shown in the sidebar even though one gets a "Board doesn't exist" error...?)
No...

Right now if you can see a board, you get the RSS feed as you should. But that wasn't what I suggested doing. I was suggesting hiding the RSS links if the board is not visible to guests. If the board is not accessible to guests, there's no need for RSS feeds as it currently stands.
Quote
Obviously, we'd have to reload the user yes.
Well, that's the thing. We can either fully reload the user, or we can intercept the request and attempt to load the user up front if that makes sense.
Quote
Which implies that one would want to supply Google with their username & password for a site...? I certainly wouldn't. But I would be perfectly fine with providing it a custom key for reading private boards. As long as no one at Google can actually get access to my account with it...
Of course they can. It's inserted in plain text in the URL as standard...
Quote
ORLY...?
Well, the session is loaded, the user account updated, but the main online log won't be. Since the session is loaded up front, even PHPSESSID sessions are invoked.
2904
The Pub / Re: RSS feeds (Was: Some admin options required)
« on August 22nd, 2012, 06:57 PM »
Quote
It would make sense -- as long as we provide a way to access these boards through a URL key representing the requesting user...
I was purely talking about icons and hiding links on boards that aren't accessible.

To implement this is massively more complicated because it requires either fudging and re-calling the loading of the user (to re-handle board access) or doing it all manually. It's not pretty, anyway (and either way has performance issues), the other option is to intercept rsskey or whatever in the user loader and do it that way but even that's a check that would have to be performed for every guest on every page load since user authentication is done before almost anything else.

The alternative is to support username/password the way Google Reader etc supplies it, which is in the URL through the proper username/password parameters, but even then we still have to deal with authentication early enough. Perhaps only doing it when feeds are requested and there isn't a cookie (the circumstances that would be applicable for such things)

Side note: there's another case where sessions are used but shouldn't be, since someone requesting an RSS feed would still be online IIRC...
2905
Off-topic / Re: PHPSESSID Brute force
« on August 22nd, 2012, 06:46 PM »
Quote
OTOH, anything with a ID less than 2 million bytes long will be guessable by brute force... It's just that something was discovered that makes it faster to brute force.
Brute forcing a couple of billion combinations is sufficiently big it's going to be noticed. But if you can do a much smaller number of requests and be able to understand how mt_rand is going to be seeded, you can access sessions with a much, much lower number of hits, probably enough it's going to get under most radars.
Quote
So, the alternative would be..? Storing a log of all recent guest requests, along with IP and requested URL? Otherwise, what are we gonna show in whosonline..?
Which is the sticking point of the argument. I do not believe who's online is actually that useful for guests, and I have long believed this to be the case. But there are enough people that seem to believe it actually tells you something meaningful that it made me want to leave it alone.
Quote
I do care (a bit) about stats, I check them at least every once in a while (like, 6-7 times a year), and yet if I suddenly found myself without any non-member stats, I'd be quite upset...
But what would the theoretical number of visitors (which is going to be inaccurate by anything from a few percent to potentially an order of magnitude) actually tell you?
Quote
it's okay for websites that sell you something, I guess, but we're talking about a forum system... GA will only make it slower.
*shrug*
2906
Off-topic / Re: PHPSESSID Brute force
« on August 22nd, 2012, 05:04 PM »
Quote
- If PHPSESSID being 'guessable' is the problem, then it's also a problem when it's stored in a cookie. Meaning, we can't have guest sessions AT ALL. Of course I'm not sure at which point we're using sessions for guests, but still..?!
It is a problem but it's not the problem you might be thinking of.

If session ids are guessable, and can be brute-forced, they can be brute-forced for session spoofing. Delivery method of that makes no difference.

As far as using sessions for guests, the answer currently is all the time. Every request either creates a new session or perpetuates an existing one, with the intent to try and get an idea of the number of 'unique' browsers.

That alone is made farcical by search engines that send multiple instances of bots at the same time.
Quote
- Guest count is important to me, although I agree that it's unreliable at best (if only because there are countless unnamed bots over the web.) But I can already see people saying, "ever since I installed Wedge, my forum's visit count has dropped by 1857%! This is an outrage to SEO gods!"
Anyone who really cares is going to install an analytics package anyway, which is probably more reliable than Wedge doing it itself, if nothing else it will be excluding bots.
Quote
- And yes, I have this annoying tendency to forget about earlier topics... So many things we discussed in the past. So many features/ideas we decided to implement, but none of us added it to a to-do-list, and it gets forgotten forever etc...
You and me both. It's just something I was pretty adamant about... ;)
2907
The Pub / Re: Print Page
« on August 22nd, 2012, 04:16 PM »
Quote
Why?
If the prev/forward navigation relies on robot_no_index, something's wrong because it shouldn't really be.
Quote
Yes, but you didn't finish your sentence...
Yes, I did, I just didn't qualify the subject of the sentence, seeing as how it was implied by the previous one. The rules around robot_no_index being added are those. (I had to modify it myself lately), and robot_no_index perhaps needs to be reconsidered.
Quote
Oh, yeah, right... So it's hidden in page 15 right? But if you use rare keywords, it'll still show it on page 1, which is better than no results at all (because of printpage not being available.)
Then again, if (and only if) Google's handling of prev/next works as expected on Wedge, then I suppose we can expect it not to need a printpage for that...
No... Google will still index all 15 pages normally. The actual problem is that printpage specifically fucks around with page canonicalisation by having content that isn't at the canonical URL. Even though it's nofollow'd, Google still follows it!
Quote
Heck, maybe it's already done that way... Because the topic just didn't show up in one go on my browser, it loaded progressively...
That's the point, it is NOT handled progressively. It is queried, pushed entirely into $context and then output. When I first went to the URL, it was actually blank.
Quote
I'd say, if mod_gzip and PHP are smart enough to catch the output buffer and gzip parts of it (I believe gzip is suited for chunk transmissions?), then it's not worth worrying too much about memory...
Except that you have to worry about memory when you do it like that.

Display does that somewhat bizarre process of having a callback per message specifically so that you can have truly massive messages or vast threads without any problems with memory_limit. Printpage does not do that, it just queries, pushes everything into $context before going to the template. On low memory configurations it's quite possible to overflow that on long threads.
Quote
Then again, I'm not exactly a server/Apache/PHP internals specialist, and I probably said something silly.
It's not silly at all. Let me explain how gzip works in relation to Apache/PHP, depending on what is responsible.

If PHP is set up to do it (and Wedge has that configuration option), it's done in PHP, and the total page output must fit in memory. This is why the DB backup feature is often more reliable if you don't gzip it, because you have more memory capacity to cope with the data, because you don't have to hold it all at once to gzip it.

If Apache is set up to do it, and not PHP, PHP just has to output its content back to Apache, and PHP just has to make sure that it doesn't run out of memory in whatever it's doing.
Quote
Same here...
Possibly, what we could do is, instead of directly showing the printpage version, we could hmm... Show a choice to the user: either print the current page, or print the entire topic, or show an archive of the topic for safe-keeping. Then we could handle all of them differently...
I'm not disputing the validity of such things. My point is that I don't believe it should be in the core by default. If admins want the ability to archive parts of the forum, that should be up to them.

The fact we get SEO benefits, plus streamlining parse_bbc a little, these are just nice side benefits.
Quote
Seems like maybe print could really be two plugins a "Save Topic" plugin for those who want to save a topic to send to someone, and a print plug for those who want to offer the option to print. Though really if the save version is printable then really only need a save topic plugin. Maybe even have different file output types depending what extensions the server has. Basic HTML, PDF for those that can ect ect.
Interesting approach. I had actually thought about doing so. I'm just not convinced that people actually use print-page for printing, and that as a result it isn't needed in the core by default.
2908
Off-topic / Re: PHPSESSID Brute force
« on August 22nd, 2012, 04:03 PM »
Quote
Can't we just store sessions per IP address? (Didn't we already have this discussion..?)
Yes and I explained why it's impractical. Especially since as part of that discussion I explained with great frustration why all the benefits of actually removing sessions for guests would be completely erased (as well as making them inherently unreliable) if tracking by IP were introduced.
Quote
And I don't understand that confusing page, really -- what exactly does it do in reality?
The secret behind PHPSESSID is that the session ids are supposed to be unguessably random. But if you can predict session ids you can hijack sessions without having to bruteforce every single session id.
Quote
And shouldn't this be a private topic?
*shrug* It's a publicly available page.
Quote
And PHPSESSID -- can't we just get away by changing the var name?
That's called security by obscurity, and it is at best a temporary workaround. It won't be hard even to automate that one.

On the other hand, if every single session went via our own handling, we could safely disable PHPSESSID and be done with it, though even then it's still going to be broken for users who don't use cookies and search engines that don't handle cookies are still going to screw around with the guest count, much as they do with every other forum system that doesn't use PHPSESSID and do it via the session.

Yet again, it's unreliable and we're still worrying about it :/
2909
The Pub / Re: Print Page
« on August 22nd, 2012, 02:44 PM »
Quote
So there are many reasons why the meta links wouldn't show up: either there's only one page in the topic (duh!), or it was access through a msgXXX or #new link, things like that...
Then the check that normally sets robot_no_index should be modified. The usual rule is that if there is random stuff in $_GET (i.e. other than topic) and/or if $_REQUEST['start'] is non-numeric (which is set up with msgXXXX for linking to specific posts, new for new items and is numeric if you're using conventional pagination)
Quote
And what matters is obviously bots only, here. I don't think that accessibility gurus would even kill anyone for not providing these meta links, because seriously... Who ever uses those?! Your browser has to support them, you have to show a special toolbar that takes room in the UI, etc...
I seem to recall it's pretty much only Opera that does with gestures on the browser side. It would be good on the bot side to paginate neatly though.
Quote
They index it, but it doesn't bring PR to the overall site, that's what you mean...? I guess the point here is simply to have people be able to reach your site through multiple keywords... (although reaching it through the printpage... Urgh!)
No. What it means is that it is indexed, but no PR is brought from the main site to the printable version.

In fact, it's worse than that, because the printpage version contains the entire thread and specifies the *first page* of the thread as a canonical version. Which pretty much screws up any real benefit it had in the first place.
Quote
Yeah, I've never really noticed that... Can you post a direct link please? I don't remember where that topic is
http://www.simplemachines.org/community/index.php?topic=200401.0

Print page actually works, but I dread to think what the memory limit is set to.
Quote
But that's the thing about printpage, the main point is not that it's printable, the main point is that it's savable... (saveable?)
I used to do that precisely on sm.org topics back in the day.
No... that's just a happy side-effect. The printable version was never intended to be used for that, it was intended to gather everything on one page for printable purposes, and also fix some other issues that float etc. would generate.

I'm still not entirely convinced this needs to stay in the core - other than archiving threads to send to people, I've never used the damn thing.
2910
Off-topic / Re: PHPSESSID Brute force
« on August 22nd, 2012, 02:43 PM »
Fucking wonderful. I'd note that if you were actually brute-forcing PHPSESSID you'd probably notice it.

What this suggests to me is that we should do exactly as I proposed some time ago - don't store any sessions for guests, meaning you never use PHPSESSID.