Random password generator update

Firstly a big thanks for the feedback I’ve received on the random password generator I stuck on the site a wee while ago, it’s had quite a bit of traffic so I’m going to assume it’s been of use to more than just myself!

I’ve fixed a minor bug where occasionally it would produce a password shorter than the length selected, which caused confusion for at least one person. To be honest I noticed it quite early on when I was testing and ignored it.

The second update is slightly more interesting. Grant from over the ditch in Australia pointed out that in the default setting of 9 characters with upper and lower case plus numbers there was often only one number in the password, where he felt there should be three on average.

And he would be correct, but I didn’t take the weighting of numbers vs letters when I wrote the generator. The problem being that there are 26 letters but last time I looked there were only ten numbers. The original code only used one instance of each number in the source string, so you were 2.6 times more likely to get a letter than a number, 5.2 times if you include upper and lower case.

I’ve fixed that up with a subtle update that uses 30 numeric characters in the source string, which gives relative likelihood of upper, lower and numbers of of 31.7%, 31.7% and 36.6%.

Along with that I’ve adjusted the punctuation string component to give more even distribution of punctuation if you select ‘Full Noise’.

Javascript Compression with Apache 2 and Debian Etch

If you’re trying to wring every last drop of performance out of a website you’re probably wanting to compress all your content before it hits the wire. While I was messing about with another project I noticed that the javascript from this blog wasn’t getting compressed.

If you just want the solution to the issue, skip to the bottom of this post, but for those interested in the finer detail, read on.

This site uses Apache 2 on Etch, and after a bit of Googling I didn’t really find a direct mention of this issue, so I though I’d slap it on here for other folks afflicted with un-compressed javascript.

First step is to enable mod_deflate in the first place, which will by default compress html, xml, css and plain text files, but due to a config issue will not get your javascript.

The command to enable mod_deflate is: ‘a2enmod deflate’. If you’re on shared hosting without this configured you’ll have to drop your support folks an email, although I’d think most shared hosting companies would be well on top of the config of mod_deflate as it saves them money!

The reason javascript is not compressed by default is that the mime-type specified in /etc/apache2/mods-available/deflate.conf for javascript is ‘application/x-javascript’.

Apache dosn’t know what extension is associated with this mime type. The mime-types used by apache are defined in /etc/apache2/mods-available/mime.conf by including /etc/mine.types.

/etc/mime.types in turn has the .js extension associated with application/javascript, not x-javascript.

To fix this up you’ve got a some options:

  • Change /etc/mine.types to be application/x-javascript, which might break other applications that include that file.
  • Change /etc/apache2-mods-available/deflate.conf to use application/javascript
  • Add the mime type ‘application/x-javascript’ to /etc/apache2/mods-available/mime.conf with the line: ‘AddType application/x-javascript .js’ which is the option I took.

After adding the line do a /etc/init.d/apache reload and you’re in business, all .js files leaving your server will be compressed if the browser reports that it accepts compressed files.

You could of course pre-compress the files and serve them using .gz extensions, or control specific compression rules using a .htaccess file, but I wanted server-wide compression without needing to specifically configure sites on the server.

Why is it so hard to think up a good password?

I’ve been working in IT for a wee while now, a shade over 20 years even, and in all this time there is one consistent thread of frustration that nibbles away at my very sanity. Trivial Passwords.

I’m sure this isn’t just be going nuts here, there must be thousands of network administrators and web masters going quietly bonkers all over the planet right at this very moment.

We slave away with intimate pride of our collective nerdiness, building robust and secure IT systems for all to behold. Fussing and fettling over minute details to ensure the ever important data is safe.

An unfortunate side affect of this creative journey is a necessary evil. The agent by which all things great in computing are undone. I’m not referring to the trivial password here but that which spawns it. The user.

“Do I have to put a number in my password, eight characters, really?”

I’m getting chills just typing that sentence.

A quick Google for ‘most common passwords’ will quickly reveal the painful truth. 123456 is actually a very common password, as is the word itself… ‘Password’.

Where am I going with all this? I use complex passwords. I love them with the same fervour as tatting enthusiasts like a good yarn. (See what I did there? No? Look it up…)

I used to use an on line password generator, but the owner of the website decided to put pop-up ads on the page, so that every time you refreshed the page you got another ad popup. ARGH.

If you were looking for something particular in your random password it could take ages with all the popping, closing and refreshing going on. Popup ads are second only in their evil nature to trivial passwords.

Fresh from a particularly annoying bout of popping, closing and refreshing last week I set about creating my own random password generator, which is now on line for all to use.

It uses the php rand() function seeded using microtime() which in lay terms means that in theory it can generate a different password every microsecond. Of course if you are a lay person you probably don’t care, and you’re using 123456 as your password.

That in a nutshell is it. Enjoy your randomly generated passwords.