Password Retrieval

I love tasty sandwiches, but I absolutely hate poor password management. 

Which brings me to Jimmy John's website.

Do NOT store your credit card information on this website, and usually not on any website to be sure.

So what exactly has gotten me riled up?  Password resetting.  It's a direct tell of how a website stores your information.  I had previously ordered a tasty sandwich online, but forgot my password.  So I clicked the forgotten password button and my email dinged.  Now comes the best part, the password was in plain text - it was readable just as if I had typed it into an office document.  Good security management is when a company sends you an email with a link to reset your password.  You can get even better with security questions, but we're just ordering a sandwich here!

This tells me that they are not using hashed passwords.  Anyone who stores passwords in the clear like this, should be kicked back to web development 101.

What is a hash?  Simply put, think of it as a math equation where you input some text or data, in this case a password, and then out comes a fixed length mix mash of alphanumeric characters.  Theoritically, the hash itself should not be able to take you back to the original password; more on that a little later. 

Amateur level
User enters a password onto a website -> Database on website stores password in plain text

At the amateur level, if anyone compromises the database, they have it all.  Also, the website developers and pretty much everyone at the company, can easily read your password.  Pathetic job at security here.

Intermediate Level
User enters a password onto a website -> Database on website stores password as a hash

Works well at this level, but a lot of improvement is needed.  If this equation is done right, even if someone steals the hashed passwords, they still wouldn't know what your password is.

There's something very wrong with this level though.  If someone is trying to discover your password to gain access, they will use a rainbow table.  Think of this as a massive spreadsheet with every popular password and common combination of words and phrases.  In the first column is the plain text, and in the next column is the hashed value using the most common hashing algorithms.  Now if they find your password hash in the second column, they can simply match it up to your original password.  You would be surprised how easily this will crack popular passwords even though it takes a lot of computer horse power to initially run and the hash hasn't been technically compromised.

Advanced Level
User enters a password onto a website -> Database on website adds random data to password and then stores it as a hash

All we need is a little bit salt.  This isn't a tasty seasoning, it's a bit of subterfuge.  You hash the password just like the intermediate level, but you don't just use the plain text a user enters into the website.  You mix it with something unique, or a salt.  One simple example is to prefix some random text to the password. 

Now if someone tries to make a rainbow table to search for your password's hash, as long as the salt is secure, it's not going to happen.  This of course isn't the only "salt" you can use, but it provides a good beginning example. 

For instance if I compute the MD5 hash onto the text string "password", I get "5f4dcc3b5aa765d61d8327deb882cf99" (minus the quotes).  Try doing a Google search with that hash.  The "password" phrase comes right up.  This being such a common password phrase and with no salt, all it takes is a simple search to discover the original password.
Dash on a little salt, let's say "5^Lt" so we now have, "5^Ltpassword" and we get,
"faf50047e2d20a2afd699cdeed7cacdd".  Do a search for that and you get ... nothing!

To be truly effective, the salt should be a secret that only very few people know.  Whenever someone wants to log in to a website, they type in a password phrase and then only the computer secretly applies the salt and verifies if it's correct. 

So if someone is storing your password, the only piece of information that verifies your identity, as
"password" 
 compared to
"faf50047e2d20a2afd699cdeed7cacdd"
who are you going to trust with your credit card and personal information?

Jimmy John's can make a tasty lunch, but they get no confidence from me when dealing with personal information.  From now on, I'll pay at the counter.

---

Some references,
Ruby Digest Standard Library
http://www.ruby-doc.org/stdlib-1.9.3/libdoc/digest/rdoc/Digest.html

Hash Functions in more depth
http://en.wikipedia.org/wiki/Cryptographic_hash_function


For the curious I'm using Ruby to compute md5 hashes.
require 'digest'
Digest::MD5.hexdigest("password")
=> "5f4dcc3b5aa765d61d8327deb882cf99"
Also of note, MD5 isn't the ideal hash function.  It is possible to break with brute force and for added security, and complexity, most commercial websites are going to use the SHA-2 hash.

Search and Ship with Google

The Wall Street Journal recently ran a story about Google looking to compete with Amazon on quick shipping services.  As a fan of Google's search algorithms and an Amazon prime customer, this is extremely interesting to me.

The first question I have is, who pays for shipping?  With Amazon Prime, they get my $79 every year and on average it works out to be profitable up to around 16 items shipped.  I average the cost about $5 per shipped item, less for blu-rays or more for bulky items, this comes to $80/5 or around 16 items.  If you buy less than this within a year with Prime, Amazon thanks you for your continued donations for their services.

I doubt Google is going to move away from their ad supported model of revenue and their partners are not going to want to step up and eat the costs for a customer who is not yearly invested, like Amazon Prime, or even guaranteed to come back and purchase another item ever again.  (This is similar to the current online coupon setup.)  This makes it clear that Google will have to subsidize some of these shipping costs to get companies on board.

That's where this gets a little complicated.  Let's say it's $1 for two day delivery of my new Gap sweater.  Somehow this is missed and on the third day I get annoyed, but at who?  If I contact Google, their going to point me at the Gap, and the Gap will either apologize and offer a credit, or blame some timing issue through Google.  In other words, there's no single point of contact for the customer to focus on. 

This is similar to my relationship with Android.  I think it's a fantastic operating system and deserves heaps of praise.  That is, when it comes directly from Google.  As soon as you get some dubious distributors of Android who like to pack their phones with vulnerabilities and bloat ware, it takes a nose dive off the cliffs of quality.  When Google works with other companies for fast shipping deals, it's once again entering into a pact that it doesn't have complete control over.    

