Archive for April 2014

Can You Tell Me How to get... How to get to to N3rd St?

A few weeks ago the city of Philadelphia passed an awesome resolution to officially rename North 3rd Street, between Market Street and Girard Avenue, to “N3rd Street” (pronounced “nerd”).

When I  read the first article a few weeks ago it took me a minute to remember where I first heard & saw the expression "N3rd St" and then it clicked.  I first encountered "N3rd St" in a tech meetup at N3rd St HQ... DevNuts in Philadelphia over 3 years ago.  The term "N3rd St" was plastered all over the walls at DevNuts.  The team at DevNuts & JarvUs definitely had a hand in renaming N. 3rd St.  They're always on point innovating in the Philadelphia tech community.  They continuously contribute to the community & they really do represent "Change" in Philadelphia from many aspects.  Big ups to "The Mighty" Chris Alfano, his team & others for their efforts in giving us N3rd St.

If you're ever in Philly visiting, you should def visit N3rd St even if it's just to take pic under the sign. Check out the new N3rd St wiki to find out more.

Thanks

-a

Worried About Heartbleed? Then fix your $h!t - Here's How

So it's been kinda fun watching people freak out about the Heartbleed vulnerability this week.  What I don't find so funny & kinda scary is that this vulnerability has been in the wild since December 2011 and people are learning about this over two years later.

In any case my social media feeds are being flooded by people asking how to mitigate this vulnerability.  This post will outline how to patch some of the most popular affected distributions by running commands in Terminals:


Mac OSX: $ brew upgrade openssl


Red Hat: $ sudo yum update openssl

Centos: $ sudo yum update openssl

Fedora: $ sudo yum update openssl

Amazon Linux AMI:  $ sudo yum update openssl


Debian: $ sudo apt-get update && sudo apt-get upgrade

Ubuntu: $ sudo apt-get update && sudo apt-get upgrade

#! Linux: $ sudo apt-get update && sudo apt-get upgrade



So people please patch your servers and take other measures as recommended per your distro's security bulltetins.

Also I wanted to mention that I've been seeing a very scary number of post in my social media feeds from "Cyber/IT Security Professionals" strongly advising people to check their assets for HeartBleed on this site http://filippo.io/Heartbleed/ .  Now I'm not saying the site is designed to be malicious but there is no real way of telling what's going on there.  Now lets pretend the site isn't legit and people start using it to test their assets using this tool.  You've just become a victim of social engineering and voluntarily  added your vulnerable/invulnerable to someones list of websites.  So now a bad actor/third party has your site in list that can be used for future exploitation.

I recommend you patch your assets and take appropriate actions recommended by trusted sources rather than use a third party tool that you know nothing about.  Also TRUST NO ONE on the internet!

Just say'n

Thanks

-a

Ubuntu One RIP - Don't Forget Your Data


I recently received an email from the Ubuntu team stating the Ubuntu One cloud service will
be shutdown effective June 1, 2014.  Ubuntu One was more than a cloud storage provider, it also had a content purchasing aspect to it as well.  For instance you could purchase music then store it in the cloud on Ubuntu One similar to ITunes.

I started using Ubuntu One when it first appeared in Ubuntu 9.10 (released October 2009) as a desktop client.  The service was great it keep my local files in sync & backed up in their cloud server.  The software actually worked and I used that for a few years as my desktop backup strategy.

As far as I know this is the first cloud storage provider to shut its doors and it should get people thinking about the data they hosted on cloud storage providers.  This data is the user's property and is just as important as any of their other assets.  So when hosting your data on cloud storage providers I suggest that users devise a simple strategy on retrieving their property (data) from these cloud provider servers when situations such as Ubuntu One’s shutdown occur.  Get your data back then delete all traces of your data on their service. 

So all you fellow Ubuntu One users retrieve your data from their servers and find a new home for it.  I've been using Dropbox but there are plenty of other providers out there.

