Tag Archives: firefox

Password Manager

Best practice states that passwords should contain letters (mixed case), numbers, and symbols, should be at least 8 characters in length, and should never be used twice. However, this isn’t very practical! How are you suppose to remember a different password for each site you have an account for?

I have been using 4 different password for my various accounts. This method has been working moderately well, but from a security standpoint, it’s suicide. I wanted to use a random password for each of my accounts. But, how would I ever remember all my passwords? A password manager, of course!

What I needed:

  • Passwords stored in an encrypted file
  • Master password to unlock the encrypted file
  • View passwords from the cli/ssh
  • Include additional information such as Security Questions and Answers
  • Integrated support for Firefox

What I used…

Vim Outliner

Vim Outliner is an outline processor. A screenshot is worth a thousand words.


By default when you save the file it will be a simple tab delimited text file. Vim, however, supports encryption. First, you need to set the encryption method by typing :setlocal cm=blowfish. If you want Blowfish to be the default encryption method for vim add the setlocal command to ~/.vimrc. Next, to encrypt the file, type :X. You will be prompted to set a password. Finally, save the file. When you open the file, you will be prompted for the password. If you fail to enter the right password you will see garbage characters.

Firefox Integration  (Mozilla-gnome-keyring)

Mozilla-gnome-keyring allows Firefox to store passwords and form logins in gnome-keyring. Gnome-keyring is much more secure than the default password manager in Firefox. The mozilla keyring must be unlocked to add / retrieve passwords. You can define how long the keyring should remain unlocked for (never, 15 minutes, 60 minutes, etc…). On my desktop I unlock the keyring for 60 minutes, but on my laptop I only unlock it for 10. When logging into a site, Firefox still prompts to  “Remember the Password”.  If you let Firefox remember the password, the password automatically gets recorded in the keyring.


I have been using this solution for about a month and it has fit my needs perfectly. I updated most of my accounts so they each have an unique password such as Dmqngi8ZoPyO or XGVoBOmd7Gar. Passwords are being stored twice: in the password file and in gnome-keyring. Since mozilla-gnome-keyring takes care of adding the passwords into gnome-keyring when I login to a site, I only have to record/update my passwords in the encrypted text file. In the rare case that I’m not at my computer, and I need a password, I simply ssh into my server and open the password file in vim.

Although the password file and keyring is encrypted it is still subject to a brute force attack. Make sure to use a strong master password, the longer the better. I would suggest at least 20 characters. In 2009, it would take a super computer 1.5hrs to crack an 8 character (alpha only; lower-case) password, but it would take 631 Billion years to crack a 20 character (alpha only; lower-case) password. Remember, as computers advance these times will decrease. And of course, a key logger could compromise the master password nearly instantly.



Webkit has been a piece of software I have been interested with for quite a while. For those who do not know, webkit is a web rendering engine. Safari and Google Chrome are two popular browsers that use webkit as their rendering engine.

Webkit was forked from the KHTML project by Apple in 2002. At the time it was know as WebCore and JavascriptCore.  A year later, Apple provided patches to the KHTML project. The KDE team was able to use some of the code, but much of it was poorly documented and the coding style differed greatly. In 2005, Apple opensourced their fork (WebCore and JavascriptCore) as webkit.

I first gave webkit a shot about a year or so ago. I read about midori, a web browser that uses webkit, and I decide to give it a try. Midori was very simple and basic, which I liked and it was faster than firefox. However, webkit would crash a lot when loading/rendering web pages, resulting in midori crashing. Of course nobody likes this and I switched back to Firefox. From that point on, I was impressed with what was going on and tried the combination of webkit/midori every few months.

Over the last year, there have been huge improvements with webkit.
Here is a look at the current status of webkit:

The Good:

  • Spell Check support. Let me explain. When spell check support was introduced it would detect misspelled word, but there was no way to see a list of suggestions or pick a suggestion. Before, when a suggestion was picked it would erase the word!  Now, it is possible fix the spelling mistake by selecting (highlighting) the word and right clicking. It is a tad bit annoying that the whole word needs be selected, but it something that you get use to.
  • Fast: If you thought Firefox was fast, webkit is even faster and it seems to do pretty decent job at rendering javascript quickly too.
  • HTML 5 Video: Youtube has deployed HTML 5 videos which only work in webkit based browsers at the moment. There are two file formats for html 5 video: OGG Theora and H264. Mozilla wants ogg theora to become the norm because it is an open and free format, whereas h264 is bound with licensing restrictions and the future is unknown for the codec (will it remain free?). Due to Mozilla stance on the issue and licensing issues, Firefox only works with OGG Theora video clips. Youtube videos are encoded in H264 therefore they won’t work with Firefox. Webkit gets around this issue by using the native operating system’s video player. In the case of linux, webkit uses gstreamer, which results in all videos being processed by gstreamer, not webkit.
  • Developer Tools: Although the inspect page/element program needs some work, it has some very promising features. It is similar to firebug, but it also has features that allow you to see what is being stored locally (cookie, session info, etc..), how fast your page is loading, how long each element takes to load, an error console, and a scripts debugger.
  • Independent: Webkit is independent from any browser. This makes it much easier to integrate webkit into a web browser. Google chrome, Safari, Midori, Aora, and Uzbl are just a few browsers that use webkit as their rendering backend. As a result, you get developers that will provide patches to Webkit because they want their browser to do x, y, z or render pages better.

The Bad:

  • Crashes: Although all web browser crash at some point in time webkit still seems to crash every now and then. Granted, within the last few days I’ve only had one or two crashes, but Firefox and other browsers rarely ever crash (unless if flash is loaded). However, Midori and other webkit browsers can restore the session if their is a crash.
  • API: There is still a lot that needs to be done with the API. For example, form auto complete needs to be implemented. Any form auto complete that is seen right now is being implement by the browser (midori, safari, chrome). It would also be nice to get right click spelling to work (without having to select the word). Lastly, the organization of the right click menus could be improved.
  • Webpages: There are a handle full of web pages that simply won’t work with webkit right now. The two that come to mind are the University of Akrons Zipline (Student Center, specifically) and Cisco Netacad. Both of these sites use long and complex URLs and the cisco netacad site is built around flash.

Webkit has seen major improvements, but still has a long way to go until it reaches the maturity and stability of other browser on the market. I would consider webkit to be usable on day to day basis providing you don’t have to access one of those overly complex pages that don’t work well with webkit.

Arch Linux AUR Packages:
midori-git: http://aur.archlinux.org/packages.php?ID=14349
libwebkit-nightly:  http://aur.archlinux.org/packages.php?ID=34814