1) Create a Link. 2) View it, send it, blow it up.

Put Hackers Against the Clock

As a development company, we either require, or maintain login information for servers, mail accounts, or applications for our clients- all of which are generally secured by a username and password. So when we need login information, we get it in an email. This confidential information remains in our sent folder, the clients inbox, and maybe on some of our mobile devices (if we choose to sync them). We decided we needed a way to send confidential information, but not have it linger inside an email client. Timebomb.it creates random URL’s for logins, with the option to blow it up in 1-hour, 1-day, or 1-week. Now we just send that link over, and know that if a hacker gets a hold of our computer in a year, our email account isn’t peppered with our clients usernames and passwords.

A Simple Interface, Because it Should Be

Our background in mobile webapps gave us the tools to make this thing mobile-ready out of the box. Using HTML5, CSS3, and custom jQuery scripts, we are seeing sub-500ms load times on a regular internet connection. The only images used are on the timebomb.it about page, which is full-width for most screens, and scales seamlessly on a mobile device. We figure with some of the odd situations you could use timebomb.it for, you want it viewable on a phone, quick to access, and easy to read:

- You need the alarm code for your grandmas garage door (just use the password field)
- You want your mom to send you the logins to your AT&T account
- Your co-worker emailed you asking for the credentials to the computer in the testing lab
- You reset the combination-code door lock on your office building, and want to inform your employees

Once you have created a link, we even have the option to “Blow it Up”; not only because it is fun to blow things up, but because you might decide you no longer want the information available. Each data field uses a mix of custom Flash and Javascript enabling a cross-browser click-to-copy feature. We set out for a professional design so users trust it, and super-transparency with the presentation of information- hopefully you agree this is a “mission accomplished”.

Passwords love encryption, give them some love.

We use an SSL encrypted connection, or HTTPS, to transfer all information to and from timebomb.it over the internet. This means people snooping your network can’t get a hold of anything you type in, or look at. Our databases are also completely encrypted, expired links are deleted every hour, and no link is ever used twice. Our servers have brute force detection, strict firewalls, and are behind bullet proof glass with armed guards (thanks Media Temple). We currently use a 10-character alpha-numeric random string to generate links; this means there are 3,656,158,440,062,979 (3.65 quadrillion) links available. Put it this way, the odds someone winning the lottery, getting struck by lighting, and dating a supermodel in their lifetime are better than their chance of finding a timebomb.it link (remember, links must expire within a week).

CIA: Confidentiality, Integrity, Availability

This acronym represents the three widely accepted components of information security. We have described how we address confidentiality and integrity using some great technology, but the most important aspect is availability. Sure, random URL’s may not be a great idea to send nuclear launch codes, but its a heck of a lot better than sending them in a plain-text email. In security we make trade-offs, and we know that if a system is too hard to use, or takes too long to access, it will get scrapped. Our mission is to provide something really secure, and to force people to think about things like security and password management, while not slowing them down.

Thats a Wrap, plus an API with a Wrapper

We never want to leave our automation-loving, UI-enhancing developers without something neat and exciting, and this is why we made a simple API and PHP wrapper, check it out: timebomb.it API and PHP Wrapper Class. Please make sure to leave you thoughts in the comments, we hope you all enjoy this little tool.

Using the API with JSON

We require four pieces of information for the API to process successfully: the API key, a username, a password, and an expiration value. If you have tried out timebomb.it, this should make perfect sense. The API is accessed through the following URL structure:

https://timebomb.it/api/json/APIKEY/USERNAME/PASSWORD/EXPIRATION

The only somewhat non-standard entry is the EXPIRATION value. This will be set to either a 1, 2, or 3, corresponding to 1-hour, 1-day, or 1-week expiration time respectively. The output will be a JSON encoded string with the following keys:

username : provided username
password : provided password
url : timebomb generated URL
expiration : seconds until link expires
created : unix timestamp

Example Input:

https://timebomb.it/api/json/Y8dqEisNoAChS6AFmwyQ1LoJ/elvis/bluesuedeshoes/1

Example output:

{“username”:”elvis”,”password”:”bluesuedeshoes”,”url”:
“https:\/\/timebomb.it\/4dewszeaoa”,”expiration”:3600,”created”:1282529729}

We suggest reading the HTTP header status in order to gain details on the success or failure of the request. The following statuses are returned based on the request:

Status = 202 : Request Successful
Status = 404 : Request Denied, Check Data Structure
Status = 500 : Request Denied, Possible timebomb.it Error

PHP Wrapper Class using cURL