The following is an excerpt from the email that I received:
As always, your content belongs to you.  You can simply download your files
onto your PC or an external hard drive.  While the service will stop as of
1 June, you will have an additional two months (until 31 July 2014) to
collect all of your content. After that date, all remaining content will
be deleted.
Thanks

-a

RIP Windows XP... Pour'n One Out for My Dead Homie

As the official Microsoft Windows XP End of Life deadline of April 8, 2014 fast approaches I sit here and reflect on how this Operating System impacted my life & career.   Back in the day there were fewer options regarding Operating Systems than there are today.  When Windows XP launched it was the badass OS that brought the best that Windows NT 4.0 & Windows 98 had to offer in one tight package.  XP really was the first full fledged plug & play OS that actually functioned out of the box on a plethora of platforms & supported a huge number of devices from jump street.

Window XP is over 13 years old & I find it amazing that Microsoft supported it for so long.  I reminisce about my days with the federal government and I remember the huge arguments that I used to have with management & co-workers urging them to stick with XP & not upgrade to that disaster of an OS called Windows Vista.  It wasn’t that I had any special emotional connection to either one of those Operating Systems I just realized that our lives would be easier if we just stuck with XP and waited for Windows 7 to be released.  I’m glad that we waited because I watched other organizations decide to deploy Windows Vista enterprise wide and it was a huge #FAIL.

I’ve built many applications on & for Windows XP and I will admit that the OS wasn’t at all bad.  It really did serve its purpose and it’s long service life speaks volumes.  I mean 13+ years of “support” is unheard of in technology and we’ll probably never see something like that again at least not from Microsoft anyway.

As the deadline approaches I seriously encourage all of you Window XP users to seriously look at Linux.  Any Linux OS will do at this point but if your running Windows XP that prob means your hardware is a bit older and if that is the case #! (Crunch Bang ) Linux is your best option.  Check my previous blog on #! here.  Retire your XP systems and migrate to an open sourced freely distributed operating system.


As for Windows XP,  on April 8, 2014 I'll be pouring a little something out of my forty.

RIP  Windows XP    2001 - 2014
Viva!!!   Linux


-a

Annoying OAuth 2.0 Provider Refresh Policies

Let's face it folks Oauth2 is here & it ain't going anywhere! I've met many hackers that either really like the Oauth2 protocol or really hate it. Few & far between are middle of the road. I am one of those middle of the road ppl. I've been exposed to Oauth since version 1.0 and I've kinda grown up on it in the RESTful API world. It's becoming the most used weapon of choice for cloud based authorization but I would like to see some sort of standardization between the providers in regards to Refresh & Access token policies.

Cloud service companies are widely adopting OAuth 2.0 & it's a great concept that provides a less riskier method for cloud services & app developers to provide a Single Sign-On experience for their users. OAuth enables developers to offer users an easy method to allow “trusted” apps to perform transactions in their cloud based services and applications on their behalf. For example OAuth enables a user to authorize an app like LinkedIn to post a Tweet on the user's Twitter feed on behalf of the user.

Now back to my issues with how providers are implementing OAuth and the annoyances being caused by customized deployments. Most of my annoyances primarily relate to variations between provider refresh & access token policies. The OAuth 2.0 spec is based on refresh & access tokens which are required to perform transactions on a user's behalf. Access tokens are temporary tokens that must be included in all requests & transactions committed against an OAuth provider. Once issued these tokens generally last less than an hour. Once these Access Tokens expire a Refresh Token is required to gain another valid Access Token which will allows continued access until the new Access Token expires & the Refresh Token is used again to retrieve another Access Token and the cycle perpetuates in a loop.

So my primary annoyance relates to the inconsistencies between providers regarding their Refresh Token policies. The Refresh Token policy that is vexing me at the time of this post is related to how some major cloud storage providers administer their OAuth Refresh Tokens. Most OAuth providers issue a Refresh Token that is permanent and won't expire until revoked by the authorizing user. Having this permanent Refresh Token definitely fosters a bit more risk & vulnerability but I'm not convinced there is much more risk compared to the more annoying policies.

