HTTPS Protocols and Ciphers

To give a bit of background on this post –

I was researching different Firefox about:config settings for another article (to be forthcoming) and had changed a bunch of security settings to try and force Firefox to use higher grade encryption when accessing encrypted (HTTPS) websites.

Later in the day, I tried to access a website I visit very frequently and found that it wouldn’t load. I eventually realized that it must be because I had changed my Firefox security settings. The question I was stuck with was, “How do I figure out what encryption protocol and cipher a website is using in order to allow that encryption in Firefox?”. After some more research I was left with the following:

What is HTTPS & how does it work?

When you access a website, you are typically communicating over one of two protocols: HyperText Transfer Protocol (HTTP) or HyperText Transfer Protocol Secure (HTTPS). When you connect using HTTPS, all the information sent back and forth between you and the website is encrypted.

There are of course exceptions to this – for example, on your bank’s website, it may have a secure component for logging into the website but it may also have a third party advertisement that is not delivered encrypted to your browser. Depending on your browser, it may alert you when there is “mixed” content being loaded.

At a high level, when you access an HTTPS website, the server has a list of approved protocols and ciphers that it will allow communications to be encrypted with. This list is either the default list that the server comes enabled with (i.e. no one really thought about it, they just turned it on), or it’s a customized list that (hopefully) only allows the latest and greatest encryption methods.

Just like the server, your browser has a list of approved protocols and ciphers that it can use. When your browser contacts the server to load the HTTPS page, the server gives it a list of the approved encryption methods – this list is prioritized by the server’s “preference”.

Assuming your browser allows connections using one of the approved server’s methods, the browser and server conduct a “handshake” where the encryption method and a key are agreed upon and exchanged, allowing both the server & the browser to encrypt and decrypt communications between them. When the “handshake” is conducted, it is the most dangerous part of the communications process because it is done without encryption and (if done improperly) can allow for “man in the middle” (MITM) attacks or other attacks by an outside party. (I hope to cover different types of attacks and how they work in a future article.)

So what’s the difference between a protocol and a cipher? Think of encryption protocols as the method by which information is encapsulated and sent whereas ciphers are the way which information inside the capsule is scrambled (encrypted) to prevent anyone from reading the information.

Determining a Server’s allowed Protocols and Ciphers

This leads us back to my original question – if your browser does not accept the encryption types allowed by the server, how do you figure out which ones you need?

I found that there is a very handy website called http://www.ssllabs.com that has a SSL Server Test tool (available here: SSL Server Test) that allows you to plug in any website and it will determine if there are any available HTTPS connections to that website as well as give you a high level score and a very detailed breakdown of the site’s security protocols and ciphers.

There is also a Firefox plug-in available (called CipherFox) to give you this information every time you visit a website.

Tomorrow I will cover which Protocols and Ciphers are best to use & how to implement them in your Firefox browser.

Got questions or feedback? let me know in the comments below. Thanks!

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.

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

Note: This is an update to my original article

With the release of IE10, Microsoft has changed how Internet Explorer stores passwords. Previously, for versions IE7 through IE9, the browser would store auto-completed passwords in the registry and
HTTP basic authentication passwords in the Windows Credentials Store (aka Vault). As a refresher: Auto-complete passwords are normal website login passwords such as gmail, Facebook, LinkedIn, etc. HTTP basic authentication passwords are network login passwords for LANs, etc.

The encryption method that IE7-IE9 used for storing auto-complete passwords was very difficult to defeat, whereas the Credentials Store was much easier to break into to recover passwords. Therefore I was very surprised to learn that in IE10, Microsoft now stores ALL passwords in the Windows Credentials Store – with no new security measures!

The Windows Credentials Store is only protected with the regular DPAPI, and can be (relatively) easily cracked. All private entries of a user can be found in his profile. By default, the folder
is in:
C:\Users\<USER NAME>\AppData\Local\Microsoft\Vault\<VAULT_UID>
where
<USER NAME> = user name &
<VAULT_UID> = Vault identifier. By default, the value is: 4BF4C442-9B8A-41A0-B380-DD4A704DDB28.

Each IE10 password entry is in a .vcrd (Vault Credential) file and the encryption key is stored in the same folder.

This moves IE10 into the same league as Google Chrome leaving Mozilla Firefox as the leader in terms of password security (providing you enable a strong Master 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…