The post ABB – Always Be Backing-Up appeared first on Big Trapeze.

1. Go to your project’s directory and “git init” to init a new repo.
2. Add any untracked files with “git add .”
3. Commit those files with a message using “git commit -m ‘Your commit message’”

We’re now going to use our Google Drive and create a blank repo. First, make sure Google Drive is running. Then, open Terminal, and

1. Create a new, blank project with

   git init –-bare ~/Google\ Drive/git/myproject.git

   . Be sure to change myproject to whatever your git repo’s name will be.

2. Add the origin to your project with

   git remote add origin ~/Google\ Drive/git/myproject.git

3. Your origin is now set, meaning you can now push with

   git push -u origin master

   (on future pushes, you can just “git push” without the “-u origin master”)

That’s it–you can verify it worked by going to a new directory and trying to clone your project

1. cd /tmp
2. git clone ~/Google\ Drive/git/myproject.git

and you’ll see it clone your repo into a new folder.

The post Using Google Drive as Your Personal Git Repository appeared first on Big Trapeze.

I started a web app in 2005, Giveo, which allowed people to raise money and awareness for causes that were important to them. I wanted to give people the ability to  connect with their friends and families to receive micro-donations–and Giveo was the first online social philanthropy site, beating superstars like Kickstarter and Facebook Causes to the punch. Giveo’s original tagline was “Giveo: Grassroots Philanthropy” — and it was a message that defined the soul of what I was trying to do. There were (and still are) a lot of  sleepless nights, or days with my head crammed into a book on “how-to” do programming, engineering, and designs, but after almost 2-years of iterations, headaches, and changes–it finally got some traction.

What started as a side project grew into a full time web startup in 2009. I met a couple of great guys who purchased Giveo from me, then in turn offered me a job to keep building it up. Over the course of those years, we found a few partners and investors, and an amazing team was assembled. We teamed up with large non-profits to help them with fundraising campaigns, cause marketing, and customer insights.

We raised money for amazing causes like the disaster in Haiti, school lunch programs for underprivileged children, and ASPCA pet rescue. And then late 2011, Giveo changed focus a bit–and changed names. We became SpotRight–a company built to spot trends and make sense of billions of datapoints, by analyzation of unending streams of data now proliferating across the globe. We use that information to better serve our clients, so that by helping them understand their customers with clarity and depth–they are able to raise more money, more awareness, or be more successful in their campaigns.

Today, I’m happy to say we’ve raised another $1M and acquired a fantastic company called SpotInfluence–a brilliant collection of beautiful minds that will bolster our offerings and put us at the forefront of both #bigdata analysis and social analytics. So, althoughGiveo is now SpotRight, it’s still got the DNA of the little company that could, and is now the bigger company that will. Thank you for your continued support–I can’t wait to see what the future holds.

Jeff

The post Giveo Levels Up appeared first on Big Trapeze.

1. Purchase a wildcard SSL certificate. I used RapidSSL, and while any will work, Comodo seems to be the one currently recommended by DNSimple, which we’ll use later in these instructions.
2. Next, add the SSL Endpoint add-on to your app via Heroku. It’s an additional $20 a month to enable this service, that’s just the cost-of-doin-bidness with Heroku.
3. So, at this point, you have your wildcard SSL installed with Heroku. You can tell if you installed it correctly by dropping into the Heroku CLI (which you can install via the Heroku Toolbelt) and issuing a “heroku certs”.  This should give you an endpoint, which looks something like: waterfall-9359.herokussl.com. You’ll need your specific endpoint for our next step, so copy it and keep it ready.
4. Finally, create an account with someone like DNSimple. Without an ALIAS service like this, you won’t be able to enable SSL on your root domain (like myapp.com or www.myapp.com). If you used DNSimple, go to the Advanced Editor for your domain. You’ll want to add the following:
   - an ALIAS record for your root url, myapp.com, which points to your Heroku-issued endpoint, like: waterfall-9359.herokussl.com
   - a CNAME record for your www-based url, www.myapp.com, which points to the same endpoint above, like waterfall-9359.herokussl.com
   - CNAME records for each subdoman you wish to enable SSL on, like blog.myapp.com or account.myapp.com, each pointing to our Heroku endpoint
5.  That should do it! The next step would be enabling SSL in your app, which is a straightforward process achieved by adding config.force_ssl = true to your application.rb file. (For more details on how to enable it in production only, read this excellent blog post from Simone Carletti.)

The post Enable Wildcard SSL on a Heroku Rails App appeared first on Big Trapeze.

