Intro to Swift

Intro to the Swift Programming Language

Apple's Swift LanguageThe biggest story out of the 2014 WWDC Keynote was easily the introduction of the new Swift Programming Language. Not to be confused with another language called Swift, a completely unrelated language used for parallel scripting, Swift is a fast and modern language that designed for safety.

When I say that it is fast, what does that mean? During the keynote, they gave a benchmark sorting a list of objects. They declared Python to be a baseline and claimed that Objective-C was 2.8 times faster than Python. That makes sense because Python is typically interpreted (as it most likely was for this benchmark) and Objective-C is compiled. So, what about Swift? Swift was 3.9 times faster than Python, an impressive improvement over Objective-C.

What about something a little more computationally difficult? With Python again as a baseline, RC4 encryption is 127 times faster in Objective-C. However, Swift is actually 220 times faster than Python, which is an even larger gap than the more simple object sort benchmark. I think we might be beginning to see where the language’s name came from.

What about the “designed for safety” part? What does that even mean? What that means is that you literally cannot shoot yourself in the foot with many common errors because they are just not possible in the Swift language. You cannot cause buffer overflows, operate on uninitialized variables, use Gotos, perform unsafe string formatting, etc. The language is set up in a way to allow you to “fall into the pit of success” with regards to many language errors that leave security holes.

What about modern? One thing is that Swift has modern features like closures, generics, namespaces, type inference, and multiple return types. The other thing is that the language syntax feels very modern. It feels a lot like Ruby and JavaScript and it ditches a lot of the “ceremony” that you had to adhere to when writing Objective-C. I’ll admit that I hated Objective-C, but Stockholm Syndrome has set in and I have actually enjoyed using it of late. I’ll be interested to see if the Ease of Use™ of Swift will make my Stockholm Syndrome fade away and make me see what I’ve been missing.

The other really neat thing about Swift is its REPL, which is implemented in Xcode Playgrounds. A playground looks like this:

Swift Playground

This playground example also demonstrated some of the syntax. Like Javascript and C#, you can just declare the variable with the var keyword and its type will be inferred. The let keyword creates a constant. If we need to help Swift infer a type, we can use the :Type syntax. We can see examples of all three of these below:

var str = "Hello, playground" // inferred as a string
var age = 7 // inferred as an int
let planetName = "Earth" // a constant string

var salary = 4000 // inferred as an int, but that's wrong
var salaryCorrect :Double = 4000 // now given the hint to be a Double instead

Types are still very important to Swift, though. For instance, if I try to execute this code:

let greeting = "Hi, I was born in "
let year = 1977
let completeGreeting = greeting + year

If I do that, I get the error “‘String’ is not convertible to ‘UInt8′”.
Update 7/16/2014 – As of Xcode 6 Beta 3, this error changed to this from the previous error of “Could not find an overload for ‘+’ that accepts the supplied arguments”

Instead, I have to explicitly cast the int to a string like this:

let greeting = "Hi, I was born in "
let year = 1977
let completeGreeting = greeting + String(year)

One final example in this simple introduction to Swift is the much easier way to do what I just did above. Wouldn’t it be easier if I could do something like C#’s String.Format() or Ruby’s string interpolation? Yes it would, and yes I can! My previous example could also be written this way:

let year = 1977
let completeGreeting = "Hi, I was born in \(year)"

And what if I wanted to execute a little bit of code via an expression in there? I could easily do that like this:

let year = 1977
let completeGreeting = "Hi, I was born in \(year)."
let altGreeting = "If I had been born 10 years later, it would have been \(year + 10)"

This post just scratched the surface of what Swift is and how its syntax can be used to handle simple variables. In my next Swift post, I’ll cover some more complex types, control flows, and how to declare functions.

iOS

Podcast Episode 16 – WWDC 2014 Recap

WWDC 2014 LogoIn episode 16 of the podcast, I recapped the 2014 Worldwide Developer’s Conference (WWDC). I had the keynote on in the background when it was broadcast (Monday, June 2nd), but I hardly paid attention to it. I was getting regular updates from co-workers and I saw Twitter explode when Swift was announced. I also went and read recaps and listened to other podcast recaps, but they didn’t really hit on the details. They focused on the headlines.

I had it in my mind that day to do a WWDC recap episode, but I needed to make the time to watch the 2 hour keynote for myself and take copious notes. I finally tackled that yesterday and sat down immediately after and shared my thoughts in this latest episode. This is actually my longest “solo” episode at 27 minutes, but I really tried to have it as full of material as possible. If you have been interested in the keynote and didn’t have time to watch it (or just wanted to hear my thoughts), check out this episode!

You can also subscribe to the podcast at any of these places:
iTunes Link RSS Feed

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.

General Tips

We have a lot of great content to show you

This is definitely one of those blog posts that will serve as a reminder to me when I forget the answers in the future.

I’m using Visual Studio 2013, when I noticed a message under the Product Videos header that said, “We have a lot of great content to show you, but we need your permission to keep it updated”.

We have a lot of great content to show you, but we need your permission to keep it updated

I am the kind of person who enjoys knowing what is going on and staying current and I think everyone knows that Microsoft really seems to care about developers. As such, they put out a lot of amazing content through their channels and partner channels. I wanted in on this gig. So, I did some digging and to “give permission”, I needed to go to the Tools menu and select Options.

Visual Studio 2013 Tools .. Options

Then, from the dialog box that popped up, I select Startup on the left and then put a checkmark in the box next to “Download content every:”. I left it at the default of 60 minutes and clicked OK.

Visual Studio 2013 Options .. Startup .. Download Every

My startup screen then immediately refreshed and now I have a list of videos that I can check out.

Visual Studio 2013 Product Videos Shown

