Mozilla's secure coding guidelines for web developers

<p><pre><code> Invalid login attempts (for any reason) should return the generic error message: The username or password you entered is not valid </code></pre> In practice, on any non-trivial website, it doesn't make a difference for security.<p>Registration form will show a specific error when you try to register username that is already taken. Password reminder form will show error when you request reminder for an unknown e-mail. Some websites even have AJAX APIs for checking validity of usernames/emails!<p>Because of that it's <i>easy for an attacker</i> to check whether username or password is invalid. Vague error messages make it <i>only hard for the user</i>.

This is a great resource, but some of the input validation stuff doesn't sit well with me, for example:<p>&#62; <i>Examples of Good Input Validation Approaches... Firstname: Letters, single apostrophe, 1 to 30 characters</i><p>First, I'm not sure if I should interpret <i>letters</i> as [A-Za-z] or something more inclusive of non-Latin characters. But anyway, why restrict this so much? What about spaces, as in <i>Mary Ellen</i>; dots, as in <i>P.J.</i>? Heck, why can't I use a hyphen or a number? Just because you might not try to name your kid Brfxxccxxmnpcccclllmmnprxvclmnckssqlbb11116 doesn't mean nobody else will (<a href="http://en.wikipedia.org/wiki/Naming_law_in_Sweden#Protest_names" rel="nofollow">http://en.wikipedia.org/wiki/Naming_law_in_Sweden#Protest_na...</a>).<p>Perhaps I'm not seeing the forest for the trees here, but when it comes to restricting input, it always seems there's a risk of "We can not accept that last name" behavior (<a href="http://www.cooper.com/journal/2009/09/we_cannot_accept_that.html" rel="nofollow">http://www.cooper.com/journal/2009/09/we_cannot_accept_that....</a>). If you're properly sanitizing/escaping on the way out, why be so harsh on the way in?

One interesting/cool suggestion that I think is worth noting specifically: the use of HMAC+bcrypt instead of just bcrypt for secure password storage.<p><a href="https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Password_Storage" rel="nofollow">https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#...</a><p><i>- The nonce for the hmac value is designed to be stored on the file system and not in the databases storing the password hashes. In the event of a compromise of hash values due to SQL injection, the nonce will still be an unknown value since it would not be compromised from the file system. This significantly increases the complexity of brute forcing the compromised hashes considering both bcrypt and a large unknown nonce value</i><p><i>- The hmac operation is simply used as a secondary defense in the event there is a design weakness with bcrypt that could leak information about the password or aid an attacker </i>

Ironically, immediately after reading these guidelines, I checked my email and had just received an email from Mozilla's mailing list service that contained my password in plaintext. Oops. (To be fair, it looks like they're just using Mailman <a href="http://www.list.org/" rel="nofollow">http://www.list.org/</a>)

Whats the point of this?<p>&#62; Email verification links should not provide the user with an authenticated session.<p>It always bugs me. The "forgot password" links only allows me to choose a new password, but does not log me, adding a extra step.

<p><pre><code> Ensure that a robust escaping routine is in place to prevent the user from adding additional characters that can be executed by the OS ( e.g. user appends | to the malicious data and then executes another OS command). Remember to use a positive approach when constructing escaping routinges. </code></pre> Surprises me that they regard sending client content to the OS at all. What is wrong with parametrized execution using using functions like os.spawn*, which place arguments straight into the called function's argv list?

Ensure the "tweet this" or "like this" button does not generate a request to the 3rd party site simply by loading the Mozilla webpage the button is on (e.g. no requests to third party site without user's intent via clicking on the button).<p>Thank you for this.

A lot of people want to get into web development. One thing they have to understand as that while the barrier to entry is low there are a ton of nuances that separate a mediocre web developer from a great one.<p>These guidelines are a good example of what web developers have to deal with on a daily basis. Certainly not trivial.

<i>Passwords must be 8 characters or greater</i><p>Half of the top 50 cracked Gawker passwords were 8 characters (and longer passwords were not exposed, due to the nature of the vulnerability). Since 8 character passwords are vulnerable to a known common weakness (in DES), this should be revised to:<p><i>Passwords must be 9 characters or greater</i><p>This will prevent your users from using passwords that are vulnerable to the DES attack if they reuse them on other sites.

OT but scary: <a href="http://michaelkimsal.com/blog/wp-content/uploads/2011/06/Screen-shot-2011-04-06-at-6.34.33-PM.png" rel="nofollow">http://michaelkimsal.com/blog/wp-content/uploads/2011/06/Scr...</a><p>This is a financial institution.

I have a question about the password policy.<p><pre><code> All sites should have the following base password policy: Passwords must be 8 characters or greater Passwords must require letters and numbers Blacklisted passwords should be implemented (contact infrasec for the list) </code></pre> Is it responsibility of the website to make sure that the passwords are strong for the general user ? Isn't it the user's responsibility to create a good password ? I would think that the site should let the user know about best practices but ultimately it should be up to the user whether to follow it or not.

Great feedback. I'm glad to see this guide was helpful and I've made a few enhancements/updates based on these thoughts.<p>-Michael (@_mwc)

<p><pre><code> Example A field accepts a username. A good regex would be to verify that the data consists of the following [0-9a-A-Z]{3,10}. The data is rejected if it doesn't match. </code></pre> I guess then that pg won't be able to sign up for your service... Nor will donfernandovillaverde79.

this is brilliant. I am wondering if there are other secure coding guidelines for web devs? I usually refer to stackoverflow for questions about security, but often wondered if there was a set standard.

Ruby on Rails also provide a guidelines for web security: <a href="http://guides.rubyonrails.org/security.html" rel="nofollow">http://guides.rubyonrails.org/security.html</a>

I love the standardisation of generic answers. First thing coming to my mind as a non-nativ speaker: is there a way to provide translated versions of it inside the wiki?

Good security practices and ease-of-use are often at direct odds with each other.