I’ve seen the list, in an attempt to see if my own information was compromised. It was not (at least here, but was recently in the Zappos breach), but I can’t say the same for almost a million other people. The list contains mostly inconsequential information–but it does have an encrypted password (along with the email address and username) for each person. After a cursory run through of several thousand random encrypted passwords, I was not able to crack any using the method I published a few years back.

Salting

These passwords are at least salted–salting is the process of taking a password and adding extra characters to it to make it more difficult to crack. If your password was “submarine” using MD5 encryption (which is what the majority of websites use to encrypt stored data) it would be encrypted as “a9bdfa76aa6d76f7bde66e470cf98553.” In an effort to make your data more secure, a programmer might salt your data with another word, like  ”kangaroo,” by adding it to your password before storing it. So, instead of storing the MD5 hash of “submarine,” which might be easy for a hacker to guess if they accessed the user database, the password is stored as a hash of “submarinekangaroo,” which would be much harder for someone to guess. A smarter salt would be something random, like “tH7rWslwj6″, so that brute-force attacks on passwords with a word-list for salts would be rendered mostly useless. Try it yourself if you want: If you’re on a Mac, go into Terminal and type

md5 -s 'whatever-you-want'

then hit Enter. What you’ll see is the hashed value of your string of text. Now try to add some characters to it–your own salt–and see how the results change. It’s important to realize that there’s no “unhash” method, per-se. There’s no such thing as

unmd5 -s 'a9bdfa76aa6d76f7bde66e470cf98553'

and get “submarine” in response. But–if you go to Google and search for “a9bdfa76aa6d76f7bde66e470cf98553″, you’ll find plenty of posts telling you the answer is “submarine.” Salt submarine with your own new word (md5 -s ‘submarineastroturf’), then search for that–chances are, your search will come up empty. That’s the importance of a salt.

How does my website know my password then?

In most cases, they don’t. They keep the hashed version of your password, but they have no way of knowing what it actually is in “plain-text.” To see if the password you enter when you login  matches what they’ve stored in their database, they have to hash it, and compare it to what’s on file. So if your hashed password was stored as

8833f74b9da9cf81d33f6c6a79ac9985

and you entered “telescope” as your password, a program quickly converts your plain-text password to

8833f74b9da9cf81d33f6c6a79ac9985

and compares it to what’s stored. In this case, there’s a match–and you’re granted access to your account. If they happened to salt your password before storing it by adding the word “pineapple” to the beginning, then your stored password would be:

0cf7664d30e8a72b6b423148578ddfba

(again, you can confirm by typing md5 -s ‘pineappletelescope’ in your terminal). So, when you enter “telescope” into your website’s login box, before it’s hashed, the website will add “pineapple” to your password, then hash it to compare with what’s stored in the database. You can see not only the importance of salting, but also knowing exactly what the salt is. Without it (without knowing pineapple, in this example), it would impossible to match the password you entered with what was stored.

Looking for patterns

So, we can assume that Stratfor is at least smart enough to salt their passwords–the question is, can we take 800+K hashed salted-passwords, and find any patterns or similarities in them? From that, could we build a frequency of the most common hashed passwords, then assume that those passwords are the same–and try to derive an algorithm that produces a salt? Can we get lucky and hope that Stratfor salted their passwords with either the username or email address of each user? Or did they use the same salt for every user? I would assume they wouldn’t use an email address–especially since a user can change their email address–so we’ll take that one out of the mix. I will, however, try the username as a salt–as that is typically something a user isn’t allowed to change.

The First Clue–No Duplicate Hashes

To begin, I sorted the 860,160 hashed-passwords alphabetically, and interestingly (at least in the few thousand I quickly scanned), there were no matches.

What does this mean?
It means that a different salt is being used for each person.

Why?
Because in a list of 860,160 passwords, the chances of none being the same are infinitesimally small. Let’s say two people used the phrase “opensesame” as their password. The hash of this is:

e6078b9b1aac915d11b9fd59791030bf

Let’s now say that Stratfor salted all passwords when they stored them, and salted them with the phrase “fishbowl123″ by appending it to the end of a user’s password. So, opensesame becomes opensesamefishbowl123, which is hashed as

8feb9db2775f81e3b152803bb9704fad

So, theoretically, if only 2 out of 860,160 people had the password of “opensesame”, we should see the hash 8feb9db2775f81e3b152803bb9704fad show up at least twice. But there are no duplicates–and that indicates that the same salt isn’t being used for each person. This is too large a sample size to not have at least 2 people with the same password–any password. Since we learned above that the salt must be known in order for a website to check your password, we’ll assume that Stratfor made their salt based on something unique to the user.