I'll describe the annoying Refresh Token policy. In the interest of security some cloud providers have implemented a more locked down policy on their Refresh Token policies and here is the flow. Ready ?:
  • App requests a Refresh & Access Token from provider
  • Provider Responds with a Valid Refresh & Access Token

In this flow, we have our valid Refresh Token but this token is under a more restrictive policy which generates the token as a ONE time use & expires after 60 days. This means when the Access Token expires you have to use this (One time use) Refresh Token to get another Access Token. Now we do get another Refresh Token with our Access Token request but again that is a one time use & 60 day expiry.

You maybe asking, What's the problem? Well this policy presents some unnecessary issues for developers that have to build against this policy. This particular policy doesn't provide the developer a friendly method in providing a seamless SSO user experience within their apps. In most scenarios, developers will have to persist Refresh Tokens (hopefully encrypted) in their apps data store. With a permanent/long life Refresh Token developers can easily implement a seamless SSO in their apps and don't have to struggle with figuring out a whole strategy on tracking the life of Refresh Tokens. I feel this restrictive policy is futile and doesn't add any value or real security. It just feels as an illusion so that companies can sell as security proposition or differentiator.

In conclusion I'm all about security but I'm also down with being sensible when designing & implementing security policies. If you produce tools & services for developers you really need to seriously weigh & balance the very thin lines between security & overall usability. At the end of the day the reality is that we can hack solutions for these types of constraints but why do companies feel the need to complicate things for the very community they're trying to capture & maintain?

So if you're a cloud service provider using OAuth please use sensible Refresh Token policies. It really does make huge difference in a developers life :-)

Thx

-a

#! Linux


I'm a huge open source & Linux guy from way back and I'm always using/testing different distros. There are so many Linux distros available and new versions crop up everyday but I've been using a gem for over a year now called #! (CrunchBang) and it is just great!!!



#! is a Debian GNU/Linux based distribution offering a great blend of speed, style and substance. Using the nimble Openbox window manager, it is highly customizable and provides a modern, full-featured GNU/Linux system without sacrificing performance. Put simply; CrunchBang could be thought of as a layer built on top of Debian, specifically to provide a great Openbox experience.



I noticed #! on distrowatch.com a few years ago but didn't give it a try until 12 months ago. I was drawn to it because like most people in the tech industry, I have some older functioning laptops & desktops that are serviceable and need a performant modern OS.  Over time the major operating systems such as Windows & OSX become bogged down and performance tanks.  Occasionally I've  become somewhat attached to particular machines such as the netbook I'm using to write this blog because it's a very small & light device I use for travel.  What ever the reasons we may have for using older devices there should always be available OS options for community users.



#! has brought life back to my beloved netbook. In the past, I've installed many “light” weight versions of Fedora & Ubuntu but they were all still too bloated & slow.  Finally I decided to try #! and eureka I struck gold!!!  #! is great because it offers an upto date Debian platform that is very performant on older hardware.

Below are some of my opinions on #! :



Positives

  • easy to install
  • offers a snappy OS revival to older laptops & computers
  • uses the Debian apt-get package system
  • provides easy to use package install scripts to install the latest browsers, storage providers & other cloudy software
  • well maintained
  • has a great user community & knowledge base



Cons

  • OpenBox can have a bit of a learning curve for non-linux users
  • video card driver support limited for some of the older nvidia cards
  • wouldn't use this distro as production servers

I have installed #! on most of my favorite older machines and I'm very satisfied with the overall experience & performance.  So download the a #! install package, format a 2GB USB drive & install #! today.  I'll post random tips as encounter helpful information to share so keep an eye on this blog for things to come. 

Share some your favorite aspects of #!