I think the Google quick ship can work, but it will not be close to the Amazon Prime level of integration and ease of use.  Have you tried searching for a product through Google lately?  For popular items like  Black & Decker juicer or Uncharted 3, Amazon is always in one of those coveted top spots.  Just getting past that for a new shipping service is going to be one heck of a battle.

Quick notes:
I don't have anything against the Gap.  I own cloths from there and have usually been happy with my purchases.  Also, as stated I am an Amazon Prime member and do a vast amount of my shopping through Amazon.com.

When Apps Go Wrong

I love how good onions bring me to tears.  Sadly, there are bland onions as well and The Onion's iPhone mobile app falls into that category.  You can get your daily laugh riot on an iPhone with their superb writing from the main website, the mobile website, using Apple's Reader, or through their personal mobile app.

Loading up the app, I get a 1990's style animated gif ad on the bottom of the screen which does a great job of grabbing my attention and pissing me off with a quasi real message.

Hey I have a new message!  Wait a min ...

This is not how I want to read their stories so I thought I would try other ways of accessing their content.  Let's hit up the website, which automatically forwards me to their mobile version.

Much better!  Got rid of that horrible ad on the bottom.  In fact, there are only two ads on the page, one above the main image and another at the very bottom.  It's a clean layout with a good choice of fonts, thumbs up.

I clicked on Apple's Reader tab, and the main article's image is removed, but the other image inside the article is still present.  Not perfect but the font is even better for reading and the story in my opinion becomes easier and quicker to access.

In terms of readability, this is the best.

Lastly, I opened the main site to see how that was handled on my smaller screen.

Damn good? Do they sell just ok gifts to?

Ads, ads everywhere.  This is how The Onion makes its money so I'm not going to cry a river.  On the plus side, with the ads formatted outside the main body of text, it becomes an easy double tap on the screen to get this,

The font is a little smaller, but it comes close to the mobile app in terms of usability.

The question I asked myself here is, "When do you really need a mobile app?"  In this case if you're only reading through articles on The Onion's website, it's just a waste.  I could read, scroll, and share just as easily, if not better at times, with the online mobile website compared to the app.

If I was going to do an app for The Onion, I think we can go a much better route.  Like Al-Jazeera's iPad app, open up to a video to get the user's attention.  There could be a pile of fun just waiting to happen with some simple ad-lib programing for their stories or even incorporate fake places on a map overview.  Something, anything, is better than reserving your main website's stories again with poor real estate and bad ads.

Virus Ridden Smart Phones Are Not the Problem: You are

How viruses used to work, 
Trick the user into running a piece of code

This could be a floppy disk (remember those?), an internet download or any way of communicating program code into a foreign host.  One of the most classic ideas was emailing mass amounts of people with a conspicuous excel document that ran code in Microsoft Excel when opened.  This would do anything from setting up your PC to remotely run commands or just maliciously create havoc.

Why did this work so well?  Windows was notorious for virus problems because of relaxed permissions and a vast install base.  Unix/Linux is less susceptible with strict file and directory permissions; which Microsoft began to emulate with implementations like the horrible UAC system.


Now security companies are jumping up and down about virus infections in smart phones and how you need their protection or the world will end.  99% of this is baloney.  Your phone does not get infected with viruses.  Today, you knowingly give access to your phone.

How "viruses" are working today,
Trick the user to blatantly accept an action that collects personal information

Permissions have gotten good enough that just downloading a piece of code and compromising your smart phone is not very likely.  (All bets are off if you're rooting or jail braking your device and using unverified kernels!)  What's changed is that applications are now sectioned off in their own little sandbox and do not have unrestricted access into the main system; unless you give them that permission.

What does this mean exactly?  It means if an evil application wants to read your SMS messages, or take note of all your keyboard inputs - you are going to let it.  If you're installing custom keyboards in Android, you're going to get a notice asking you if you really want to allow this application access into your phone.  You better be damn sure that new keyboard isn't a piece of evil code because you just gave this app and whoever created it, direct access into all of your phone's information.

iOS is an even harder wall to knock down.  It's sectioned off like the Great Wall of China around Apple's house.  With a moat and a dragon ready to take you out if you get too close.  No one gets in, no one takes a look around, period.  There has been a crafty exception where a security researcher was able to get outside code to run from an app and he was kicked out of Apple's developer program for a year.  They're a little touchy on this subject.  This is one of the very few occurrences of this type of execution though.  With Apple's review process and sectioned off OS, almost no threats are going to come from the outside.


It's the same thing with some lame Facebook applications.  For example, there are some apps that claim to show you the frequency of visitors to your profile page, and yeah, total BS.  When you install this type of application, you give it permission to read through all of your posts and friends - so it does just that.  Taking some bogus average of number of posts from friends and direct messages to show you the number of times your profile has been viewed by a particular person.  What really just happened there was you gave this application, and whoever wrote it, full access into all of your Facebook posts and friend connections. 

This next era in computer security has reached a much more social aspect.  Viruses are no longer the main threat, it's the user who allows programs into their lives that is.  The worst part of this?  Agreement Fatigue.  Users are seeing these messages asking for access so often, no one pays attention to them anymore.  When was the last time you read, or even skimmed, an EULA agreement?  When was the last time you paid special attention to what access you were allowing outside apps?  Just like that, users are the weakest line of defense and no security company can sell you a product to improve that.