Tag Archives: security

Enable P3P support in Firefox

In Outlook Live browser cookie issues, I discussed the issues surrounding cookie usage and the Outlook Live service.  As you may remember, one of the problems surrounding turning off the blind support of third-party cookies is the check that is performed at logout.  If the check doesn’t pass then you will get a warning message.

The fix for this from the MS perspective is to enable third-party cookies.  One of the main reasons to not follow this is for better privacy while browsing the Internet.  As with most computer security, web browser security is often a trade-off between usability and security.  You have to know what to set things to to achieve a balance between good security and acceptable annoyance.  Many users install ad-blockers, flash blockers, disable Javascript, etc.  These are good tactics, but they also introduce browsing annoyances since the very technologies these plug-ins disable are what makes the web experience interesting and fun.  For more on browser security check out Securing Your Web Browser at CERT.

Fortunately, in this particular case the solution is relatively easy.  Since Mozilla gives us the ability to configure the browser directly, we can change how Firefox handles cookies.

First you will need to open Firefox and go to the site about:config to edit the settings.  This is not really a website, but a method provided to directly configure some browser settings.  You will be presented with a warning box, just click the button.

Navigate to the configuration editor

Configuration editing warning message

Next, in the filter box type network.cookie, this will narrow the list displayed down to only the ones dealing with cookies.  One of the settings to be changed already exists, the other will have to be added.

Filtering the preferences list

Narrowed down preference list

The setting that you want to change is:

  • network.cookie.cookieBehavior

Change network.cookie.cookieBehavior to have a setting of 3, enabling the change, by double clicking on the number in the Value column and entering the new value in the dialog box.

To add the new preference, right click in the window and select Integer from the New submenu.

Adding a new preference entry

Enter network.cookie.p3plevel in the dialog box that appears. Set the value to be 3 in the second dialog box.  There is no save function, the changes take effect immediately, just close you browser tab/window.

After making these changes you will now be able to successfully navigate the Outlook Live site and logout without getting the warning message.  You will also be better protected from nefarious third-party cookies.

If you want to change the preferences back to the defaults, simply open the preferences for Firefox and click the checkbox next to Accept third-party cookies.

Apparently this functionality was part of Firefox 2 but was subsequently removed after someone complained about the size of the code required to implement it (a total of 60k in what is now a 56.9MB, at least that’s the size of the application on Mac OS X).  In reading through the comments in the Bugzilla post, I fail to see where anyone makes a decent argument for reducing end-user security.  For more on all of this, check out the references section of this post.

These changes were implemented on Mac OS X 10.6.4 using Firefox 3.6.11, but it should be pertinent to Windows and Linux as well.


  1. http://blog.psych0tik.net/?tag=p3p
  2. https://bugzilla.mozilla.org/show_bug.cgi?id=225287

Outlook Live browser cookie issues

Windows Live logout error messageIn June of 2010, Valdosta State University transitioned to using Microsoft’s Live@EDU service for our e-mail.  This is Microsoft’s competing product line with Google’s Apps for Education service.  There were many reasons why we chose the Microsoft service which I won’t get into here, suffice it to say, that was the decision that was made.

While I don’t use the web interface all that much, when I do use it on Safari 5 for the Mac, I have noticed an oddity.  After you login to the system and do whatever you plan to do that session, to logout you should click the “Sign Out” link.  Seems standard enough, right?  Well, not exactly.  On Safari on the Mac I have noticed that I get an error when the signout process is attempted.  When testing Firefox 3.6.11, I found I wasn’t receiving the error screen and the signout process completed successfully.

After delving more into this it turns out that the problem is third-party cookies.  The default settings in Safari are very restrictive.  They are also all or none.  There is no exception list to the privacy settings for browser cookies in Safari, unlike Firefox. Also, it turns out that if you change the settings in Firefox to match the restrictive settings in Safari you get the same error screen.

In order to find out what site was causing the problem I cleared all the cookies for Safari, then enable the setting to always allow cookies.  After comparing the list of cookies that were set, I found one listed for the domain passport.com that did not show up in the cookie list when Safari is set to accept cookies only from sites that I visited.

Cookie listing for Safari on the Mac with 3rd party allowed

Further investigation using the Live HTTP Headers add-on in Firefox revealed the following for that domain:


GET /ThirdPartyCookieCheck.srf?ct=1287943985 HTTP/1.1
Host: loginnet.passport.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101012 Firefox/3.6.11
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://login.live.com/logout.srf?lc=1033&nossl=1&lc=1033&ru=https://login.microsoftonline.com/login.srf%3Flc%3D1033%26ct%3D1287943985%26rver%3D6.1.6206.0%26id%3D260563%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Foutlook.com%252Fowa%252F%253Frealm%253Dvaldosta.edu&id=12&wa=wsignout1.0

