isnoop.net blog

Last weekend Washington state just upped its liquor prices an average of 13% per bottle in a bid to help fill its 6 billion dollar budget gap. The estimated proceeds from the increase in liquor tax should cover about 1.3% of the budget shortfall. The problem is, I don’t think they will take in nearly as much as they have estimated.

It hasn’t even been a week and I’m already hearing several people talking about making booze runs down to Portland, Oregon. A casual web search reveals some insightful answers.yahoo.com advice suggesting there is no peril in shuttling copious quantities of booze across state lines, but I remain dubious. However, with over 75% of the cost of a bottle now profits to the state, it will become harder for people to resist a little bit of sales and use tax evasion.

I hate to say it, but it will probably take a horse’s ass to spearhead an initiative to reduce state liquor taxes. It can’t be many more years before people start whining about the ever-increasing rates in general and I know someone will come riding in on their white horse to rescue the taxpayer’s hard-earned dollar once the general consensus agrees that the economy has sufficiently recovered.

Photo credit Thomas Hawk

As a follow-up to my last post, here are a few tips to help keep you from driving your site users away with misguided password restrictions.

#1: Consider Context

Your tweets may be precious to you, but as a web developer, you should understand the differences between password security for Twitter and for online banking. Consider the monetary and legal damages that to both you and your customers if their account were compromised and plan accordingly.

#2: Character Taboos

Since you are properly protecting passwords by only storing a hash, there is no reason to limit characters they use in their passwords. Don’t tell your users they can’t use symbols or start their password with a space if that’s what they want to do. In the end, all you’ll be storing is an alphanumeric hash of the password anyway, so it shouldn’t matter if they send you a bunch of binary gook.

#3: Password Rotation

Set reasonable requirements for password rotation. If yours is a high-security system, it is reasonable to require password rotation every few months. In order to prevent abuse, it is even reasonable to check for duplicates against the last N password hashes or all of the hashes used the last few months. Before implementing any password rotation scheme, be sure you’ve visited and revisited #1 above.

Despite the practices of some sites, there is rarely if ever a good reason to keep an unlimited log of every password a person has used, never letting them be reused.

#4: Minimum password lengths

Let’s assume someone really wants into one of your user’s accounts. If they had the capabilities of attempting a blistering 1,000 different passwords per second, here’s how long it would take to try every possible combination:

The exponential growth of possible combinations makes password cracking infeasible pretty quickly. Assuming 1,000 attempts per second is ludicrous against a webserver, but assuming your database isn’t compromised, this should be the only means an attacker can brute force an account. The time to compute reaches absolute absurdity after just 8 lowercase characters.

#5: Maximum Password Lengths

As in character taboos, what do you care if your users have 100 character long passwords? It is reasonable to put a ceiling on password lengths to prevent blatant abuse (perhaps in the neighborhood of 500-1,000 chars), but don’t limit your users to a 12 character password because that’s all your schema can hold.

Remember that you should be hashing passwords and that most hashes produce a fixed-length output no matter the input.

Just a quick note to any developer, site owner, or project manager who is in charge of developing a user login system:

Don’t put unreasonable restrictions on usernames.

It is sensible to prevent people from creating names containing certain characters or names of extreme length. However, some sites go too far by requiring all user names be 7-12 characters in length. Other sites forbid user names that begin with numbers.

A more reasonable approach would be to allow user names from 3 to 16 characters, with a limited set of punctuation allowed, and the first letter cannot be whitespace.

Remember that user names are generally public information so you don’t need to apply the same protections you do to ensure strong passwords. Do the right thing and your users will thank you by not abandoning your account creation form.

Most programmers take a pragmatic approach to security and scale their efforts based on an estimate of the sensitivity of the data they are storing.

The unfortunate truth is that password security is frequently underestimated, making it easy for credentials to be sniffed or stolen.  Users often keep a very small collection of passwords, with many people memorizing a small collection and using them on almost every site and service they use. A password compromise on one site can lead to a compromise on many.

#1 Only store salted password hashes, not the plaintext password itself

The cardinal rule for handling user passwords is to never store the password itself.  You should only store a hash (one-way encrypted representation) of the password, cryptographically salted with a string at least 16 characters long. When you want to check a user’s login, simply re-hash their input with the same salt and compare it to the hash stored in your credentials table. 

