Can’t remember your PIN? Here are some tips for choosing a new one!

In today’s era of computers, the numerical password or PIN is incredibly easy for a computer to guess. That being said, here are some ideas to make the number you choose harder to crack and easier for you to remember.

First off, a computer can guess any numerical PIN less than 11 digits long in about 2 seconds thanks to the power of iterative guessing.
The best way to protect your PIN is to enable a time out on whatever device you have. For example, on your phone or tablet, if someone enters the wrong PIN more than X number of times, it wipes the device’s data, or it makes you wait a minute between each try, etc.

Next, try using the following methods to pick a PIN that’s difficult (for a human) to guess, but that you can remember:

• Make your PIN as long as you can. This will depend upon your device & your memorization abilities. Assuming you can use all 10 digits (0 – 9), a 4 digit PIN gives you 10^4 or 10,000 possible combinations. 5 digits gives you 100,000, etc. The longer the PIN, the harder to guess.
• Don’t use a number someone else would know (such as your birthday).
• Use the keypad on your phone to spell a random word that you will remember. E.g. NAME = 6263).
• Make a sentence out of numbers. E.g. using the first letters of each word in “This Sentence Is Awesome!” gives a PIN (on a phone keypad) of 8742.
• “Encrypt” your password by appending another number to it. E.g. if your birthday is July 19th, choose a PIN of 0719 and then tack on another number (such as the last 4 of your phone number) to give you: 07191234
• Don’t use a common PIN – 10% of PINs equal 1234, another 10% are 0000 and 1111. That means that 20% of the time, I can guess your PIN using those 3 numbers. A number like 2580 looks random but it’s the 22nd most common PIN. Why? Because it’s straight up & down on a phone keypad. Be unique – don’t follow the herd.
• Use sports players jersey numbers. This doesn’t work for me because I’m not a sports guy, but for those of you who are – just concatenate the jersey numbers of your favorite players together. E.g. Babe Ruth (3) + Lou Gehrig (4) + Yogi Berra (8) could give you a PIN of 030408.
• Choose a number you like such as your birthday and then subtract or add another number you like. So your birth year might be 1955 and your wedding year might be 1978. The difference is 23. Subtract 23 from your birth year to get 1932. To make it even harder to guess, reverse the numbers to get 2391.
• For a bank card, use the assigned random PIN and memorize it.

Helpful? Got tips or tricks of your own for remembering PINs? Share in the comments below!

~Yosef

HTTPS Protocols and Ciphers Continued

Yesterday I introduced you to HTTPS protocols and ciphers. Today we will focus on:

Which protocols and ciphers are (currently) best to use?

There are two types of protocols, SSL & TLS (SSLLabs checks both types).

SSL

• SSL 1.0 was never publicly released
• SSL 2.0 is considered insecure at this point
• SSL 3.0 is considered generally secure but highly depends on which cipher it’s using as well as if the browser protects against what’s known as “BEAST” (Browser Exploit Against SSL/TLS) attacks.

TLS

• TLS 1.0, like SSL 3.0 is considered generally secure but highly depends on which cipher it’s using as well as if the browser protects against BEAST attacks. In addition, TLS 1.0 allows for interoperability between TLS 1.0 & SSL 3.0, however this weakens the protection provided by TLS 1.0 and is not advised.
• TLS 1.1 is generally considered secure depending on the cipher used.
• TLS 1.2 is considered an enhanced version of TLS 1.1 and is again, secure depending on the cipher used.

So which ciphers are best?

Unfortunately, this is dependent on which protocol you are using. In general, all ciphers used with TLS 1.2 are secure except for RC4 (which is never considered secure, regardless of protocol). The main ciphers are as follows:

• AES CBC – secure when used with TLS 1.1 & TLS 1.2. Secure with TLS 1.0 depending on the browser used.
• AES CCM – secure when used with TLS 1.2
• AES GCM – secure when used with TLS 1.2
• 3DES CBC – secure when used with TLS 1.1 & TLS 1.2. Secure with TLS 1.0 & SSL 3.0 depending on the browser used. Insecure when used with SSL 2.0
• Camellia CBC – secure when used with TLS 1.2
• Camellia GCM – secure when used with TLS 1.2
• IDEA CBC – Secure when used with TLS 1.1, Secure with TLS 1.0 & SSL 3.0 depending on the browser used. Insecure when used with SSL 2.0
• DES CBC – Insecure with all protocols
• RC4 – Insecure with all protocols
• RC2 CBC – Insecure with all protocols

Once you know what type of protocol and cipher you need in order to connect to a website:

How do you change your browser to allow/disallow certain types?

I will focus on Mozilla Firefox, my browser of choice. Google Chrome & Internet Explorer allow you to change which protocols they use but you can’t specify the exact cipher.

In Firefox, you can allow / disallow specific protocols and ciphers by going to “about:config” in your URL “Amazingbar” (hit Enter).

Click the “I’ll be careful, I promise!” button to access the settings.

In the Search field, search for “ssl3” to view all SSL 3.0 options. You can double-click on each one to turn it on (TRUE) or off (FALSE).

To set your TLS settings, search for “tls”.

You will see two available settings that allow a range of 0 to 3:

• security.tls.version.min – specifies the minimum required/supported protocol version
• security.tls.version.max – specifies the maximum required/supported protocol version

For example, a min/max of 0 means that the minimum/maximum supported encryption protocol is SSL 3.0. A 1 indicates TLS 1.0, etc.

For more information, see the following article as a starting place: Wikipedia: Transport Layer Security

Questions/feedback? let me know in the comments below. Thanks!

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!

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…