Author Archive: Mark Ridlen

July 27, 2010

Security Myths Part 1

The world of IT security is full of partial truths and paranoia - some of which is completely justified. Sometimes, steps are taken that actually are beneficial, but without knowing the reason behind the precautions, many administrators are lulled into a false sense of security. Here are some common misconceptions that I see in action frequently:

Security Myth #1: If I set my password strong enough, my system will be secure.

The Facts: There are many ways to compromise a system. For example: exploitable code on your website, lax filesystem permissions, and publicly accessible services running on your system (such as email or chat). In fact, having a long secure password is often like having a steel security door with retinal scan technology on a grass hut. Don’t get me wrong, having strong passwords is a great thing, but don’t forget to look at the rest of your system!

The Side Effects:

  • Longer passwords take longer to type (obviously).
  • You are more likely to forget a longer password.
  • You are more likely to mistype a longer password (and get locked out).
  • If you force this policy on your end users they are more likely to write the password down (bad).

Security Myth #2: If I replace letters with their corresponding l33t speak numbers (e.g. hello -> h3110), it will make my password more secure.

The Facts: Technically, yes it will make your password more secure, but only marginally. Simple character substitution is a common feature among brute force tools. This will slow down the brute force attack, but your system may still eventually be compromised by a hybrid dictionary attack. You might also consider configuring the brute force protection options on your server.

The Side Effects: There are no side effects - in fact, this is a far greater idea than simply using a dictionary word. However, it is best to also add some additional numbers or letters to throw off brute force tools. Many brute forcers also allow for pre-pending or post-pending a string of numbers (e.g. 123hello or hello123). It is better to place random numbers or characters in the middle of your password so that it is not vulnerable to a dictionary attack (e.g. hagen!23daas). Another alternative to a secure and easy to remember password is make an acronym of a famous phrase or quote. For example: “sticks and stones may break my bones” -> “S&smbMb!$”.

Security Myth #3: If I change the port number for RDP/SSH/Plesk or turn off ping response, my server will be safe.

The Facts: This is the myth of “security through obscurity.” Changing your port number or turning off ping will only reduce attacks from computer worms and extremely lazy hackers. Say for example that you run a website on your server. Anyone who knows the URL of the website can easily find your IP address (by ping or nslookup). Then all they have to do is port scan that IP address (using a port scanning tool such as nmap or SuperScan) to see which ports are open. If your passwords are secure enough, you needn’t worry too much about the brute force attacks from the internet. You should only consider this a secondary safeguard just in case the server happens to have a vulnerable service running on it. Your first priority is making sure your system is properly patched and updated.

The Side Effects:

  • It is very difficult to track or troubleshoot packet loss on servers that have ICMP blocked.
  • Changing ports may confuse your users.
  • You will need to remember to include this port information in any technical support request.
  • Many automated systems or scripts will require custom configuration.
June 24, 2010

HTML 5 Video

If you haven't heard the buzz about HTML5, you should check out the many features and improvements. It has support for cool stuff like SVG and MathML, but one of the most impressive things it can accomplish is embedding streaming videos with no required flash player or java applet. The old way of video streaming usually involves first converting your video into the proprietary flash ".flv" format. Then you add many lines of ugly code, filled with frequently redundant information, like this example courtesy of YouTube:

<object width="480" height="385">
<param name="movie" value=";hl=en_US&amp;fs=1&amp;"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src=";hl=en_US&amp;fs=1&amp;" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed>

In HTML5, all this can be replaced by something as clean and simple as the tag. Here is an example of what it looks like in action:

<video width="640"  height="360" src="./movies/movie1.mp4"  controls autobuffer>

Much cleaner, right?

Sadly, this is not without its caveats. First of all HTML5 is not yet a finalized standard, so the various browsers will handle it differently. Secondly, Internet Explorer does not yet support HTML5 (surprise, surprise!), although the upcoming IE9 will provide support for it. This brings me to the first major hurdle:

Currently, there is no universal codec/container combination that will satisfy all HTML5 browsers.

This means that if you desire to use HTML5 video, you will need to encode your video at least twice. The two "official" combinations are Ogg/Theora/Vorbis and MP4/H.264/AAC. The Ogg combo works on Firefox and Opera, whereas the MP4 combo works with Safari, iPhone, Android, and the upcoming IE9.

Check out for more detailed information.

Once you have your videos encoded and uploaded, you'll need to set it up in your code. The guide recommends having 3 codecs (with webm, which is a soon-to-be standard) and Flash fallback, but in the future various browsers should have a more uniform codec support:

<video id="movie" width="320" height="240" preload controls>
<source src="pr6.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' />
<source src="pr6.webm" type='video/webm; codecs="vp8, vorbis"' />
<source src="pr6.ogv" type='video/ogg; codecs="theora, vorbis"' />
<object width="320" height="240" type="application/x-shockwave-flash"
<param name="movie" value="flowplayer-3.2.1.swf" />
<param name="allowfullscreen" value="true" />
<param name="flashvars" value='config={"clip": {"url": "", "autoPlay":false, "autoBuffering":true}}' />
<p>Download video as <a href="pr6.mp4">MP4</a>, <a href="pr6.webm">WebM</a>, or <a href="pr6.ogv">Ogg</a>.</p>

You'll notice the optional mime types and codecs as additional attributes. This is really just error proofing your code. It will make sure that it will have browser interoperability, and browsers won't have to download the videos to tell what codecs they are using (which saves you bandwidth—and when you are serving up videos, your bandwidth is a precious commodity!).

So much for the clean and simple solution, eh? So what is the upshot here? Well, first and foremost, it's an open standard. You no longer have to rely on the proprietary Flash plugin to do something that the browser should be able to natively support. Secondly, Flash is not universally supported, and with the growing prominence of iPhone video streaming, you'll be missing out on a huge demographic. Thirdly, HTML5 video is friendlier with overhead resources. So while it's not perfectly simple yet, it's still worthwhile to start adopting.


Subscribe to Author Archive: %