-a

BBQ Hack - A Hacker's Rib Recipe

Last Sunday I got the urge to bust out the old smoker grill & roast some
Mesquite Smoked Baby Back Ribs. I've been into BBQ & grilling for over 20+ years so I consider myself very knowledgeable in this regard. I discuss BBQ with various types of people, from BBQ n00bs to professional pit masters & I'm always amused at the level of paranoia & secrecy around individual BBQ recipes. These people are insanely sensitive regarding these recipes.

I guess I like my BBQ recipes like I like my tech... Open! I'm not one of those
recipe hoarders. When people ask me for my recipes I gladly give them up. I think it's a great thing to mentor & share recipes because it causes innovation & creativity. In this post I'm giving up my recent rib recipe & I'm sure you'll be surprised how great it tastes & how easy it is to execute.

Hardware:
1 x Outdoor Charcoal Smoking Grill ( Gas & Electric are fine but I prefer coal & this recipe is for coal)
1 x Bag of “Hardwood Coal”
1 x Bag of Smoking Wood (Mesquite, Hickory)
1 x Coal Starter Not Required
1 x Electric Coal starter Not Required

Ingredients:
1-2 x Full Rack of Baby Back Ribs
1 x Baby Ray's BBQ Sauce

Prep the Ribs
  • Pull the silver off theback of the ribs
  • Evenly sprinkle a light layer of the Montreal Steak Seasoning on both sides of the ribs (Don't over season)
  • Let the ribs marinate in the refrigerator for 2-6 hours if possible.

Grill/Smoker Prep
  • Pull the ribs out of the fridge & let them come up to room temperature
  • Stick the Electric Starter in the Coal starter
  • Fill the Coal starter with the Hardwood Coal keeping the Electric Starter in the center.
  • Plugin the Electric Starter and let it heat the Coals fro 10-15 minutes (Note: I suggest you visually monitor this process for safety)
  • Carefully Remove the Electric starter after 10-15mins
  • Let the coals burn for 5-10 minutes more
  • Carefully place the hot coals in the Smoker's designated coal receptacle
  • Let the grill come to temp for 5 minutes
  • Place a handful of Hardwood Mesquite chunks on the hot coals
  • Finally place the ribs on the grill and close or cover the smoker

The Cook
  • Never Ever uncover or open the smoker's lid/door (it lets the heat out)
  • Make sure that there is continuous smoke being generated while smoking - don't use too much wood 
  • Check smoke every 45 minutes and add a chunk or two if needed
  • Cook for about 6 hours
  • If ribs are still under cooked you can finish them on a very low temp gas grill using indirect heat on 225-300 for 45-60 mins
  • 30 mins before you remove the ribs slather Sweet Baby Ray's BBQ sauce on the top and let caramelize (Optional)

Post Cook
  • Let the ribs set for 10mins
  • Slather more Sweet Baby Ray's if you like (Optional)

Conclusion
So I know that you're probably surprised that I only used the Montreal Steak Seasoning as a sole rub ingredient but I've actually tried many rub recipes that require anywhere from 10 to 25 ingredients & this single seasoning is the best I've had on my ribs.  I've actually had taste tests with friends where I prepared ribs with a robust rub & my Montreal Steak Seasoning rub and Montreal Seasoning won every time.

This recipe is great for BBQ n00bs and will definitely get you some BBQ street cred.  Use & share this recipe with fellow hackers and reach out to me if you need advice.

Hack Idea – WiFi Thermometer
I'm working on building a WiFi Thermometer hack so that I can write and app that will enable me to monitor the temps of my cook from a mobile app. Luckily someone already has a hardware hack completed that I can use to easily build my own WiFi thermometer and maybe improve on this hack.

This will be my next project at the next Hackathon I participate in so don't steal my idea ;-)...  jk

Check out the project here:

Thanks

-a

yep don't use it unless you ask ;-). Powered by Blogger.