We have created a basic PHP wrapper that can be used as a standalone class, making it pretty simple to integrate timebomb.it into your application. Of course it’s not perfect, that will be subject to your application, but it will get you off the ground quickly. We are using the PHP library cURL, which you probably have if PHP is installed on your server, otherwise look at How to Install cURL for PHP. Below is the standard usage for the timebomb.class.php wrapper.

<?php
require_once('timebomb.class.php');
$tb = new Timebomb();

$data = array(
	"key"=>"Y8dqEisNoAChS6AFmwyQ1LoJ",
	"username"=>"elvis",
	"password"=>"bluesuedeshoes",
	"expiration"=>"1"
	);

$timebomb = $tb->create_link($data);

if($timebomb['success'])	{
	echo $timebomb['url'];
}	else	{
	echo $timebomb['message'];
}

/*$timebomb_data array elements
	$timebomb['success'] : TRUE or FALSE
	$timebomb['message'] : status message
	$timebomb['username'] : provided username
	$timebomb['password'] : provided password
	$timebomb['url'] : TimeBomb generated URL
	$timebomb['expiration'] : seconds until link expires
	$timebomb['created'] : unix timestamp
*/

//Use for auto-generated passwords
//$password = $tb->create_password();

We have added a simple password generator to the timebomb.class.php wrapper as well, just in case you want to produce them on the fly. The “timebomb” array returned from the class is described above in the PHP comments, and provides all the important information about the created link, or if there was an error. Below is the source for the timebomb.class.php wrapper, and we have provided both of these files in a ZIP package for convenience.

<?php
class Timebomb	{

	function create_link($timebomb_info)	{
		$url = implode('/',$timebomb_info);

		$ch = curl_init('https://timebomb.it/api/json/'.$url);
		curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0');
		curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 30);
		curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
		curl_setopt($ch, CURLOPT_HEADER, 1);
		$curl_data = curl_exec($ch);
		$curl_info = curl_getinfo($ch);
		curl_close($ch);

		if($curl_data != FALSE)	{
			$timebomb_data['status'] = $curl_info['http_code'];

			switch ($timebomb_data['status']) {
				case 202:
					$json_data = substr($curl_data, $curl_info['header_size']);
					$timebomb_data = json_decode($json_data,TRUE);
					$timebomb_data['success'] = TRUE;
					$timebomb_data['message'] = 'Congrats, your TimeBomb link was created.';
					return $timebomb_data;
					break;
				case 404:
					$timebomb_data['success'] = FALSE;
					$timebomb_data['message'] = 'Please check your inputs and make sure you have a valid TimeBomb API key.';
					return $timebomb_data;
					break;
				case 500:
					$timebomb_data['success'] = FALSE;
					$timebomb_data['message'] = 'TimeBomb may have blown itself up, please try again.';
					return $timebomb_data;
					break;
				default:
					$timebomb_data['message'] = 'Houston, we have a problem with something, not sure who to pin it on right now.';
					$timebomb_data['success'] = FALSE;
					return $timebomb_data;
			}
		}
		$timebomb_data['message'] = 'The cURL process failed.';
		$timebomb_data['success'] = FALSE;
		return $timebomb_data;
	}

	function create_password($length=12) {
		$chars = array_merge(range('a', 'z'),range('A', 'Z'),range(0, 9));
		$password ='';
		for($i=0;$i < $length;$i++) {
		   $password .= $chars[mt_rand(0,count($chars)-1)];
		}
		return $password;
	}
}

Download the timebomb.class.php ZIP Package

Final Remarks

If you would like to contribute, collaborate, or provide feedback to our timebomb.it project, please be sure to visit the Prime Studios Homepage, or comment on this post. Happy coding everybody.

As a developer, your world might crumble without using FTP (File Transfer Protocol). Oh how we love our port 21, uploading and downloading everything in plain text. However, if you are at all worried about security and integrity of your (and your clients) data and information, you would be much better suited using an encrypted file transfer method like sFTP- the “s” standing for “SSH”, or “secure”.

In our video we talk about the importance of data encryption across the wire, as well as over the air, and show how attackers can take advantage of non-encrypted data transfer. Our alternative to FTP is sFTP, which utilizes the SSH (Secure Shell) protocol for file transfers, providing a fully [public key] encrypted path for the data to flow. We are essentially mitigating any MITM (Man in the Middle) attacks, or network sniffing; where an attacker simply jumps onto your network and steals confidential information as it flows. By using encrypted data transfer, the data can still be sniffed and logged, but it is nearly impossible to make useful. Some of our tips for using sFTP are as follows:

Consider moving your primary SSH port to non-standard location and block the use of port 22.

