Browser Search Tools

In addition to the search engine tips I posted about yesterday, here are some browser specific tips for speeding up your searches on an individual page:

Finding Words on a Page
Suppose I want to find out if Jabian is in the S&P 100. I navigate to Wikipedia & look up the S&P 100 list of companies. Instead of scanning through the entire list (and possibly missing an entry) I can use the built in search (find) function in my browser. In Firefox & Internet Explorer, press the “Ctrl” button in conjunction with the “F” Button (Ctrl+F).

This will bring up a search box in the browser where you can search (see area highlighted in pink in the picture above). As you can see, Jabian is not (yet) in the S&P 100.

Searching from the Address Bar

Did you know that instead of navigating to Google (or Bing, or whatever your favorite search engine is) – you can type your search criteria directly into the address bar of your browser? Firefox & Chrome default to Google while Internet Explorer defaults to Bing. You can usually change the default search engine in your browser’s options menu.

Type your query into the address bar & hit enter to load.

Your results will be automatically sent & loaded in your default search engine.

Think your browser hotkeys are safe? Think again…

Great article on how a hacker can use simple javascript to trick you into giving up your passwords. Become a Security “Thinker” and don’t fall for these tricks!

ArsTechnica: How script kiddies can hijack your browser to steal your password

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 5 of 5

Part 1 of this series may be found here.
Part 2 of this series may be found here.
Part 3 of this series may be found here.
Part 4 of this series may be found here.

Safari

I must admit, I was pretty surprised by how hidden Apple made their security information. After years of hearing how horrible Safari is in terms of general security – their password security is actually pretty decent. unfortunately, it too is able to be hacked if you know what you’re doing.

Safari stores your usernames and passwords in a file called “keychain.plist” in the following folders:

Windows XP:
C:\Documents and Settings\[username]\Application Data\Apple Computer\Preferences

Windows Vista\7]
C:\Users\[username]\AppData\Roaming\Apple Computer\Preferences

Sorry Mac users, I don’t know where this is stored on a Mac… If someone wants to give me a Mac, I’ll be more than happy to research it for them… 🙂

The contents of this file are pseudo-encrypted because it’s stored in a “Binary Property List” file format which is an Apple format for storing binary data. If you just open the file it will look like garbage. However, Apple provides a tool called plutil.exe that can read this format and it’s actually provided with Safari in the following folders:

Windows x86:
C:\Program Files\Common Files\Apple\Apple Application Support

Windows x64:
C:\Program Files (x86)\Common Files\Apple\Apple Application Support

Run this program in DOS using the following commands:

plutil.exe -convert xml1 -s -o [Output Path\output_file.xml] [Path to keychain.plist file]

This will convert the .plist file into an XML file. In the XML file, everything will be decoded except for your password which will be inside an tag called

The encrypted password is encoded using the BASE64 algorithm. Bizarrely enough, the original password data stored in the keychain.plist file is not encoded with BASE64. It is only encrypted to BASE64 when converting the .plist file into XML using the plutil program. In the .plist file, the password is encrypted using standard Windows Data Protection (DPAPI), which provides the known functions of CryptProtectData and CryptUnprotectData for encrypting / decrypting of data using your Windows authentication password. When using CryptProtectData, Safari uses a standard, static salt for all passwords which is also stored in the keychain.plist file.

So to actually decode the XML file, you must first decrypt the BASE64 encrypted data, then decrypt the Windows DPAPI encrypted data. Easy right?

BASE64 encryption can easily be broken with free code available online. From there, you need to figure out the salt to use with the Windows DPAPI CryptUnprotectData function.

For the curious, the salt generation algorithm and decryption functions are available in the Apple supplied CFNetwork.dll file which can be found in the following folders:

Windows x86:
C:\Program Files\Common Files\Apple\Apple Application Support

Windows x64:
C:\Program Files (x86)\Common Files\Apple\Apple Application Support

The salt data in the .plist file is 144 bytes long and ends with “com.apple.Safari”. Once you find the Salt in the .plist file, you can easily decrypt the passwords using the CryptUnprotectData function (available on the Microsoft MSDN website).

As you can see, Safari is much more complicated than other browsers but in the end, it’s just as easy for someone who knows what they are doing to hack.

Summary

I think that all the browsers fall short in one area or another. Firefox comes the closest but only if you enable a Master Password. IE9 has good security for Autocomplete data, but only if you do not store website history. Chrome fails in terms of protecting your usernames and passwords from any key loggers. Opera fails completely because it uses a known, static salt. Safari surprisingly enough provides decent security from someone who doesn’t know what they are doing but a true hacker should be able to decrypt your passwords with some patience.

My recommendation? Use Firefox, keep it updated and enable a strong Master Password. Again, I refer you to check out XKCD’s Password Strength cartoon for tips.

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 4 of 5

Part 1 of this series may be found here.
Part 2 of this series may be found here.
Part 3 of this series may be found here.

Opera 10 and above

Opera stores the following information in an encrypted file called wand.dat:

• Login URL
• Main website URL
• Username field ID
• Username
• Password field ID
• Password

The wand file stores the data in encrypted blocks consisting of the following fields:

• Size of encrypted block (4 bytes)
• DES Key Length (1 byte)
• DES Key (8 bytes)
• Size of encrypted data (4 bytes)
• Encrypted data

Wand.dat is stored locally on your computer in the following locations:

Windows XP:
C:\Documents and Settings\[username]\Application Data\Opera\Opera\wand.dat

