How about putting the wiki password in an image or SVG file?

Jeremy C. Reed

BSD News, BSD tutorials, BSD links http://www.bsdnewsletter.com/

Alan Horkan wrote:

On Tue, 1 Feb 2005, Jeremy C. Reed wrote:

I dont know if we have any users of accessibility technology (or lynx for that matter) helping out but if we put the password in an image then we definately wont in future.

Reading a passphrase from an image every time is far worse a likely to discourage contributions than needing to register once.

Why decide between these? Offer registration for hassle free editing/the visually impaired[0]/lynx users[1]. Less regular wiki users who'd be put off by the need to register can use a simple image CAPTCHA, and spammers can head somewhere else.

John

[0] I'm thinking a graphical SVG editor will have fewer of these than most gnome applications.

[1] Apparently these are suspicious, and probably hackers anyway: http://yro.slashdot.org/article.pl?sid=05/01/28/031248&tid=172&tid=1...

All of the suggestions in this thread are viable options, although some will require more work than others:

* Changing the password: Trivial, easy to do * Blocking more IP's: Trivial, easy to do * Adding basic auth login: Requires sysadmin work + ongoing account admin * Adding adv. auth login: Requires perl or php coding + sysadmin work * Randomizing password: Requires a little perl coding * Randomized image: Requires more perl coding * Changing wiki's: Requires sysadmin work + lots of content conversion

I would be happy to change the password but I think that'll only be a temporary fix. Several people have admin access for banning IP's. I assume the IP's are already banned now; if not then we probably need more wiki admin's.

For the other options, if someone else has the time to do it, and is willing to do it within certain guidelines, that might give us a longer term fix.

I like Mental's idea of getting a better feel for what's going on, although honestly I sense that we're just in a war of escalation, so whatever we do, the spammers will catch up eventually.

FWIW, we're also getting a larger amount of spam to the mailing lists than normal; fortunately mailman catches most of it, so I just go through and discard it each morning. I don't know if this spam and the wiki spam are related, but it's curious that both got significantly worse within the last week or two.

Bryce

On Tue, 1 Feb 2005 mental@...3... wrote:

Quoting bulia byak <buliabyak@...400...>:

...

It looks like 82.194.62.17 and 193.188.105.16 automatically spam our wiki, they spammed pages minutes after my reversals. I reverted them several times, but then quit, so they're likely spammed again now.

...

Maybe it's time to change the password, make it random for each page, and less easy to extract from the text. And in any case, please ban those IPs.

I would be very curious to see what happened if we simply changed the password but left the IPs unbanned. Depending on how quickly (or if) the board is respammed that will give us some idea how the attack is being performed -- i.e.:

Is it parsing the page for the password?

Has the spamming software been manually adjusted for the site?

Are we being specifically targetted?

It might be nice to add a feature for "blackholing" IPs as well -- i.e. accept the submission, but log the attempt and don't update the actual wiki page.

I think collecting hints towards this information would be very helpful.

The point is that blindly making changes may not be the best use of resources; it's better to gather some intelligence about the specifics of the attack (rather than guessing) and focus our efforts accordingly.

-mental

---

This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Tue, 1 Feb 2005, John Pybus wrote:

Bryce Harrington wrote:

...

All of the suggestions in this thread are viable options, although some will require more work than others:

• Changing the password: Trivial, easy to do
• Blocking more IP's: Trivial, easy to do
• Adding basic auth login: Requires sysadmin work + ongoing account admin
• Adding adv. auth login: Requires perl or php coding + sysadmin work
• Randomizing password: Requires a little perl coding
• Randomized image: Requires more perl coding
• Changing wiki's: Requires sysadmin work + lots of content conversion

Changing the code to add rel="nofollow" to links, should also help discourage spammers by making their links worth less. See:

http://www.google.com/googleblog/2005/01/preventing-comment-spam.html

Of course this also means links people post to the wiki stop counting towards search rankings, but it may be a price worth paying.

Actually, we already have the robots.txt file stopping indexing entirely, but that hasn't stopped the spamming. Converting to the rel="nofollow" approach would be better in that our wiki would get google indexed, but spammers still would not get credit. On the other hand I doubt it'd make any impact on the quantity of spam (I expect spammers are ignoring both robots.txt and rel="nofollow".) But if anyone would like to implement this, go for it, it's a good idea.

Bryce

mental@...3... wrote:

Quoting John Pybus <john@...368...>:

...

Changing the code to add rel="nofollow" to links, should also help discourage spammers by making their links worth less. See:

http://www.google.com/googleblog/2005/01/preventing-comment-spam.html

Of course this also means links people post to the wiki stop counting towards search rankings, but it may be a price worth paying.

It might be appropriate, but are spammers likely to notice?

Sadly, not in the short term - I don't expect they pay enough attention to individual wikis :-( In the longer term, if widely taken up, it'll make a difference to the attractiveness of wiki spam in general.

John