HTTP/1.1 302 Found
Connection: close
Date: Sun, 24 Oct 2010 18:13:05 GMT
Server: Microsoft-IIS/6.0
PPServer: PPV: 30 H: BAYIDSLGN1F57 V: 0
Content-Type: text/html; charset=utf-8
Expires: Sun, 24 Oct 2010 18:12:05 GMT
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: MSPP3RD=2832116359; domain=.passport.com;path=/;HTTPOnly= ;version=1
Content-Length: 0
Location: http://loginnet.passport.com/ThirdPartyCookieCheck.srf?tpc=2832116359&lc=1033


GET /ThirdPartyCookieCheck.srf?tpc=2832116359&lc=1033 HTTP/1.1
Host: loginnet.passport.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101012 Firefox/3.6.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://login.live.com/logout.srf?lc=1033&nossl=1&lc=1033&ru=https://login.microsoftonline.com/login.srf%3Flc%3D1033%26ct%3D1287943985%26rver%3D6.1.6206.0%26id%3D260563%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Foutlook.com%252Fowa%252F%253Frealm%253Dvaldosta.edu&id=12&wa=wsignout1.0
Cookie: MSPP3RD=2832116359

HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: close
Date: Sun, 24 Oct 2010 18:13:06 GMT
Pragma: no-cache
Content-Type: image/gif
Expires: Sun, 24 Oct 2010 18:12:06 GMT
Server: Microsoft-IIS/6.0
PPServer: PPV: 30 H: BAYIDSLGN1F50 V: 0
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked

Continuing the investigation, I decided to force Firefox to ask me about each cookie that was going to be set.  This makes a dialog show up for each cookie attempt giving me the option to deny it, allow it only for the current session, or always allow.  After walking through the tortorous process of a complete login/logout session, it turns out that two cookies are being set for the domain passport.com with each of them set to expire at the end of the session.  More detail on the cookie can be seen in the screen shot of the cookie detail (provided by the plugin Add N Edit Cookies) shown below:

Detail on the contents of the passport domain cookie

So, the next step was to fire up my VM and see how all this worked on the Windows side of things.  I figured that since we had not been deluged with user requests concerning this that the browsers on the Windows side of the equation were handling it all differently. Firefox on Windows is configured out of the box just like Firefox on Mac OS X.  So, as I expected the operation was the same as well. If you allow for third-party cookies, then it works fine, if you don’t then you get the error screen.

The interesting development is the settings for Internet Explorer.  Bear in mind that I am using Windows 7 and Internet Explorer 8, but the settings should be fairly similar on Windows XP and between versions 7 and 8.  The default setting in IE8 is to all third-party cookies, but (and this is the key) only if they have a compact privacy policy (P3P).  This is the setting that makes the big difference.

Default privacy settings for Internet Explorer 8

It turns out that neither Firefox nor Safari support P3P headers by default.  In fact there doesn’t appear to be any support for them in Safari at all.  Configuring Firefox to support them requires some advanced editing of the main configuration file.

I haven’t found any adverse effects to the workings of Outlook Live when using Safari, but it is rather annoying that this occurs.


  1. http://en.wikipedia.org/wiki/HTTP_cookie#Third-party_cookies
  2. http://squeeville.com/2010/02/03/third-party-cookies-in-safari-internet-explorer/
  3. http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/

RHEL5 Password Policy Enforcement

Image Credit: Ohio State University

Yesterday in my post on Solaris 10 Password Policy Enforcement, I outlined the steps necessary to implement the password requirements that have been decided upon in my system environment.  This post will outline the same process on the RHEL5 systems that I admin.  While the policy requirements are the same, the implementation is vastly different.

Desired Policy

To re-cap, here is the policy that is to be applied to normal users:

  • at least 8 characters in length
  • no more than 20 characters in length
  • contain at least on letter
  • contain at least one number
  • forced to change at least every 180 days
  • 15 minute lockout after 5 unsuccessful attempts

Implementation Differences with Solaris 10

While there were a couple of pieces of the desired password policy that I was unable to implement on Solaris 10, the ease of which the others were configured wins the game hands down.  The PAM module setup on Solaris makes it dead simple to update the policy.  All you have to do is to change the various tunable settings.  And they are all listed in fairly understandable verbiage, no complex or arcane settings.

On the RHEL5 systems I had to delve into the vagaries of PAM module attributes and ordering.  As always, it is important to make backups of any files to protect yourself and allow for disaster recovery. To implement the requirements, I had to edit two files on the system:

  1. /etc/login.defs
  2. /etc/pam.d/system-auth

