isnoop.net blog

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.

Many websites offer the flexibility to display the same page via both SSL and HTTP. The major problem with offering this is the possibility that embedded content will not be served via the same protocol; many browsers will throw an error if an SSL page embeds HTTP images.

However, there is a simple and W3C valid solution to this problem. Simply omit the protocol and colon from the URL:
<img src="http://isnoop.net/sa/av.jpg">
becomes
<img src="//isnoop.net/sa/av.jpg">

This works with embedding images, links, javascript embeds, and other link types.

The drawback to doing this everywhere is that you must be conscious as to whether the resource you are linking to is available on both SSL and HTTPS. Embedded scripts from services like Google Analytics are well served by this technique. If your enterprise uses a dedicated image hosting server, this is also a highly appropriate solution.

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