Tag Archives: ssl

World is Too Slow to Adopt Two-Factor Authentication

Posted by on September 25, 2012 No comments

Here’s the deal: you do a lot of business online. Amazon purchases, you check your X-Box account, access social networking sites and so on. And as I’ve said time and again, man in the middle attacks are at an all time high. So you needed a way of securing your online accounts beside using just a password.

While some sites like Facebook, Google and Dropbox have implemented forms of two-factor authentication, many sites do not (to my knowledge Apple and  Amazon have not implemented TFA security). SSL alone doesn’t protect customers from online threats.  Amazon AWS does support multi-factor authentication but, at the time of writing this, their user accounts do not have this feature (upon asking their technical support why they didn’t use TFA, I was told “SSL was secure” and not to worry).

For those left out of the loop, TFA relies on either texting you an ever changing security key or displaying one using a token generator (such as the great Google Authenticator for Android). Logging into a website from an unknown computer (one where a former cached login could not be found) results in a page asking you to confirm a key displayed on your token generator.

The way it works now if you don’t remember your password? A reset email can be mailed to you… not such great security. It sends an email to the account you registered with. If your email account is compromised to begin with, your other accounts can be too. All the SSL in the world doesn’t amount to a hill of beans if you don’t have better security practices for users that want to make use of them.

Social engineering attacks can also be used to get companies to change your passwords by phone. Apple and Amazon have already been caught doing this. For more information see my post entitled “Apple’s Social Engineering Crisis.”

So why don’t sites adopt TFA? They don’t want to be bothered implementing it. Really. That’s the only excuse I can think of since, if companies follow Google’s example, you have to manually opt in to using it in the first place.

So enough is enough. Start telling the companies that you do business with online to enact TFA now.

Related Articles (Better than this rant)

“Please Turn on Two-Factor Authentication.” Curts, Matt @ Lifehacker.

“Two-Factor Authentication: The Big List Of Everywhere You Should Enable It Right Now.” Gordon, Whitson @ Lifehacker Australia.

“XBox GM Talks Xbox Live Security.” Frederiksen, Eric. July 19,2012. See: http://www.technobuffalo.com/gaming/platform-gaming/xbox-upgrading-security/

Products of Note

Google Authenticator for Android

Google Authenticator for iOS

SolidPass Two-Factor Authentication Token (Used in many places)

Related Blog Posts

“Public Wi-Fi? Be Mindful of Session Hijacking“

Public Wi-Fi? Be Mindful of Session Hijacking

Posted by on August 1, 2012 No comments

Cache Exploitation & Sidejacking (Session Hijacking)

Tools

* Firesheep Packet Sniffer on PC
* FaceNiff or DroidSheep on Android (rooted)
* Other MITM (man in the middle software; no packet injecting capable NIC needed!) For more on MITM attacks please click here (Schneier on Security; 7/15/2008).

The risk

The most common type of cache exploit can be seen using Firesheep which takes unencrypted data passed via cookies over a Wi-Fi network and reveals them (works well with social networks and sites that do not appropriately handle user data transmission).

Although some data may be handled via SSH (encrypted), the actual cookies, for logins are not on some insecure sites. Some social networks and heavily trafficked websites have sought ways of solving the problem but not all evolve accordingly. So long as they don’t, this exploit will work and has done so for many years.

These type of exploits could be known as the “The Starbucks Social Network Exploit” for all intents and purposes since places that offer free wi-fi are at risk.

Naturally ANY wi-fi network is at risk. As we see with Aircrack and WEP/WPA cracking, any reasonably secure network can run the risk of MITM attacks. Another way of bypassing security measures is by ARP poisoning once one has gained access to a network, assuming the identity of a networked computer. Another reason why you should only join relatively secure networks that allow SSH tunneling.

Protecting yourself

* Use SSH tunneling to connect to your VPN/proxy setup after connecting to open wi-fi.
* Always try to use SSL/TLS enabled variations of web pages (if you use Firefox please be sure to download and make use of the HTTPS Anywhere Addon).
* Use encrypted connections, using only protected wi-fi networks not public ones or at least trusted ones.
* Urge wi-fi network admins to monitor ARP tables and run appropriate IDS and conduct other server-side preventative measures.