Talk:Security issues with authorization extensions
Proposed table of extensions & which flaws they pass/fail
Good idea to make this list. There was an old one similar to this. We could create a table showing if and how each security extension handles this issues. --Fernando Correia 19:46, 23 February 2007 (UTC)
- I've added which ones my Extension:Simple Security fails - I know how to fix them all since we've dealt with all those on our own hiddeous hack of a wiki (OrganicDesign:XmlWiki), so I'll slowly incorporate the fixes into Simple Security. --Nad 00:20, 2 March 2007 (UTC)
Proposed template for security extension's info pages
A template similar to Template:Extension could be used, say Template:Security extension, which could have parameters for which of the flaws it passes and fails. The template could also have a message saying something like:
- --Nad 03:21, 3 March 2007 (UTC)
Good idea, but who's going to do the auditing? Also, not only authorization extensions expose security flaws - especially, parser hook extensions are prone to be vulnerable to HTML injection, opening the wiki to XSS attacks. I have been thinking about a Template:security alert, and perhaps a toned down version, Template:security advisory. Not sure if/how this should be combined with what you propose. -- Duesentrieb ⇌ 10:58, 3 March 2007 (UTC)
There should be different "security levels"
- 1) Intranet - Edit permission
- If the content is "read only" and just needs to be protected against changes.
- 2) Intranet - read permission
- If the whole content needs to be protected.
- 3) Internet - protection against advanced hacking attempts
In the case of 2) and 3) I kind of favor the idea of RSA-crypting of the content, which I think is easier to implement. Most security breaches will retrieve the content, but would not help much, if the content is crypted.
--GunterS 11:36, 3 March 2007 (UTC)
- Hm, why do you think stuff in the intranet does not have to be "so secure"? Insider attacks are generally much more serious - because insiders know what to look for (or what to change), and where.
- Encrypting the data would not help to stuff remaining holes - in oder for MediaWiki to function, it needs to be able to access the decrypted data. So, if someone can query the decrypted data, anyone can (that's the nature of the security leak). The only thing encryption would protect against would be people looking at the database directly. And if you are able to do that, it's also likely you can find the place where the decryption key is stored, rendering the whole scheme pointless.
- Sure, you can have people manually encrypt and decrypt all pages they want to view or edit, so their key never leaves their box. But that would be so cumbersome, it would render the wiki useless if done for anything but a few pages. -- Duesentrieb ⇌ 15:56, 3 March 2007 (UTC)
What about api.php access restrictions ? is it possible to access a page's content using that and bypassing any "inwiki" restriction ?
Darkoneko 09:22, 4 July 2008 (UTC)
- It should not -- if it is, that's a bug in either the extension of the API code. Extensions using the UserCan hook should be fine, if it's possible to circumvent UserCan using the API, that's a bug. -- Duesentrieb ⇌ 13:12, 4 July 2008 (UTC)
- Okay, thanks ^_^
- Darkoneko 14:12, 4 July 2008 (UTC)
Philosophy of openness
There seems to be a bias against wikis wanting to have much functionality for restricting some access but not other access. I.e., not only do people point out that MediaWiki doesn't currently support such functionality, they seem to suggest that MediaWiki shouldn't support such functionality.
While it would be great if information could be free, the fact is that there is a lot of censorship out there. E.g., a lot of hosts will take exception to certain content if its public availability would attract controversy. There are all sorts of threats that can be brought to bear against hosts, such as economic ostracism, frivolous but costly lawsuits (especially in jurisdictions that use the American rule), unwelcome regulatory attention and investigatory scrutiny/harassment from the government, and even threats of physical violence in some cases.
One way to make that less of an issue is for a wiki to restrict public access to controversial parts of the site, e.g. by only making that content available to logged-in users. That way, the community's members can "go underground" and talk freely, without having to worry so much about outsiders raising a fuss and trying to get the plug pulled. At the same time, the wiki may wish to have a public part of the site that contains non-controversial information.
In some situations, it's not a choice between completely open, public communication and restricted communication. It's a choice between restricted communication and no communication. So, I think it is good to encourage the development of security measures that will enable these underground communities to collaborate efficiently without making their content available to everyone. Leucosticte (talk) 14:08, 12 September 2012 (UTC)