In Rare Risk and Overreactions
Bruce Schneier writes, "If you want to do something that makes security sense, figure out what's common among a bunch of rare events, and concentrate your countermeasures there. Focus on the general risk of terrorism, and not the specific threat of airplane bombings using liquid explosives. Focus on the general risk of troubled young adults, and not the specific threat of a lone gunman wandering around a college campus. Ignore the movie-plot threats, and concentrate on the real risks."
I hate form spam. Whether the form is a contact form, a survey, or something else spamming can make life a pain. SANS has an interesting piece on techniques that can be used to reduce or prevent form spam. In my opinion the best solution is the one that has the least impact on legitimate users, is easy to implement, can be implemented in numerous ways, and has the highest negative impact on spammers. That's why I like the idea of including a form field that is required to be empty. To make it easier on legitimate users the field can be hidden using CSS. This way legitimate users aren't bothered with it, yet spambots are compelled to fill it in.
When was the last time you changed your e-mail password? If you're like most people, you probably can't remember. That means it's been too long. How about some external motivation? Consider the number of Internet processes that assume you have control of your e-mail account:
- e-commerce applications
- Web site membership enrollment processes
- domain registration and management
- hosting providers
What would happen if a bad guy figured out your e-mail password? He could change your password. But why would he do that when he could use your account at the same time as you. He could request a password change from any Web site that uses e-mail confirmations. Perhaps one of the worst things that could happen to you is to lose your domain name. Imagine if the bad guy transferred your domain name to another registrar into an account that he controlled. How much damage would that cause?
Web browsers have become the de facto client interface to Internet based applications. As we travel around the Internet, whether for pleasure or business, we find ourselves creating personal profiles for various Web sites. These profiles usually include access credentials (usernames and passwords). Good password management practice calls for many distinct passwords. But this proliferation of passwords results in the need for strong password storage. In addition to password management we need to give some thought to encrypted communications.
I was recently tasked with increasing the up time of my employer's main Web site. The site uses a content management system that lives on two Windows/IIS servers. (I know, the system was purchased before I was hired.) One server is for making changes to content (design-time server) and the other is the public web site (run-time server). The design-time server has a complete copy of the site which is replicated to the run-time server. Unfortunately the run-time server has a habit of refusing to serve pages at the most inopportune times, usually when I'm on vacation or somewhere without a computer.
A couple of years ago I was sitting in one of those mind numbing meetings about stupid users or some such thing when I began to doodle and hit upon an idea. Wouldn't it be cool if all of our users sat in specially designed (or retrofitted) chairs that were capable of producing a shot to the sitter's posterior. The idea called for a chair, a boot, a lever, an actuator, a small computer with a network connection (wired or wireless), and some custom software. The computer would provide a network interface that would allow an administrator or help desk person to send a request to the chair and the person sitting in it would get a single kick in the pants. The idea for the interface later morphed into a web page and/or XML-RPC interface that listened to requests from authorized administrators which would trigger the butt kicking as well as various presets (single kick, small whooping, smack down, death by boot, etc).
Kernux is a fully kernel-mode http-daemon for Linux. Currently Kernux is in it's developing stage. Similiar developments in the same area were khttpd by Arjan van de van and Tux web-server by Ingo Molnar. Khttpd was included in the linux testing kernel 2.5 by Linus Torvalds. But it was actually not in kernel-mode of operation. Also it handled dynamic requests which is assumed to be insecure for the server OS by the Linux kernel developers. Tux is another implementation of kernel mode http-daemon, being developed by RedHat. The developer is Ingo Molnar, the creator of O(n) scheduler, which control the procsses from Linux kernel version 7.2 onwards.