Windows Vista\Windows 7:
C:\users\[username]\AppData\Roaming\Opera\Opera\wand.dat 

The issue with Opera’s security is that it uses a static salt to encrypt the data. The salt is:

0x83, 0x7D, 0xFC, 0x0F, 0x8E, 0xB3, 0xE8, 0x69, 0x73, 0xAF, 0xFF.

To decrypt the data, a hacker simply retrieves the DES key (8 bytes) from each encrypted block of data in the wand file. They then compute the MD5 checksum of the byte stream consisting of the salt and the retrieved DES key. Next, compute another MD5 checksum of the byte stream consisting of the first MD5 checksum, the original salt and original DES key (in order). These two MD5 checksums are used to create schedule keys for decryption with a DES vector component comprised from the second MD5 checksum. Finally, the data can be decrypted using the known Triple DES decryption function. The decrypted data will be stored in Unicode but you can easily convert it into ascii.

End result – a hacker only needs a copy of your wand.dat file to easily decrypt all your usernames and passwords.

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 3 of 5

Part 1 of this series may be found here.
Part 2 of this series may be found here.

Firefox

Firefox by default has lousy security. However, if you enable the Master Password option (off by default), Firefox has the most secure security… go figure.

Firefox stores usernames and passwords in a SQLite database called signons.sqlite which can be found in the following folders:

Windows XP:
C:\Documents and Settings\[user_name]\Application Data\Mozilla\Firefox\Profiles\[random_name].default

Windows Vista\7:
C:\Users\[user_name]\AppData\Roaming\Mozilla\Firefox\Profiles\[random_name].default

In the SQLite database, the username and password are encrypted using Triple DES and BASE64 encryption algorithms. The decryption hash is stored in a file called key3.db in the same folder structure. By default, if a master password is not set, Firefox will allow any user to open up the signons.sqlite and key3.db files to view the usernames and passwords directly in the browser, no questions asked. As long as someone has a copy of the two files, they can transfer them to any machine and view the data.

However, if the Master Password is set, then Firefox will store a one way hash in the key3.db file and require you to input the password to generate a matching hash in order to decrypt the signons.sqlite database. Without the Master Password, no one can decrypt the data. Therefore, your data is as secure as your Master Password. Without it, there’s virtually no security on your data.

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 2 of 5

Part 1 of this series may be found here.

Chrome

Chrome’s encryption in theory is great so long as you can ensure that there is no malware running on your computer. Considering the latest exploits of the Stuxnet and Flame viruses, I think it’s pretty obvious that cannot always be assured. Chrome stores usernames and passwords in a SQLite database called Login Data located in the following locations:

Windows XP:
C:\Documents and Settings\[username]\Local Settings\Application Data\Google\Chrome\User Data\Default 
	
Windows Vista\7:
C:\Users\[username]\Appdata\Local\Google\Chrome\User Data\Default

In the database, the only field which is encrypted is the actual password, URLs and usernames are not. The encryption used is the Triple DES algorithm using the Windows user’s login password as a seed. This allows only someone logged into that username / password combo on the computer to view the passwords. However, it cannot prevent any malware running on the system from stealing that user’s passwords.

Browser Security: How Firefox, MS Internet Explorer, Chrome, Opera & Safari store usernames & passwords – Part 1 of 5

NOTE: There is an update for IE10 password security available here.

As a follow-up to my previous post on the LinkedIn security breach (See post) I decided to research how different browsers protect your stored usernames and passwords.

This will be a 5 part series, one for each browser because some of the browsers have quite a bit of security to get through. Please keep in mind that I am only discussing how the most recent versions store usernames and passwords. Also keep in mind that this information is only as current as the date at which this article is published. Browser security is constantly being upgraded and changed.

With those disclaimers, let’s begin:

MS Internet Explorer 9 (IE9)

IE is still the most used browser and in some respects uses the most interesting encryption methods. Internet Explorer stores two type of passwords, Autocomplete and HTTP basic authentication based passwords. Autocomplete passwords are normal website login passwords such as gmail, Facebook, LinkedIn, etc. HTTP basic authentication passwords are network login passwords for LANs, etc.

With version 7 onwards, IE stores all the Autocomplete passwords in the following registry location in an encrypted format:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2

Each entry in the registry key corresponds to a hash of the website URL corresponding to the username / password for that URL. Every time you visit a website with a username/password field, IE computes the hash of the website URL and tries to match it to an entry in the registry key. Thus, if you delete your browser history on a regular basis, the only way that a key can be decrypted is if someone knows a specific URL or if someone accesses your machine and uses your version of IE to revisit a website that IE has an entry stored for.

The HTTP basic authentication passwords are stored in the ‘Credentials Store’. The ‘Credentials Store’ is in the following location:

Windows XP:
C:\Documents and Settings\[username]\Application Data\Microsoft\Credentials

Windows Vista\Windows 7
C:\Users\[username]\AppData\Roaming\Microsoft\Credentials

The HTTP basic authentication passwords are encrypted using built in Windows Cryptography functions and are salted with the text generated from the Windows GUID ‘abe2869f-9b47-4cd9-a358-c22904dba7f7’. The decrypted text contains the username & password pair separated by semicolon.

Windows provides the Credential Management functions to add/remove entries from the ‘Credentials Store’. There is a function called CredEnumerate that allows you to to enumerate through the entries and decrypt them using the CryptUnprotectData function. Because the encryption uses a known salt, the salt is practically worthless if someone can get a copy of the GUID from your machine.

To be continued…