It’s a Doozy!
Did you know you can trigger a refresh while viewing the source of a page? This feature has been around since the dawn of Firefox 2.0, but it is still unknown to many web professionals.
All the standard keyboard shortcuts work, including the F5 and Ctrl+Shift+R for a cache flush. Give it a try on your favorite dynamic page.
Thanks to Apple shipping everyone’s iPhone to be delivered last Friday, my package tracking website Boxoh.com saw double the number of absolute hits and six times the number of Adsense impressions. That’s a lot of iPhone recipients mashing F5 all day long.
Let’s hope more of them turn into return visitors. I do have several features in the works to help make the site more compelling for regular users and one-timers alike.
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.
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.
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.
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.
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:
| Min length | a-z | a-z, A-Z | a-z, A-Z, 0-9 | a-z, A-Z, 0-9, Symbols |
|---|---|---|---|---|
| 6 | 3 days | 225 days | 2 years | 22 years |
| 7 | 90 days | 32 years | 110 years | 2,035 years |
| 8 | 6 years | 1,663 years | 6,814 years | 191,258 years |
| 9 | 166 years | 86 millennia | 422 millennia | 17,978 millennia |
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.
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.
They say clothes make the man, so it stands to reason that the theme makes the blog. After receiving several moans about my blog’s styling, I’ve finally decided to do something about it. No more Kubrik theme for me.
For those who don’t care for the WordPress default theme, I do hope this one is more appealing. For tech and convenience oriented folk like myself, this new theme was easily customizable to support multiple widget bars. Plus, I hear three column fixed width layout is in this year.
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.
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.
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.
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.
Prevent packet sniffing password theft by encrypting pages where the users are changing or creating new passwords.
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)
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.
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).
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.
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.
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 only took a few minutes in the food processor to turn a quart of heavy buttermilk into one of the tastiest butters I’ve ever had. The transition from creamy liquid into butter is almost instantaneous and is very interesting to watch.
The leftover buttermilk went into a quick and easy batch of bread machine bread. A few hours later, we had a great homemade treat.
Buttermilk costs just over $2 a quart here. The yield was just under 2 lbs of butter. That’s about a 60% savings per pound for a better product than you can buy at Safeway or QFC.
I’ll be making my own butter from now on.
I’m looking for one or more advertisers who would be willing to sponsor the package tracking RSS feeds generated over at Boxoh.com. As it stands, only about 5% of the traffic to the site is via web browsers. Last month alone, I got just under 1.5 million hits to the dynamically generated RSS feeds for package tracking. The Google ads on the web page are hardly reaching my audience.
Unfortunately, commercial RSS advertising systems such as Feedburner will not work as they are geared towards blogs with a small number of feeds to monetize. Since Boxoh delivers individualized feeds based on package tracking numbers, the number of unique RSS feeds is vast.
If this sounds appealing to you, please get in touch with this contact form.