#2 Never display a user’s password

There is never a good reason to display a user’s password on a web page.  If they have forgotten their password, send the user through a password reset procedure.  This also includes displaying their password in HTML forms.  Don’t send the user’s password out as the value of a password form field input.  This is almost as bad as displaying it on the page.

#3 Use the password field in forms

On occasion, a site will not use the “password” input field type on a login form.  Any sensitive input acting like a password should be presented as a password input.  This provides basic protections against caching, copying, and prying eyes.  This applies to passwords, PINs, SSNs, and other private authentication data.

#4 SSL encrypt pages where users create new passwords

Prevent packet sniffing password theft by encrypting pages where the users are changing or creating new passwords.

#5 Protect passwords sent over non-encrypted connections

If you can, SSL encrypt any page where a user is sending their password for login.  In places where this may not be an option, consider using javascript to prevent the password from being sent in plaintext.  (More info on this in a later blog post)

#6 Never store passwords in cookies

Many developers don’t consider the fact that cookies are sent by the user’s browser for every request to a domain, including requests for images, CSS, and javascript.  All this traffic makes it extremely easy to sniff passwords stored in cookies. Passwords stored in cookies are also easily found by someone who has access to a computer’s harddrive.

#7 Enforce reasonable password rules

All sites need some basic rules around passwords to keep users from using poor passwords.  However, don’t think you’re doing yourself or your users any favors if you implement rules like setting a maximum password length, requiring users to change their passwords too often, or preventing users from ever re-using a password once they’ve changed it.  

Forcing users into situations like these frequently leads to password post-it notes stuck to monitors or the underside of keyboards.  Sometimes, it even drives site users away (I’m talking about you, sharebuilder.com).

#8 Send confirmation emails when their password is changed

Whenever a user’s password changes, send a confirmation message to their verified email address.  Tangentially, any email address change should trigger confirmation emails to both their new and old addresses.  This behavior helps your users quickly find out when they’ve been compromised, which can limit the damage done by a malicious user.

#9 Never email a user’s password

Many sites feel they are doing their customers a courtesy by emailing them their own password when they change it or sign up.  However, if your email account is ever compromised, a simple search for ‘password’ can reveal a treasure trove of passwords, allowing a malicious person to gain access to many more sites and services used by a user.  The resultant password list may also be used against any other site that hasn’t emailed a user their password, such as their bank, PayPal, or social networking sites.

#10 Use a proper password reset system

When a user forgets their password, generate a random temporary password and email it to their verified email address.  This should not overwrite their old password.  Instead, it should be set to expire within a reasonable amount of time (a few hours) and if it expires, the old password should remain in place.  If the user logs in with the temporary password, they should be required to enter a new password before continuing to the site.  The temporary password should then be expired and unusable on that account.

Google Voice is a very interesting service. If you were one of the people (like myself) that got an account on GrandCentral.com before they were bought out by Google, you are now eligible to be part of the Google Voice beta.

It offers a lot of interesting services such as visual voicemail, speech to text, VOIP, free long distance, and many others. However, in order use most of these, you need to use the phone number Google assigns you. Google can’t be your voicemail provider unless all of your calls are routed through them first.

So are you going to hide your current cell phone number and tell all of your friends and family to call your GV number instead? Unlikely.
I believe it is much more likely that Google is actually moving to become a telephone service provider themselves. That way, you just transfer your phone number to Google and they give you all of the great features of GV along with it. However, in order to participate in LNP (the FCC program that enables users to transfer phone numbers between providers), they must become a wireless carrier.

I know it sounds unbelievable. I am somewhat skeptical myself. It seems like quite a stretch for them to actually get into voice service. After all, couldn’t Google just partner closely with the existing providers and integrate their GV directly into your existing plan? Unfortunately, cellular service providers would probably never play ball with Google this way. GV bundles free long distance VOIP, SMS, and (quite possibly) unlimited airtime.

Many people were skeptical when a search engine company was rumored to be branching into email. There was even more surprise as the rumors of a Google phone came true. Now that they have their own cell phone OS and a fantastic web integration platform, it is not inconceivable that they will take the next step and start leasing tower space.