The User Record

The user records for the Stratfor file include information like name, stratfor ID, user ID, user email address, timezone, picture, signature, theme, last login date, account creation date, and a few trivial ones. We know that the salt most likely comes from one of these fields of information, and we know the salt needs to be unique to each user, so we can start eliminating some of these. The dates are interesting, but there is a good possibility that there are plenty of users with the same login date, or account creation date, even down to the hour or minute–so we can’t assume that is unique. We also know that there will be plenty of duplications of the timezone, so that one could be eliminated as well. The theme (which I assume was some sort of color theme or account theme for each user) can also fall under the “duplicate” category, but it falls under another greater category–which is that of a field where the value could change. For the salted password to work–the salt must always stay the same. We can also consider user email address as something changeable, as well as the user’s name–so we’ll eliminate those from our list of possible salt options.

That leaves us with 2 good options:

• user id
• Stratfor id

Because we know that the salt is unique to a user, we have a good starting point for our attack, using the two options above as our primary salt tests. We know that Stratfor isn’t using a random string for a salt–something that they’ve locked away in some file–because even if they did, there’s a great possibility we would have duplicate hashes–and we have none.

We have candidates for our salt, now what?

To do all the password crunching and text analysis, I’ll be using my new friend, Ruby on Rails. Rails makes it really easy to spin up a quick database and start throwing data in it and doing text manipulation. The first step is to clean up the list and throw it into a database table. I took the huge Stratfor file, removed the extraneous columns and imported the user records into a database.

Next I created a model for attempts. The attempts are based on the premise that at least one user out of the 860K will have one of the “10 most common passwords” (which, incidentally, were taken from the leak of 32 MILLION passwords from RockYou.com’s compromised systems.)

The 10 passwords we’ll start with are:

• 123456
• 12345
• 123456789
• password
• iloveyou
• princess
• 1234567
• 12345678
• abc123
• monkey

What we’ll do is take each of the 10 passwords, and add the user id to the beginning, test it, then add the user id to the end, and test it. For example, lets say the user’s password hash is “3d50169ccfe06ecf1bdf4c63fb199bd9″, their user id is “20,” and their Stratfor ID is “23087.”

I’ll take our first password, “123456,” prepend “20″ to it, to get “20123456,” then get the hash (md5 -s ’20123456′):

11720f3fa65c0fe57212ba6f12af1af1

No match. So now I’ll try “123456″ and append “20″ to it, to get “12345620,” then get the hash (md5 -s ’12345620′):

594111f029cbea462f70398257ac0e7f

No match. Now I’ll try it with their Stratfor ID. No match? Now I’ll move to the next of our Top 10 passwords, “12345,” and continue the test. For each password in our list, we have to try 4 different combinations. That’s 40 combinations for our 10 passwords, tried across 860,160 rows, which means over 36 million tries.

If none of these works, the odds of the salt being based off one of our test columns seems slim, at which point we might consider that the hash is built off of more than one column (for example, prepending the strafor id to the password and appending the user id to the end). If that’s the case, our number of brute-force attempts increases exponentially–and that’s bad news for this exercise, but better news for those whose data is at risk.

The Results

Armed with my list of 10 common passwords and the Stratfor hash, I put Ruby to the test. Less than 20 minutes later (even running on an underpowered MacBook Air), the experiment was a success, and the results are stunning:

Of the 860,160 user accounts from the Stratfor file, 986 of the users had one of the ten common passwords. The salt, as it turns out, is the Stratfor ID, prepended to a user’s password. So, if your password happend to be “monkey,” and your Stratfor ID was “187519,” your password is based off the MD5 hash of “187519monkey.” (Incidentally, 14 people of 860,160 had the password monkey. The most common, sadly, were 123456 (483 occurrences), and password (285 occurrences).

What Does This Mean?

It means someone nefarious, knowing the salt column, could take it and run each of the users’ passwords against a brute-force dictionary–and there is no doubt that the 986 number would greatly increase, giving the hacker access to thousands of accounts.

It also means that it only takes two people to have a bad password to crack a salt. If no-one in the 800K test had used one of those top 10 passwords, there’s a good chance I would’ve gone on to another method, having found no matches.

What does it mean to Stratfor, and companies like them? You have to do a better job of protecting our data. Salting is a good step towards protecting data, but if you don’t use it right, it’s only a minor stumbling block to someone with relatively little skill. Perhaps salting with data from multiple columns, or column data in reverse (maybe the username backwards), or a column on each end of the password (maybe a username and the account-created date), like “usernamemonkey01-25-2012″ would be better. The insecurity of our personal data is troublesome, and breaches happen almost every day. I can only hope this will help those who keep our data become more responsible in their protection of it.

The post Extracting a Salt from an MD5 Hash appeared first on Big Trapeze.

In this example I have a model, @tweets, filled with scraped tweets from Twitter. I have a hash, stats, filled with stats about those tweets–like the total number, the number of tweeters, the number of re-tweets, etc. Ideally, I’d like my JSON response to look something like:

{"stats":{"total":1024,"users":128,"retweets":"32"},"tweets":[{"tweet":"Petrol heads! Tune in to @DiscoveryUK at 9PM for the premiere of brand new #WheelerDealers the series kicks off with a rather nice Fiat Dino"},{"tweet":"2nd last nite in bahamas!  Dinner alone. shark diving done and my camera gear just arrived!!  Thanks a lot Air Canada. Exmas tmrw.  L"}...]}

First, in your controller, convert this hash to an OpenStruct format, which uses a RABL-friendly dot notation, like

your_controller.rb

require 'ostruct'
@stats = OpenStruct.new
@stats.total = @tweets.count
@stats.users = '128'  # Keep adding stats if you'd like
@stats.retweets = '32' # .. more stats

Then, in your view file

your_view_file.rabl

object false

child @stats => :stats do
  attribute :total, :users, :reteweets
end

child @tweets => :tweets do
  attributes :tweet
end

Your result should look like the example output above. Two things to note: 1) I was able to get this to work without explicitly requiring ostruct in my controller. 2) It also works without explicitly specifying “object false” in your .rabl file.

The post Using RABL to Display Multiple Models appeared first on Big Trapeze.

Backup your id_rsa file! Then,

openssl rsa -in ~/.ssh/id_rsa -out ~/.ssh/id_rsa_new
cp ~/.ssh/id_rsa ~/.ssh/id_rsa.backup
rm ~/.ssh/id_rsa
cp ~/.ssh/id_rsa_new ~/.ssh/id_rsa
chmod 400 ~/.ssh/id_rsa

Removing a passphrase from an SSL server key

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr


Remove passphrase from key:

cp server.key server.key.org
openssl rsa -in server.key.org -out server.key

For more details:

http://www.akadia.com/services/ssh_test_certificate.html
http://www.thinkplexx.com/learn/howto/security/ssl/remove-passphrase-password-from-private-rsa-key

The post Removing the Passphrase from SSH Keys appeared first on Big Trapeze.

• Download and install ffmpeg2theora from http://v2v.cc/~j/ffmpeg2theora/
• Go into terminal, navigate to the directory where your M4V video is stored, and type ffmpeg2theora name-of-movie.m4v

That’s it. Depending on the length of your movie, a few minutes later you’ll have a nice OGV file to go with your M4V.

The post Create an OGV file from M4V appeared first on Big Trapeze.

This took a while to figure out, but it’ll be easy for you if you follow the steps below:

1. Install the EC2 API Tools (setup instructions for Mac OS X)

2. SSH into the instance in which you wish to allow remote MySQL connections, and edit the my.cnf file. In Ubuntu, you can find this at

/etc/mysql/my.cnf

Look for the line that starts with bind-address, and comment it out. If enabled, this line tells the MySQL server to only allow connections from the localhost.

3. Login to your EC2 instance at Amazon AWS. Make a note of the security group that your instance belongs to. In my case, it was “default.”

4. Back on your machine where you installed the EC2 API Tools, run the following command:

ec2-authorize default -p 3306

* Note if your MySQL port is something other than 3306, change the above command to the appropriate number.

That’s it! You should be connecting now with no problems.

The post Allow Remote MySQL Connections to an AWS Instance appeared first on Big Trapeze.

1. Check your current MAC address from Terminal:

ifconfig en1 | grep ether

2. Keep Airport turned on, but log out of all networks (click the Airport icon, “Join Other Network,” enter a bogus one, and hit cancel as it searches).

4. From terminal again, type:

sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -z

5. Still in terminal, change your MAC address with a command like:

sudo ifconfig en1 ether 00:e2:e3:e4:e5:e6

6. Check your new MAC address to make sure it saved:

ifconfig en1 | grep ether

Done…

The post Changing Your MacBook Pro Airport MAC Address in Snow Leopard appeared first on Big Trapeze.