echo "hey, it works" > /dev/null

just enough to be dangerous

Jeremy Keith—The password anti-pattern


... asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable

Adactio: Journal—The password anti-pattern

Jeremy Keith's password anti-pattern post came across my radar again recently. This was written almost 21 years ago in Internet time (2007), and it's still an issue today, even with the growth of OAuth as an alternative.

We should start a shame file. I've only just signed up for it, and it looks like it might be really useful, but the first entry is Dropbox.

dropbox using the password anti-pattern

Update your Habaris !


Habari 0.5.1 has been released. This is a security fix and you should update immediately if you're running 0.5. If you're running trunk, you should svn up, making sure you back up your data if you haven't updated for a while, as we recently merged some significant schema changes for the upcoming 0.6 release.

WordPress security: that's a long queue, do I really have to stand at the back?


You should never ever modify core files in WP. If you find you have to, file a ticket for a new hook or filter so your modifications can be a plugin — it makes things so much easier.

The security report may well be bogus, and Matt gives some reasonable advice for avoiding security issues, but I think this is a bit rich. Never ever. Emphasised. Okay, go and open a ticket, it will all be fine. I'm fairly sure that the WordPress terms of service (no, no, we're talking about the self-installed software, don't go looking at the WordPress.com terms of service) don't say anything about guaranteeing tickets are addressed in X days. Of course they don't, Automattic is not a support company for self-hosted installs unless you want to pay for "enterprise-level support for large-scale users".

As of this writing there are 944 open tickets, dating back to the start of 2005. Many of those are enhancements, some trivial, some critical. What's going to happen to your ticket? If it's a critical security or data loss issue, it may well get addressed immediately, as I'm sure the original SQL injection attack ticket would have been if there'd been more information, and if it actually exists. Those don't come up very often, and it's likely that it will take a while before your ticket gets addressed. Maybe I'm wrong, and requests for hooks or filters do get addressed immediately, but then you either have to be running out of the subversion trunk or wait for an upgrade anyway.

Now, I am absolutely not criticising the fact that there are lots of open tickets. That's the way things happen in open source software, and to a certain extent it shows the software is a success. But it is unreasonable to suggest that just because you've opened a ticket the problem will go away and you'll never have a reason to change core code.

Why 'Anonymous' Data Sometimes Isn't | Bruce Schneier


Using public anonymous data from the 1990 census, Latanya Sweeney found that 87 percent of the population in the United States, 216 million of 248 million, could likely be uniquely identified by their five-digit ZIP code, combined with their gender and date of birth. About half of the U.S. population is likely identifiable by gender, date of birth and the city, town or municipality in which the person resides. Expanding the geographic scope to an entire county reduces that to a still-significant 18 percent.

Gravity never sleeps (notations that use eval) | Michael Sperberg-McQueen


JSON makes very good use of Javascript’s literal object notation. But it’s a consequence of this fact that a JSON message can conveniently be processed by reading it into a variable and then running eval on the variable. [...] The moment you do this, of course, you expose your code to a Javascript injection attack.

I'm really enjoying Michael Sperberg-McQueen's klog. I hope he keeps it up.