Google is out to eat the telco’s lunch.

Google Voice is the long awaited re-release of Grand Central, an online voice communications service. Based on their beta, Google Voice will essentially be a Gmail for voicemails with call forwarding, filtering, SMS, VOIP, and speech to text.

They appear to be assigning Montana area code (406) phone numbers to folks who call or SMS a Google Voice user. I can only assume that the generated number will be your default Google Voice number if you eventually sign up.

If you would like to know your default Google Voice number, send an SMS to 206.855.5330. I’ll reply back to you with your number. Once established, you can start receiving calls at that number that are forwarded to your phone.

Disclaimer: I don’t know if the numbers are permanent, but they appear to keep working after at least two weeks.

It is a common belief that moving into a higher tax bracket will cause you significant financial hardship. People have given away large sums for a tax deduction or even accepted lower pay believing they are actually saving money by maintaining a lower tax bracket. This post explains why this is incorrect and illustrates what a tax bracket transition really means for you.

The Myth
The basic belief is that tax brackets are retroactive and that all income is subject to your highest tax bracket’s percentage rate. The chart below illustrates the tax amounts a person would be subject to if this logic were applied.

(Click to enlarge)

The Reality
Only the income above the minimum amount for any given tax bracket is subject to that bracket’s rate.

For example:
If you are filing single and made $30,000 in 2008 you would be in the 15% tax bracket. Your first $8,025 would be subject to 10% in taxes. The remainder ($21,975) would be taxed at 15%.

This chart illustrates the actual tax breakdown for each taxable income group:

(Click to enlarge)

This detail view illustrates the different tax brackets as they apply to the income of a person filing single. The red line is a reference to help illustrate the slope of the tax amounts below.

(Click to enlarge)

This final chart illustrates the myth vs reality when one’s income moves from one tax bracket to another. The blue vertical bars indicate the tax brackets. The red zone illustrates the incorrect assumption that your tax rates apply retroactively. The green zone is your true net income.

(Click to enlarge)

Summary
This post should dispel the myth that your current tax bracket applies to 100% of your income. While taxes are complicated by many factors, this basic rule still applies. Don’t let yourself be fooled into believing that you are actually saving money by lowering your tax bracket. You should make tax-deductible donations as you see fit, but don’t think you’re saving any money by doing so.

More information
IRS 2008 tax tables
Chart source data (Google Docs spreadsheet)

I should preface this by saying that I normally do my home improvement shopping at Lowe’s. Historically, they have had better customer service and have a higher likelihood of carrying the oddball things I require for my more unusual projects.

This weekend I found myself going back and forth between Lowe’s and Home Depot as part of a home improvement project. Each time I visited Home Depot, I noticed an unnerving trend: abnormally attentive employees.

There were a lot of staff on hand and they kept stopping me and asking if I needed any help. At first I thought it was because I was one of the few people in the hardware store at 9am on a Sunday. Perhaps with my large graph paper pad, they assumed I was a mystery shopper. Maybe they just had a corporate pep rally so they could be expected to be truly helpful for a few days before going back to the norm.

I knew something was up when an employee helped me load several dozen pavers and a few bags of sand onto a cart, pushed them through checkout, and then helped me load it all into a truck. He even brought me a spare bag of sand after one tore a little bit.

I pointed out that his service was exemplary and that everyone was abnormally helpful for a big box hardware store. He confessed that they are running a new program called “Power Hour” from 8am to 8pm on weekends. During this time, they boost staff and have everyone make sure all of the customers are well attended to.

Home Depot may have just discovered the secret to weathering this economic downturn.

In a time when many companies are trying to lure in customers with lower prices, rebates, while cutting staff, at least company is spending their customer attraction dollar on its employees. In the home improvement market, they probably don’t have a lot of wiggle room for big sales and discounts. Making sure they have plenty of staff on hand who are eager to help will probably make a huge difference for them this season.

Unfortunately, it is a bit of a catch-22. They’ll have to rely on word of mouth for news of their improved service to spread. They can’t reasonably run an ad campaign shouting “We now have the customer service you want and deserve* (*Saturday and Sunday between 8am and 8pm)”. Still, this is probably a big expense for them and they are going out on a limb. If they don’t see a reasonable return, they may just drop it and go back to the way things used to be.

