isnoop.net blog

The EULA. It’s an interesting beast. On one hand, software makers have the right to say you cannot decompile their code and resell parts of it on your own. On the other hand, the rights granted to software makers and the limitations placed on end-users are often egregious, ludicrous, contradicting, and at the very least inscrutable.

I propose we break this down into three easy-to-digest parts:

What you want from me

First, a simple list of personal information that the app will collect and use just like with Facebook Apps or the Android Marketplace. This process is simple and well precedented. It covers the publisher’s backside and informs the consumer. Win-win.

What I get from you

Second, simple list of rights a user has with the software. How many copies can they install? Until what date is their license valid? This stuff is already baked into the legalese, but here you can make it easy to digest. At the same time, leave out the crap we already know such as “You can use this CD burning application to burn CDs.”

What I give up in return

Finally, provide a succinct and realistic outline of things the user should not do with the software. This will be the hardest part of all to streamline. Look, nobody is planning on manufacturing nuclear weapons with iTunes. In fact, let it be implied and obvious that if you’re breaking the law, your license is invalid and you are not authorized to use the software. Don’t be like Adobe and insist I cannot install their Air player on any machine that shares files with other machines. In today’s modern computing world, almost every computer out there shares files.

Of course, this is all naive and wishful thinking. So perhaps we should spend our efforts developing an app that automatically clicks the “I Agree” button. To whomever creates this app: Please lead by example and put a reasonable EULA on it.

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.

A co-worker just pointed out a wonderful new tool for those who are frequently bothered by people who would rather ask you question instead of Googling it themselves:

LetMeGoogleThatForYou.com

Aside from being snarky and satisfying, it immediately struck me as a brilliant money maker. Perhaps even the best Google AdSense for Search referral generating tool since Mozilla put the Google search bar in every broswer it ships (Mozilla pulled down 75 million USD last year from your searches).

So, next time your cousin wants to know all about mesothelioma, send your response by way of LMGTFY and know that those guys are probably making a good chunk of the $40-$60 CPC the keyword “mesothelioma” commands.

Of course, I am in no way affiliated with LMGTFY. If they aren’t using their site as a Google search revenue generator, they’re missing out.

Update:
I’ve delved into their code and it would seem that they aren’t currently monetizing their searches. Perhaps it is better this way because it might break Google TOS to have their current gag auto-submit the search on behalf of the user.

Still, if you arrived on this page after searching for mesothelioma, I have my own ads that I use to help cover the cost of this and all my other sites. Just sayin’…

Update 2:
Good for them! The site is now sponsored by 37 Signals and they are bouncing traffic through Google AdSense for Search. Unfortunately, the referral version of the search results does not have the pretty look that traditional search results do. However, this does not degrade from the original thrust of the site which is to teach people that they, too, can use the Google.

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.

Below is an email I got through Zend’s certified engineer website. The questions posed by the writer below are not uncommon, so I have posted his letter and my response for general consumption.

Hi,

I am an aspiring PHP programmer. I need some advice from the right people like you before taking a plunge into PHP. I know to know what the future holds for PHP in the web development sector. Why is there more demand for ASP.net or Java than PHP when PHP is the best option available for web development. I have heard that PHP professionals are some of the least paid people in the industry, is this true? why should I not go for ASP.NET or Java as compared to PHP? I know it all comes to one’s interest but knowing a stable path for career is also essential. Please help me and my many other colleagues who want to join the PHP community. Your kind help would be highly a appreciated. Please be frank to give your advice.

–Vibhor S.

Vibhor,

Thanks for your email. From my point of view, I am inclined to believe that PHP is actually in higher demand than ASP or Java. However, the latter two are likely to be more common for large companies. I believe this is mostly the result of corporate decision making and the antiquated belief that PHP is not enterprise class. Companies like Facebook, Flickr, and Digg are rapidly dispelling that myth.

The roots of the enterprise class myth also help to explain the question of compensation. PHP started off as a hobbyist’s language. From there, it became the de facto scripting language for low-cost web hosts. As a result, a lot of personal and small business websites sprung up with PHP as a back end. Lacking the project and budget size of medium and large companies, most jobs available to PHP developers were (and perhaps continue to be) for less pay. This is not to say that there are not good paying PHP jobs available. I live in Seattle and am one of a group of 6 PHP developers for a medium sized company. I believe we are competitively compensated compared to the industry at large.

The other part of the compensation problem might have to do with the experience curve of PHP programmers. I have seen many developer resumes and the large majority of people who claim to be PHP experts are in fact novices or even beginners. PHP is a very simple language to learn and become comfortable with, but that comfort is not the same as knowing (and using) best practices, OOP, or even PHP5. Many PHP developers haven’t had any experience working in a collaborative environment and, frankly, may not be suitable for full-time work in a group of developers.

On the question of why one should choose PHP over ASP.NET or Java, I cannot answer. I chose PHP as my language of choice for personal and perhaps arbitrary reasons. I like that it is open source, works best on *NIX systems, is in active development, offers a tool for just about any job, and has a wide and varied user base. It also helps that the language happens to have a sustainable number of companies offering full-time work for PHP developers.

One might just as well choose Java, ASP.NET, Ruby, Python, Perl, C++, or any other popular web language for their own set of reasons. You’ll find ample work with any of these under your belt. Some might have a brighter future than others, but you’ll still find COBOL programmers out there making pretty good money despite the dwindling need for their chosen skills.

I hope this helps. Good luck with your programming.

–Ian