Author Archives: Lyle Kozloff

what? another post about passwords?

You’d think that I do nothing but mess people up by making them change their passwords. I actually make every effort to not mess people up while incrementally moving towards having a quality working environment.

I have noticed the particular pain that machine-generated random passwords impose on staff, particularly those who aren’t familiar with all the ‘special characters’. (Which is fair – if I didn’t use them every day I would have no idea where the | [pipe] key is on the keyboard). I’ve also noticed the brain-wracking caused by being forced to pick a new password with requirements of a certain length, capitalization or punctuation.

So, as an experiment in password generation I pulled a generous list of nouns and adjectives and cobbled together a  password generator that makes passwords like these:

  • tearful-berry
  • alleged*locket
  • pricey#government
  • previous.geese
  • uttermost_moon

Obviously random passwords of this length are far better than dictionary words. But, my hope is that these will at least not annoy staff in the interim – and potentially replace an extremely weak password that they’re already using.


passwords, security and human computer interaction

Screenshot from 2013-05-29 08:49:42
I’ve written a lot about the importance of changing your password and keeping your accounts safe. We don’t currently have a comprehensive password policy, but with our student account I have a great opportunity for trying things out that can be applied up the chain.

This year was the first time we did student accounts, and I gave them strictly random passwords. They were terrible, hard to memorize and students hated them (at first). As with many things, after a couple weeks of grumbling they memorized their passwords and were fine for the rest of the year. This year I wanted to enforce good principles of security, but give them the option of several passwords.

I wrote a quick password-changer (code) with a few goals in mind:

  • let a user choose from a set of good passwords
  • generate ‘pronouncable’ passwords
  • authenticate user using existing password
  • store password where it can be retrieved by school administration

Since I didn’t want students to have the ability to type in any password, I implemented it using radio buttons. This gives me the control of what types of passwords they can have, but gives them the freedom of choosing from an infinite number of them.

Unfortunately, what in concept seemed great and obvious to me was actually somewhat confusing for the students. We had a few common problems:

  • not actually making a password selection (that is, clicking on a radio button)
  • confusing the terms ‘username’ with ‘email’ (adding onto their username)
  • emailing me directly with a password they want, or the password they selected

After adding some more clear help text, we had some greater success. I’d still like to make the process more clear though – especially before I use it for staff! Any thoughts on how?



Student ID cards are pretty ubiquitous. Unfortunately the student information system we use doesn’t currently allow us to generate them ourselves. So, I created our own custom system!

My hope is that we’ll be able to have a standard ID card across our schools. Ideally, the barcodes on the bottom will used for access to the libraries at the various campuses and for a cashless payment system.

We’re not far from these goals, and this is a pretty cool first step. If you’re interested in the code behind it, it’s available at my github account:

Edubuntu Logos Remix

Per request of a teacher doing a video assignment, I got the chance to play with UCK (the Ubuntu Customization Kit) to remix the Edubuntu flavor of Ubuntu we use at school. In it’s default configuration it’s quite capable, but is missing some decent multimedia software.

UCK was super simple to use.. once I got past a few dependency issues. Essentially, it would fail to write certain files midway through the process and die. To solve this I first installed UCK from the main ubuntu repositories, satisfying any dependencies and then downloaded the current version from the Sourceforge page. From there it was a pretty simple matter to re-arrange files, remove unnecessary software and language packs and put in the stuff I did want.

All in all I was able to pull the size down to just 2.2GB – and still support the main languages represented at our school: English, Korean and Khmer. While it’s probably not fully localized, it will hopefully provide a more friendly environment for non native English speakers.

This is only the first, quick version. There are a few, key pieces of software that I’d like to get on there. Even so, it’s a pretty neat start!

Belldandy: a RaspberryPi based school-bell system

When Logos first moved to their new campus we had a PA system installed. Part of the contract with that company was bell system… but their solution was horrendous (and never worked). Their approach was to wire 3 alarm clocks together and to have our staff get up and stop the alarm after it rang. I don’t remember the exact price, but I think they wanted $100 for their system.


That said, I can’t brag about my ‘temporary’ fix too much. I used an abandoned iPod touch and alarm app to cobble something together. To fix the problem of repeating alarms, I created mp3s containing 4 hours of silence, and then each bell used a play list with our desired sound plus a few repeats of the silence mp3. It was messy, but it worked in the day to day: for two years.

(Aside: since then, there are quite a few apps for iOS specifically designed for school bell systems. Clearly my approach wasn’t unique!)

While the system was good, we always ran into problems when we needed a special set of bells, or to change the schedule. You could do it, but it was a pain.

My immediate thought was for a RaspberryPi to replace the iPod. With precious little coding you could make a decent system.

Belldandy is the result. If you’re interested in the code, you can get it at my github account:

It’s a bit hackish itself, as I was using it to try some things out I’d been wanting to play with. Currently, all it requires is: a webserver, write access to the crontab file and a command line sound player.

The back end is a simple XML file that’s controlled by a PHP front end. With the easy video out of the Pi, I’ve got a simple, mouse-driven, interface that rests in our office. Bells are rung by the inbuilt cron system, and updated by a processing script that runs every few minutes.



For now it’s working great (and our time is always accurate!).

The Pi, without a hardware clock, does have one big disadvantage: without an Internet connection a power failure will result in the clock not displaying the correct time. It’s not a problem for us, but it does limit the device somewhat. That said, my solution is portable to any computer/computing device that can run a UNIX-like operating system.

From an IT/Administrative view of things, there’s no reason that this process should run as root. But, since it’s a single application device, from a practical point of view, it doesn’t matter. That said, there’s no reason we couldn’t use the Pi to also host a student information system, or any other number of school systems.

The real test of all of this is time (and when we need to change bells!)

DNS Woes

While much of this blog will be of use to AH employees – I, personally, have greatly benefited from reading tips and tricks from various blogs around the Internet. Sometimes people have the exact same problems I do, and I get to benefit from their solution!

I’d like to make sure some of my solutions can be of benefit to others, so I’ve created this ‘technobabble’ category. Feel free to ignore unless you’re really, really interested in the nitty-gritty of AHIT.

We recently changed ISPs across a number of sites. While I had been testing them at a couple of our sites over the course of the year, I didn’t check up well before rolling out this larger change. As a result, we found that this ISP had started using a transparent proxy. Unfortunately this meant that OpenDNS stopped functioning, leaving lots and lots of undesirable things accessible from our campuses.

We successfully mounted an application to be removed from the transparent proxy. Under normal circumstances, this would solve our problems – but it looks like beyond just the proxy, DNS requests are being rerouted.

Not, however, in a opaque and easy to detect way. It seems as though common DNS servers are being rerouted through a transparent DNS proxy… but requests that would fail otherwise, still fail.

The upshot is I’ve created an offsite DNS server that simply grabs results from OpenDNS directly through another ISP. With caching enabled on-site, I suspect that performance will be acceptable. The upside to this approach is that, once you’ve got BIND configured, it’s incredibly easy to deploy. No need to worry about Dynamic IPs or OpenDNS’ updater. You plug in your private DNS server and it ‘just works’.

The downside to this approach is that I won’t have the fine-grained control that OpenDNS provides in its native implementation. Sites are blocked everywhere, or nowhere. Worse still, I don’t have the reporting that lets me know when something nefarious is happening at a single site.

We’re still working with the ISP to figure out what’s going on, but this solution does solve our immediate need.

Some handy tools for diagnosing DNS problems:

  • namebench - benchmarks DNS servers, automatically detects redirects

  • DNS Leak Test - lets you see where your DNS queries are being resolved