If you shop at a Home Depot this season and you experience exceptional customer service and attentiveness, let the staff know and maybe even let corporate HQ know.

With any luck, this is just the beginning of a revolution in big box home improvement customer service.

As a professional PHP developer who enjoys helping others learn about the language, I have noticed several phases of PHP skill development. One of the first phases is when one stops piling all of their code into one file and starts storing their classes and specialized logic into reusable files. For some, this change brings on a wave of problems that may be very difficult to track down.

The Problem

At some point, many PHP developers run into an inexplicable White Page of Death or at least stubborn cookies and headers that won’t change when they should. A common cause is include files with white space after the PHP closing tag. Your web server might send these characters to the browser before you process your header() or setcookie() calls, causing them to fail. PHP allows for a single newline after a PHP closing tag before it starts interpreting characters as output.

Solutions

Omit PHP closing tags
The PHP closing tag is useful when you embed PHP into a page that already contains other content such as an HTML template. However, if you only intend to have PHP logic in a page and nothing else, you can omit the final PHP closing tag:

<?php
$test = new testClass();
$test->helloWorld();
// End of PHP script. No closing tag needed.


This approach does not incur any additional resource penalty to the server.

Output Buffering
If you feel that you need to send output before processing headers and cookies, you should use output buffering. The ob_* class of PHP functions are very useful in these circumstances, but be aware that it comes at the cost of an increased memory footprint and slightly slower processing.

Error Logging
Instead of silently failing or dying with a white page of death, error logging would tell you exactly what is failing and why:

[24-Oct-2008 15:17:31] PHP Warning: Cannot modify header information - headers already sent by (output started at /websites/demo/htdocs/whitespace.php:5) in /websites/demo/htdocs/cookie.php on line 8

I suggest everyone who develops in PHP do so with log_errors enabled. If develop with logging on from the beginning of your project, you will quickly capture potential problems before they grow too great in number and become overwhelming.

I prefer to set my error_reporting level to “E_ALL & E_STRICT” because many standards and best practices are enforced with these messages. (E_STRICT will be included as part of E_ALL in PHP 6)

Once you have logging enabled, you can SSH into your server and “tail” your error log for real-time error output:
[ian@devbox]~ tail -f /tmp/php.log
Using the “-f” flag will follow the log and give continuous output as it appears in the log file.

Please note that logging should be used sparingly (at least at a higher error_reporting level) in production servers. Also, I advise against using PHP’s display_errors in any case, especially production servers. In a production environment, this argument can provide dangerous information to site visitors. You may find it useful in development, but I find that not all errors will be visible or readable when output within your page. However, your log files will never let you down.

I’m in the Apple store right now playing with a new MacBook Pro. I love the backlit keyboard of the original MBP, so I decided to get it to light up in this bright showroom for a quick demo.

On the old MBP, you’d cover both speaker grilles at once. There is a light sensor in each one and the brightest of the two is used to determine how much to dim the screen and brighten the keyboard.

Covering the speakers in the new laptop didn’t work, so I tried placing my hands symmetrically all along the sides of the screen. The screen finally dimmed when I slid my fingers across the top bezel above the screen.

Whenever I blocked the camera’s eye with my finger, the screen would dim. This was a troubling revelation. If the MBP is using its camera as an ambient light sensor, that means it is effectively always on and collecting image data even when the recording light is off. This would be a significant departure from the original built-in iSights where Apple claimed the hardware that drives the camera is so tightly linked to the indicator LED that one could not record you without your knowledge.

I busted out my credit card for some fine-tuned testing. I slowly slid it across the top of the bezel and found that it didn’t always dim when I covered the camera. In fact, it only dimmed when the small lighter spot just to the left of the camera was covered. I had assumed that this was the green indicator LED for the camera. A quick trip to Photo Booth confirmed that the LED is in fact on the right side of the camera.

So, rest assured that your new MacBook and MacBook Pro are not constantly recording you as you write emails in bed with your hair in curlers. The placement of the light sensor may cause concern at first, but a bit of investigation quickly indicates that there is little to worry about.