Great write-up about catcha's when implementing user authentication/management for PHP/web applications, especially because he explains why things should be done a certain way. The only aspect I am missing is why it is important to construct (especially) the credential verification logic as a combination of application logic and database query instead of just combining everything into a SQL query. I have seen constructs like

SELECT uid FROM users WHERE username='foo' AND password='bar'

My submission for the Month of PHP Security was published today. I implemented a new feature for Suhosin which allows configuration values (any data actually) to be encrypted using an encryption key specified in the php.ini configuration file. In addition to the patch I've written an article explaining the necessity for encrypting passwords in confguration files - especially in enterprise environments.

You, my loyal blog readers, are the first to learn about my newest creation: CSS history hack based user tracking . Everyone else will have to wait until my presentation at SIGINT tomorrow (sorry, it'll be in german by request of the organizers).

I had to reset my pentabarf password for the CCC, here's the confirmation E-Mail I received:

Dear ***,

Someone (probably you, from IP address 127.0.0.11)
requested a password reset.

To reset your password just follow the link where you can define a new
password:

<--snip-->

That's funny because 127.0.0.11 is a loopback IP address (originating from their own system).

By the way: http://events.ccc.de/sigint/2010/wiki/Fahrplan/events/3785.de.html (in german)

The chumPod is a music widget for the Chumby. This is no April's fools joke. Why would anyone create a music widget for the Chumby? Because I like to listen to some internet radio stations on my Chumby and always having to navigate through the chumby menus is very annoying. I would rather have that control "up front" as a widget. Sure, this does not exactly fit the chumby's "widget" paradigm - but it suits my needs.

The current version is barely more than a proof-of-concept. It looks rather ugly (I have no design skills at all) and doesn't yet have a configuration tool for widget configuration (internet radio stations are currently sort of hardcoded). I am working on implementing support for Firefly (or any other Roku Soundbridge Protocol compatible server).

The chumby widget page can be found here. The sourceforge project page is here. And the source code repository is located here.

Firefly is an open-source media player (iTunes for the poor). I've implemented a plugin that serves up a crossdomain.xml file: this allows Flash "applications" to use Firefly (for streaming music).

The source code is here. Place it in the src/plugins folder of the firefly sources and compile it like so:

  gcc -shared -o crossdomain_xml.so -I.. -I../.. crossdomain_xml.c

Well, I thought I had a novel idea while driving today; turns out someone else had already written (pretty much exactly) what I had in mind.

I refrain from having subversion repositories for my personal documents on a public ("root") server. I rather keep them in repositories on my home network. I don't like the idea of a (constantly exposed) internet-server containing all my documents. That's why there should be a second line of defense in case such a system is hacked. The "obvious" solution would be to use a cryptographic filesystem on the server that has to be mounted before the repository is accessed. However, that approach introduces a whole slew of technical issues (only root can/should mount, has to be manually dismounted, ...). Why not instead implement a new (or extend an existing) SVN backend that provides such cryptographic capabilities? Unfortunately, it looks like this can't be implemented as a source code patch (instead of a plug-in or extension).

On a side note: I recently stumbled across this SQL backend for Subversion (sadly it hasn't been continued and looks incompatible with current releases).

A log entry from my blog's log file:

XXX.XX-get-oneprice-adsl-for-only-R169.cybersmart.co.za

Some online storage (WebDAV) services provide mechanisms to share specific resources with others easily: usually, a link can be generated that allows access to the specified resource within the online storage (but can't be used to access any other resources). That way it's easy to share documents without having to create user accounts, set passwords and apply the corresponding ACL settings. It would be pretty cool if such a feature were to be implemented in mod_dav_svn (actually, mod_dav might be the more suitable module for this).

On another note: SVNIndexXSLT might be a good way to implement HTML output containing RSS feed links for this idea. The benefit would be not having to patch mod_dav_svn's source code (search for "gen_html") and thus to create an independant module that builds upon mod_dav_svn.

Update: As it turns out, using the SVNIndexXSLT is a no-go because there is no practical way to determine the current URL using XSLT in that context: the items in the xml document lack the basepath and unparsed-entity-uri() is not implemented in TransforMiiX (Firefox's XSLT engine) for determining the basepath later on. Sure, using the HTTP referrer on the server-side should work for most use-cases, but that's too hackish for my taste.

Too bad I didn't think of this earlier in the contest: the terms & conditions for the Palm webOS Hot App contest declare no restrictions about the type of app for the contest; I am sure that a "$5.000 Giveaway" app would have good changes of winning (by registering the most downloads). Of course, this money would only be paid if the app does win the contest itself (multiple winners should be drawn if this app would win any of the big $100.000 prizes).

There's a debate here in Germany about whether an IP address is a piece of data that can (or could) identify a person. This is an important question for the IT industry in Germany because of our stringent data privacy laws: storing and/or processing personal data requires the person's (prior) agreement. The current headlines revolve around Google Analytics but the general question is whether the established procedure of logging IP addresses is in line with the law.

What if IP addresses are declared as personal data? Two questions twirl around in my head:

1. What about other uses of IP addresses (like in dynamically generated firewall rules)?
2. What's a practical alternative to logging IP addresses?

While my first question is in fact to be taken seriously - albeit it's sort of funny to think about the implications. Hoever, I don't have any further thoughts with respect to question #1. I've seen several academic papers in the past with respect to question #2 but can't currently locate them - with one exception: Ulrich Flegel's paper about pseudomizing Unix log files using a modified syslog daemon (which has additional pseudomizing aspects like unix usernames and the like). My main issue is that the deployment of such a solution would be rather involved for most environments. My (rather easy to deploy) suggestion is a pseudomizing reverse DNS server; the web server would need to be configured to not log IP addresses but rather the reverse DNS name of the visitor (which is a standard configuration option for most servers). However, most webserver admins (understandably) shy away from logging reverse DNS names because of the potential for delays incurred by unsuccessful reverse lookups. However, if a DNS server handling reverse lookups was deployed locally then performance wouldn't be an issue. If this reverse DNS server served not the real reverse DNS name but rather a pseudomized DNS name then all the sudden we would have solved those legal concerns. Well, not quite: of course the IP addreses would need to be stored within the reverse DNS pseudomizer itself; however, I am sure that there are ways to design and operate such a device in that it would be considered compliant to the law (ie: access restricted to a designated privacy officer).

Yesterday I've stumbled across a tool Pit and I wrote a few years ago. In honor of his birthday I decided to devote a blog entry to this (don't worry: the technical details are quite interesting).

The scenario: we were facing issues in our production environment with a multi-process server application that binds an UDP port to a multicast address on HP-UX. Every now and than the system would stop processing messages sent to its multicast address. After quite some time we realized that this ocurred whenever one of the server applications processes terminated (ie: crashed). Since this server application was a service provider on the corporate/enterprise service bus it meant that that particular service was available in one less server (as in system) instance to the service bus whenever a process terminated. That could turn in to a real problem quickly, so we needed a solution that would allow a quick problem recovery until the real issue was fixed.

The problem: HP-UX 11.11 had a bug that didn't account for multiple "participants" (processes bound to the same multicast address). In other words: if you had multiple processes on the server that used the same multicast address and one of these processes terminates then HP-UX (incorrectly) instructed the network card to not listen for incoming packets to that multicast address any longer (well, the corresponding MAC address). The remaining server processes would keep on waiting for incoming packets but the network card just didn't want them any more. The theorectical solution looked easy: if a process bound itself on that multicast address then HP-UX would instruct the network card to listen to multicast packets again. The two obvious implementation alternatives weren't quite acceptable:

• restart the entire process tree -> a restart took too long
• start a dummy process that binds to the multicast address and puts itself to sleep (it must not terminate because that would reverse the intended effect) -> how many dummy processes would we have over the course of several months?

I would like to listen to podcasts while driving. I bought an iPod a few years ago and thought I would take it with me in the evening and sync-up podcasts for the next day's drive (my car has an USB connector suitable for iPods). However, I never developed a habbit of taking the iPod with me and thus it now contains only music.

I recently got an Android phone and that rekindled my desire to listen to podcasts on the road. I figured that it could automatically download podcasts and all I have to do is figure out a way to get the podcast played over my car's stereo. Connecting my phone to my car's USB port might work (I haven't tested that yet), but I don't want to have to fiddle with the USB cable every day (yes, I am lazy like that).

My preferred solution was to have the podcasts streamed over bluetooth to play on my car's stereo. However, my car only supports the HSF bluetooth profile (designed to trasmit voice calls to headsets) and not the A2DP profile (for high-quality music content). Thus, I would need to figure out a way to get Android to transmit the audio content via HSF to my car. I stumbled across various posts in which some people wrote about their own unsuccessful efforts to accomplish this. I remember one posts that contained a statement by some Android developer that only phone conversations are supported for HSF. It said something like "android does not support app processor generated audio data for HSF" (referring to the "main"/"app" CPU in the phone - instead of the "media"/"phone" processor which handles all phone-related processing).

While I do think that it should be plausible to hack something together for rooted Androids, I don't see that on my to-do list for now. Instead, I am currently investigating another solution: exploit the fact that my phone contract has a flat rate for calling land-line phone numbers. I am thinking of setting up an asterisk instance that I can call (phone call, not VoIP) and have it play back my podcasts. It would consist of two components: a web frontend for managing podcast subscriptions and the asterisk logic for handling incoming calls in order to navigate through the podcasts and to actually play them. Although this solution is not as technically challenging as hacking audio support for HFP for Android, it's probably the more appealing solution for others.

By the way: for those who are eager to investigate the bluetooth HFP implementation in Android, here are the relevant Android source files:

• ScoSocket.java
• android_bluetooth_ScoSocket.cpp
• BluetootHandsfree.java

Update: If your in Germany then check out http://www.phonecaster.de/ - it does exactly what I wanted to implement myself. I may not pursue my idea anymore...

Wouldn't it be cool if mod_dav_svn (the Subversion plugin for Apache) offered RSS (or Atom) feeds for repository entities? One could browse through the repository with a browser and easily monitor repository entities for changes via RSS. Subscribing to a directory entity should report changes to any contained entity.

I think that adding an additional URL handler like ".../!svn/rss/..." (similar to others like ".../!svn/vcc/..." or ".../!svn/his/...") would be a reasonable implementation choice. The first thing to implement would to add the RSS element links for all listed repository entities in the generated HTML output (<link rel="alternate" type="application/rss+xml" title="..." href="..."/>) - that should be nearly trivial. Far more complex will be the implementation for the RSS URL handler itself: it requires accessing the repository's log data and should optimally be rather performant (ie: not parse the log data from all versions in the backend). My guess is that there's no way around having to maintain a sqlite(/whathever) log cache for efficiency.

Oh, right: I don't think that I'll be implementing this feature any time soon. What about you, don't you have some spare time for this project? Leave a comment or send me an e-mail in case you want to tackle this.