Never use the root account to log into sFTP (or SSH). Create users with sufficient privileges for particular needs.

Use a client like FileZilla, WinSCP, or Putty for all your sFTP and SSH needs.

As always, security is only as strong as the weakest link, so the first step is to not allow attackers onto you network. Use strong, randomized passwords, and if your router isn’t already using WPA2 for the encryption type, either change the setting, or get a new router! If you are [still] using WEP encryption, you will get cracked faster than a whip on a horses behind. Check the links below for some more info:

Chroot SFTP user on Ubuntu Intrepid

How to Secure SSH Server from Attacks

OpenSSH

ScreenCast Commentary

Today we are going to talk about CSRF (or Cross Site Request Forgery), otherwise known as session riding, see-surf, and XRSF, and how to built a token system in Code Igniter to mitigate any potential attacks using CSRF.

To start, the core of CSRF lies in web browsers making requests that they are “technically” authorized to do, however the user doesn’t actually know the request is being made (otherwise known as a confused deputy attack). Consider things like image tags, or iFrames, they make calls to external URL’s all the time.. if instead of a call to an actual image, the image tag calls a URL with malacious GET variables in the URL, some damage can occur.

One solution to this problem is the use of form tokens, or a unique and random string put into a hidden POST variable and into a cookie every time the page is loaded. This makes it nearly impossible to make a POST request from an external source because that token must be validated on the server side based on the POSTed token value and the set cookie value. Remember the same basic principle works in any PHP application, Code Igniter just makes session management a lot simpler.

Remember if an application vulnerable to XSS (Cross Site Scripting) it could possibly navigate through the DOM and find the token value, making it possible for an automated attack. Read up on the “samy is my hero” MySpace attack for more on that.

End Commentary

CSRF with POST variables is dangerous because an attacker can setup a false form, maybe just asking for your favorite color, and then post hidden content to a form/site that you have a session on. Below is the code we used inside the Code Igniter Auth class and the main controller to implement a form token system.

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class Auth 	{
	function Auth()	{
		$this->ci =& get_instance();
	}

	function token()	{
		$token = md5(uniqid(rand(),true));
		$this->ci->session->set_userdata('token',$token);
		return $token;
	}
}

/* End of file Auth.php */

<?php

class Welcome extends Controller {

	function Welcome()
	{
		parent::Controller();
		$this->load->model('search_model');
	}

	function index()
	{
		if($this->input->post('login'))	{
			$this->session->set_userdata('logged_in','yes');
		}
		if($this->input->post('logout'))	{
			$this->session->set_userdata('logged_in','no');
		}

		if(strcmp($this->session->userdata('logged_in'),'yes')==0)	{
			$data['logged_in'] = true;
			if($this->input->post('search'))	{
				if($this->input->post('token') == $this->session->userdata('token'))	{
					$this->search_model->add_search($this->input->post('search'));
				}
			}

		}	else	{
			$data['logged_in'] = false;
		}

		$data['token'] = $this->auth->token();
		$data['search_amt'] = $this->search_model->post_amt();
		$this->load->view('welcome_message',$data);
	}
}

/* End of file welcome.php */
/* Location: ./system/application/controllers/welcome.php */

Before we try to explain that, lets talk a little about how a lock works. A lock has a set number of pins inside (anywhere between 5-7 pins for a normal lock), each cut to a specific height. When a key with the correct pattern is inserted all the pins line up straight and allow the lock mechanism to rotate (see more at How Stuff Works). The problem for someone without a key is that they need to manually manipulate each pin to the correct height in order to get the lock to rotate/open.

So lets start with a simple comparison, we can easily see that the more pins in a lock, the harder it is to pick. Along with this, the more random the pin-heights, the harder the lock will be to pick. Sound familiar? In web application security we use bit-length (each bit is a technically “layer” of security) and randomness all the time. Consider how we encode passwords to save in a database, the most common hash’s are MD5, and SHA1, which are as a standard are a 128-bit vs. 160-bit encryption (respectively). Quick Tip: Anything encoded for the US Government must be at least as secure as the SHA1 encryption, MD5 is unacceptable. Lets see an example:

Well, indeed MD5 is a shorter encryption, and in turn less secure if we were to try to break it using “brute force”- having server upon server running automated scripts using good ole’ trial and error. Lock pickers use brute force all the time, one method uses these nifty “jiggler keys”:

These keys are made for car door locks. As you can see there is some randomness between each key, and the idea is that when you put that into the door lock, “jiggle and twist”, but the time you give each pattern a couple minutes you find one that works- brute force at it’s finest!