Implementation Process

It is important during this process to recognize that if you set the PAM requirements incorrectly you can get burned to the point that the root user will be unable to login, forcing you to boot into single-user mode to recover or to boot the system from a live cd and revert the authentication files.

Setting the password expiration requirement and length setting

Before we get into this please note the warning notice from the login.defs file manpage on a RHEL5 system

Much of the functionality that used to be provided by the shadow password suite is now handled by PAM. Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Pleaserefer to the corresponding PAM configuration files instead.

It is still important to configure the password length in the login.defs file so that we can account for legacy codebases.

  1. Open /etc/login.defs in your favorite editor
  2. Set the attribute of PASS_MAX_DAYS to be 180
  3. Set the attribute of PAS_MIN_LEN to be 9

Setting the password complexity requirements

Now here is where the going gets real interesting.  Before we look at /etc/pam.d/system-auth a strong caution

Backup up the file before you alter it and open a backup terminal session as the root user before continuing.  If you put the wrong attributes in place or put the PAM directives in the wrong order you will lock yourself, root user and all, out of the system.  At that point you have two options: single user mode recovery from the console or use a live cd to boot the machine and revert to the backup after mounting the filesystem.  Oh, and it is wise to give yourself a delay with either GRUB or LILO because without the delay you won’t be able to change the boot option to allow the single user mode recovery option.

So, the file involved in this process is /etc/pam.d/system-auth and before I go into some of the nitty gritty, here’s the configuration I ended up using:

# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_tally2.so deny=6 unlock_time=900
auth        sufficient    pam_unix.so nullok try_first_pass nodelay
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so
account     required      pam_tally2.so per_user

password    required      pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The retries requirement is implemented using the following line

auth        required      pam_tally2.so deny=6 unlock_time=900

The complexity and length requirements are implements using the following line

password    required      pam_passwdqc.so min=disabled,disabled,12,9,9 max=20 similar=deny enforce=users retry=3

The following line is set to ensure that the retries count is maintained even if the counter for the pam_tally2 module is corrupted

account     required      pam_tally2.so per_user


Rather than go into the details of each individual attribute and how they interact, here are the resources used to develop this ruleset.  They contain an large amount of valuable information.

  1. http://wiki.centos.org/HowTos/OS_Protection#head-c6bf533e4f6de1ff3e13d556053fc40bc121e5cc
  2. http://www.openwall.com/passwdqc/README.shtml
  3. http://www.puschitz.com/SecuringLinux.shtml#LockingUserAccountsAfterTooManyLoginFailures
  4. http://www.linux.com/archive/feature/113807

Solaris 10 Password Policy Enforcement

Image Credit: Ohio State University

I was recently handed a baseline policy that was to implemented for all users on the Solaris 10 systems that I support.  After a small amount of research I was able to find the various pieces that needed to be altered.

Desired Policy

After discussion between the security officer and the other management level staff, the following policy was decided upon:

Normal User Password Requirements

  • at least 8 characters in length
  • no more than 20 characters in length
  • contain at least on letter
  • contain at least one number
  • forced to change at least every 180 days
  • 15 minute lockout after 5 unsuccessful attempts

Most of the restrictions were fairly basic and could be easily accomplished.  The only one that I could find no mechanism for control of in Solaris 10 is the automatic unlock of an account after the specified 15 minute lockout.  While it is possible to determine when an account has been locked by looking at the timestamp in the syslog, there is no automated method for unlocking the account after a certain amount of time has elapsed.  I suppose it would be possible to write a script to check the entries in the shadow file then grep the syslog then do some math on the timestamp, but honestly I am not worried about it.


The implementation process involves editing two files that are key to the functionality of user login security.  As always when altering system files it is a good idea to make backups of the originals in case things go wrong.  The files involved are:

  1. /etc/default/login
  2. /etc/default/passwd

Setting the account lockout (aka Three Strikes)

Generally the default on a Solaris 10 system is to set the account lockout to three password retries before an account is locked.  We decided to relax this a little and allow for five retries.

  1. Open /etc/default/login in your favorite editor
  2. Search for the line reading RETRIES=3
  3. Change the line to read RETRIES=5

Configuring the complexity rules

The password complexity ruleset for Solaris 10 is fairly understandable.  The rules are defined in /etc/default/passwd and the values to be tweaked are:


The desired policy decided upon was to require at least one number and one letter.  There was some discussion about special characters, but it was decided to not require any special characters for normal user accounts.  Given these requirements the following process is used to implement the complexity ruleset:

  1. Open the file /etc/default/passwd in your favorite editor
  2. Set the password complexity tunables to look as follows