Podcasts

Podcast Episode 15 – Is College Worth It?

The Ohio State University CampusIn this week’s episode, I tackle the tough question of whether a college degree is worth the expense. My focus is for programmers, but you can easily apply my logic to your course of study.

If you listen to the podcast, I can understand if you might think that I have a confirmation bias because I ultimately recommend the course that I’ve taken. I have honestly been aware of that and tried to take it into account as I formed my opinion to share on this podcast. I not only looked at my life, but at others who took many different paths and compared the outcomes. Over and over again, I saw a pattern emerge and that pattern is what led to what has now become episode 15 of the podcast.

As I mention on the episode, if you disagree with me, I’d love to hear your side. I hope that you also will try to look past only your own experience, but I’m interested in everyone’s opinion. You can just comment here on this blog post or make your own blog or podcast rebuttal and just let me know here or on my Twitter.

You can also subscribe to the podcast at any of these places:
iTunes Link RSS Feed

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.

Code Tips

Why Salt Your Hashes?

Note: Post has been updated below

SaltSalted hashes? Have I decided to blog about breakfast?

No. By “Hash”, I mean “cryptographic hashes” and by “Salt”, I mean “additional input added to a one way hashing function”. Back in Episode 4 of my Podcast, I talked about a system that was written from the ground up to manage users, passwords, and permissions. During my little rant, I talk about storing passwords as the result of a one-way hashed value, but I didn’t really elaborate.

I realize that many of my regular readers may know this information, but I’ve been surprised at how many that I’ve found who do not. Hopefully, I can shed some light to those who don’t know and also become a viable source in search engine results for when the question is asked.

Let’s get the easy part out of the way first. We KNOW not to store plain text passwords, right? Some people know that and choose instead to store the passwords via two-way cryptography, meaning they can encrypt and then decrypt the password to compare it or email it you. That is also a terrible idea. Now, your entire system is only as secure as the security around your decryption key or decryption certificate. You’ve just made an attacker’s job very easy.

The better way to store passwords is to only store the result of a one-way hash. Then, when someone presents their password for authentication, you just hash the input and compare that to what you have stored in the database. However, even though this is good, it is still not right.

Take this for instance. Here is a sample table with hashed passwords.

user password
pete b68fe43f0d1a0d7aef123722670be50268e15365401c442f8806ef83b612976b
bill 59dea5f67aea4662c26a5ac6452233e783407d55c4f96d6c4df6f0d7c06c58af
jeff b68fe43f0d1a0d7aef123722670be50268e15365401c442f8806ef83b612976b
andy b6642c42bd670b0c070dd45d087877a4bc8d6ee29c88df59273ea48ed72b76c4
ron b68fe43f0d1a0d7aef123722670be50268e15365401c442f8806ef83b612976b

Right away, you should be able to see a problem. The hashes for pete, jeff, and ron are all the same. A common attack against hashed passwords is a rainbow table. In that case, dictionary words (or common known phrases) are pre-hashed and those hashes can then be compared against a compromised database. Let’s take a look.

password SHA-3 (256) Value
password b68fe43f0d1a0d7aef123722670be50268e15365401c442f8806ef83b612976b
letmein ceaa5fd0a764ad8202f43f2efc860d8c7472911ca9d1ccea2dc232713ae1fc0d
blink182 aadfce5bdba224673c168fb861f45cdd6ebf4e34d35001ae933bd53b7f6b337f
password1 abbe6325ea0d23629e7199100ba1e9ba2278c0a33a9c4bfc6cd091e5a2608f1a

Now, by comparing, we can see that the password for pete is the word password. That means that the password for jeff and ron are also “password”. By only cracking one hash, we gain access to two other accounts. This is not good.

The fix is to “salt” the password before hashing it. You want that salt to be a unique value. Some people create a random value and then store the salt alongside the password in another database column. Others derive the salt from something like the row’s primary key, etc. Either way is fine (as long as your derived value won’t change).

Now, let’s examine our user table.

user salt password
pete I7Yrs9THQyLxpVllSwbf 9b7ec6d82075a9e7d8227897e8919785031b9a7cdab5750dea044390d1fd1f46
bill K0kJJCQcVVqfLzykcpbP 297d00ae29ff3c32fe874c00d0154085ac862a154b061c17cd465de7f1cdee9a
jeff NwV7PdmPUKY6GgScEUqu c2936d36583d0513980e496005872e4954d142ed823b7b0b1abf28211efc538f
andy GpHrXjbQRTjObZWM7jbd 0338bd60f7d761ce9c8922087e87c9ccb7936bb5f9c5c28d72fd28f4d8708e6b
ron iHh8SX7fQEF2WFUOfxEp 07f459276c9be7d63aa8d57dac7468c8b16dd4367e91615fb9972543a707c403

We notice right away that none of the user’s hashes are the same. I didn’t change the passwords, but the salt values made the passwords unique so that they all hashed differently. We can no longer tell whose passwords are identical. Also, our plain dictionary attack no longer works. Even though we’ve telegraphed to the attacker what salt to use, the attacker would have to generate rainbow tables across their entire dictionary for each individual salt.

This isn’t 100% secure (nothing is), but this is a best practice and certainly will slow the attackers down. This method of storage, combined with strong passwords should keep your data as safe as it can be.

Thoughts? Disagreements? Share them in the comments section below.

EDIT (5/16/2014): I talked on my podcast referenced above about how easy it is to get behind or to overlook things if you do your own security as yet another reason NOT to do it. I recommended just using existing products or frameworks that have already been hardened over rolling your own. As a perfect example, I talked about doing all of this, but forgot about bcrypt (and others) that are much more secure, salt the value for you, and already have libraries in all of the major languages.