Handcuffs are a well-known lock that display some layers of security. Instead of six or seven pins, handcuffs have one simple lever- yes, society trusts that if you are dumb enough to get arrested, you are not smart enough to bypass a single-lever mechanism. However, consider the more transparent layers of security related to handcuffs:

Be pro-active, strip and clean anything that could damage the application. Give as little information about the way the application is built as possible; hide file extensions and handle all errors. Lastly, watch and react; if you get 100 requests from an IP address in China in 3 minutes, block it. As developers we must try our best to put the attacker at a disadvantage by using layers, remember some of these when building a web application:

Layers, The Future, and You.

We believe one large part in the evolution of web security is summed up in agreat quote from an OWASP Podcast we recently listened to, “If someone was throwing rocks at your house window, you wouldn’t just sit there and be happy your windows are strong, you would call the police or go after the person. We don’t do this in web application security yet.” One idea we are currently piloting at Prime Studios is a “that’s weird” database; we add a simple line to our XSS (Cross Site Scripting) filtering, our CRSF (Cross Site Request Forgery) filters, and authentication systems to monitor for anything that we would say “that’s weird” to. It doesn’t sound like much, but if we see a lot of login failures or broken form tokens over a certain time period, we can take action on a particular user, IP address, User Agent, or a mix of all of them.

Everyone likes elegant solutions, but unfortunately with web application security we can’t just rely on a single [Godly] plugin or framework to handle all our security needs. The first step is knowing what to look for (education), and then you can start building your own methods for a strong security policy throughout your applications (implementation). Hit up the following links for some more great web application security tips:

Improving Web Application Security

OWASP Top Ten for 2010

Web Application Firewalls

XSS, or Cross Site Scripting, is one of the biggest security risks that any web application developer or concerned client should have a good understanding of. XSS makes use of vulnerabilities in a website to inject [malicious] code. Websites are made up of many elements, including things like header information, HTML elements, and sometimes JavaScript elements. JavaScript runs on the browser, and can modify things within a webpage dynamically, and without the user actually knowing. This video explains a vulnerability on a website that includes a search box and a login form in the same view. We show how to use JavaScript to modify a form action, resulting in a complete exploit of a users credentials.

Our privacy policy: With knowledge comes power, use it wisely and in positive ways. For more information about web application security visit OWASP (Open Web Application Security Project).

This is why we call it social engineering, and in the world of application security, the more human manipulation and error there is (or could be), the weaker the entire system. Let’s try breaking into someone’s bank account, both the techy way, then try exploiting the human element.

Techy Way

First, let’s see if the login form properly escapes and validates the inputs, maybe we can do some simple injection. Damn, they know about SQL injection. Next check if there are holes in the system to hijack cookies, or maybe we can brute force the credentials with a dictionary algorithm and a couple servers. Yikes, encrypted cookies, random hash tokens for form validation, and now they are blocking our IP’s because of so many persistent requests. Let’s go for one last thing, let’s put 3-4 thousand characters into a POST or GET request, and see if we can make any exploits from the returned error codes.. Nope, they trim all their inputs to 40 chars before ever processing them. Looks like the script kiddies (bottom of the bin) hackers are stuck.

Human Way

I know a guy down the street who is loaded, his name is John Doolittle. I search for him on Google, find that he is Director of Marketing at www.MarketingFirmABC.com. Then I search the last name in Facebook, and find his wife’s profile, which she publicly posts her email address. I buy the domain www.MarketingFirm-ABC.com, setup a redirect to www.MarketingFirmABC.com, just in case anyone checks. Then I make an email address for myself “john@marketingfirm-abc.com”, including all the headers so the name comes up pretty. You see where this is going.. I email Mrs. Doolittle “Hi Hun, could you resend me our bank acct logins? Must have thrown that sticky note out! -XO”. Give it an hour and unless she is hip to that faulty dash in your email address, you will have bank logins from her, probably with “Sent from my iPhone” at the bottom. You scrap the domain, and access the account from an offshore IP. This is otherwise known as phishing, and while an “old” technique, it still is a common exploit.

Solution = Education

This is kind of scary, but we see that no matter how hard we try to add more layers of security to our application, the weakest link may very well be with the end-user. With this in mind, it’s our responsibility as developers to not only take care of the tech stuff, but to hold the users hand a bit, and unobtrusively educate them about the subtle security risks. Just imagine how many passwords could be retrieved if someone had access to your main email account, or how many they could get by doing some simple “I forgot my password” submissions. Just another day of cautiously embracing the web.

Our privacy policy: With knowledge comes power, use it wisely and in positive ways. For more information about web application security visit OWASP (Open Web Application Security Project).