Setting the password expiration and length rules

Configuring account lockouts and password complexity is a great start, however it is not the complete picture.  While reasonable complexity rules will allow users to set passwords that they can readily remember, and a flexible lockout value will give some room for fumble fingers, if users are not required to change their passwords every so often then the security of the system can suffer as well.

You also should consider password length.  A shorter password, regardless of complexity, is going to be easier to crack from an algorithmic standpoint.  This is simply due to the mathematical requirements.  The problem is that user’s tend to not like long passwords.  As you increase the password length, you increase the likelihood the passwords will use dictionary words (we can account for that as well).

The agreed upon setting for normal users on our systems was 180 days.  Unfortunately Solaris 10 uses a setting measured in weeks and not days.  What this means is that the setting will have to be slightly longer.  The password length was decided to be at least 8 characters and no longer than 20 characters.  Also, Solaris 10 has no setting to enable a maximum password length.

  1. Open /etc/default/passwd in your favorite editor
  2. Set the value for MAXWEEKS to be the value of number of days divided by 7, rounding up
  3. Set the value for PASSLENGTH to be the value of the minimum number of characters

Important Notes and Considerations

Password Length

The default algorithm used for passwords under Solaris 10 is crypt_unix.  This algorithm is not considered sufficiently secure, even by Oracle.  You should investigate using a different algorithm such as MD5 or Blowfish instead.  The default will not allow for passwords that are longer than 8 characters.  You can set the password to be longer, but all characters after the eighth position will be discarded during the authentication check process.

Retroactive Usage

Changes to the password expiration policy is not immediately retroactive.  For the expiration requirements to take effect on existing accounts you will need to initiate a manual password change for the shadow file entry to be updated.

Dictionary Words

When Solaris 10 was introduced one of the changes made to PAM was the ability to use a comma-delimited list of dictionary files to avoid usage of common words during password selection.  This can be configured with the DICTIONLIST variable in the /etc/default/passwd file.

Applying lockout to the root user

While this is not the default, you can apply the lockout rule to the root user account by editing the /etc/user_attr file and changing the lock_after_retries value for this user to yes.  Be warned this is not recommended since a locked account can only be unlocked by the root user.  If your root level account becomes locked then you will need to have an account that allows sudo access or you will end up going to some extreme lengths to re-enable access to the system.


Of course, none of this information is really unique.  Here is the list of resources I used to put all of this together:

  1. http://blogs.sun.com/gbrunett/date/20040923
  2. http://docs.sun.com/app/docs/doc/816-4557/6maosrjds?a=view
  3. http://docs.sun.com/app/docs/doc/817-0547/esqeq?l=en&a=view
  4. http://docs.sun.com/app/docs/doc/816-5175/crypt-unix-5?l=en&a=view

For more commentary on password length, complexity, etc., see a few of these sites:

  1. http://www.infoworld.com/d/security-central/password-size-does-matter-531?page=0,0
  2. http://www.avertlabs.com/research/blog/index.php/2007/11/02/password-policy-length-vs-complexity/
  3. http://www.symantec.com/connect/articles/simplest-security-guide-better-password-practices
  4. http://www.symantec.com/connect/blogs/password-survey-results
  5. http://www.computerweekly.com/Articles/2009/03/10/235217/Web-users-stick-to-one-password-survey-reveals.htm

Moving into the cloud


One of the current hot topics in many technology circles concerns the cloud-computing model.  Wikipedia has the following definition for cloud computing:

a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.

One of the biggest criticisms and concerns with this approach is the ownership, integrity, and security of the data.  At work we are struggling with this concept as well.  We are investigating moving our student e-mail into either Microsoft’s or Google’s online mail model.  From an economic approach it seems very cut-and-dried.  If we move the data for our users into the cloud then we cut down on our data storage, server and basic infrastructure costs.  However, the legal ramifications of this are interesting.

Faculty and staff data are to be kept inside the enterprise due to concerns over the possibility that their mail would contain confidential or sensitive data, such as grade information, student id numbers, etc.  What is interesting is that if a student is the recipient of an e-mail from a faculty or staff member that contains this information then the confidential or sensitive data has been placed in the cloud whether or not the faculty or staff member wanted it that way.

I have been dealing with this in a small way myself while trying to decide if I should move all of my personal mail into Google (which already hosts my mail accounts using the Google Apps services).  Do I rely on the large scale backup and storage of Google?  At first I was concerned that I might loose connectivity during a rare outage of the GMail system.  But I realized that I only check my mail using a full client on my machine at home.  Everywhere else I rely on an imap connection or the web interface.  So I have made the leap!

Now to work on making my GPG signature stuff work with GMail’s web interface.