Wednesday, September 17, 2014

Gaining New Javascript and Python skills...

Recently I've decided to take my JavaScript skills to the next level. While I've been an engineer for many years, (nearly a decade professionally and twice that as a hobbyist for those curious,) I had always dismissed JavaScript as many had, a language for nice little transitory animations and form validation on sites. I am however, finding that it can be a full fledged and fairly powerful language.

To bring my skill set in JS up to snuff I've been doing the Codecademy courses in both JavaScript and jQuery, in addition to going through various JavaScript powered APIs. And I can safely say, my horizons and abilities with not only JavaScript, but also object oriented programming have expanded dramatically. This is mostly due to using JSON (JavaScript Object Notation) and working to understand various RESTful APIs such as those of Microsoft's OneDrive/SkyDrive and YouTube.

With most of what I can take away from Codecademy done, I've turned to doing their Python and Ruby courses for fun and a bit to feel the accomplishment of finishing all of their main courses. As I do this though, I find myself realizing how little I actually know of the Angular framework and seeing how fast I adapted to new concepts and syntax. (For example, the "dictionaries" in Python essentially being JSON syntax... Awesome!)

So, I'm looking at doing Code School's courses since I've already done a little of their JavaScript Mastery course and Github elective, I really want to make myself a continually stronger software engineer. But I've decided that I won't be doing that until after I get all of Codecademy finished out and I highly encourage anyone interested in beginning into the realm of programming to start there. I even tell those I tutor to go there as a supplement to everything else, as I know I can't cover every learning style.

Saturday, August 30, 2014

I Love Eclipse

Decades ago, when I started developing, I had no clue about IDEs and the like. My first would probably technically have been Dreamweaver and then a version of Visual Studio back when VB6 was still a thing. But eventually, I found myself using Eclipse and while it was a bit steeper, it made more sense as I began doing more, and I still find myself using it to this day for continually more development.

For example, in previous postings I've pointed out it can be used for PHP and even as a RDBMS for SQL via plug-in. Another advantage I get from it is that it can be used to develop Android applications since it was one of the first officially recommended methods by Google and also, Eclipse was meant to be a Java IDE above all else, so the marriage made sense.

But I continue a decade or so later, find myself continuing to use Eclipse as my go-to IDE. Even more-so because of it being cross-platform and my switching readily between Linux and Windows. Part of me wishes I had more money to throw at supporting them.

Tuesday, July 29, 2014

Add-on to Information Security posting from the other day...

When going back through my previous post on handling and storing data which requires security, I realized I skipped over one minor thing which can be major: The difference between using GET and POST to send data to your server-side script.

Don't use a GET method to ever send data which you intend to be secure.

Why? GET data is that which is stored in the URL string as something like, "?foo=bar&this=example" ... This is as good as transferring said data in plaintext. (Granted non-alphanumeric characters would appear encoded to "%20" and the like.) In fact, I would go as far as to say to only use GET to receive data when it's completely inconsequential and ideally to only set-up a MVC for transmission of data.

Instead you should be using POST data to send sensitive data to the server. This is because instead of being part of a requested URL, the data is sent within the payload of the packet and is harder to see when utilizing SSL/TLS.

Graceful Degradation v. Responsive Design

In a previous post, I covered the concepts of graceful degradation from a UI/UX development standpoint. However, last year some time, the term "Responsive Design" swept the developer community with virility akin to that of a YouTube video.

So here are the fundamental differences in terms of concept:

Graceful Degradation is to ensure your application functions as well as possible across all devices as you take away the building blocks. (IE: What to do when a technology such as Javascript or the Flash plug-in are missing.)

Responsive Design is the progressive enhancement of your application based upon  the least amount of technology and front-end control possible. Then build your way up from there.

The idea of both of these is to help things along when the user experience would otherwise be sacrificed. However, they differ in one major way. GD is reactive by nature and RD is proactive by nature.

That may not seem major, but consider this: You want to build a large, complex, media rich site. Something that's going to display the data you want in an effective fashion.

Now you have two options. You can design the completed application with the assumption you have everything available or you can assume the end-user has minimal capabilities. And in development, especially that of front-end development, you'll notice that idea of, "less is more," really applies. Thus the RD concept of designing for mobile devices without Javascript enabled and then devices which do have it enabled.

However, rather than look at these two approaches as an either-or situation, is to realize that they work even better in conjunction with each other. For example, a <noscript> which informs the user that the site has extended functionality with Javascript enabled, should always be used in some fashion. From there, you can and should use libraries like Node.js or jQuery to carry out required functionality. (I say should because these libraries/frameworks take into account browser implementation intricacies and workarounds, and internally implement them so the end-result is more consistent.)

Tuesday, July 22, 2014

Programming Concepts: MVC

MVC or Model-View-Control structuring enables a developer to change various parts of a program without having to go through other certain parts. Or even, ideally, being able to re-use parts without having to rebuild everything from the ground up. The name of the game with MVC is a modular design. But to understand the structure, (and the overwhelming number of frameworks which utilize it,) you have to first understand the concepts behind each part.

Model -- This is best thought of as physical objects and their attributes. The same way you'd model an object in say, Blender, you can model an object's data. For this, you should ideally have good knowledge of Object Oriented Programming, as you will of course, be modelling objects.

View -- This is a scene to those who build games or a template to application developers. Essentially, what you're describing here is how to display the output data to the client. In many instances, you may build a different view for say, each level, or a set of levels. You would likely build one for various different menus and the like as well.

Control -- This is the bit responsible for connecting the model and the view. Say for example, you want every section of a site to have a view corresponding to its model to display the data as efficiently as possible? This is what makes that possible, in addition to being able to describe what should happen if you fail to find a view or even say, wish to differentiate between friends and non-friends on a social network and the data that's loaded from the model into the view. (Though largely, that check and return of data should be handled when modeling the target user object.)

So now that we have some idea of what MVC is, how is such structured in various places? Well, if you want to see an MVC structure broken down into its components, you don't have to look much further than what's available in pretty much any modern browser and the support of HTML/CSS/Javascript.

HTML is our Model and should define the data being loaded. A webpage should be able to be its own standalone document without the need for external structuring and the like, beyond what's served. For example, loading up header before main and also on-page navigation prior to content and content prior to footer.

CSS is our View and should define the way the data is presented. While HTML does have elements such as <div>, <span>, and even formatting elements like <b>, <i>, and <u>? These should largely be for formatting and marking up a document in a fashion to say, marking the text with specific purposes such as headers and foreign or emphasized words rather than being used as stylistic elements. CSS can and does provide the ability to style these elements in any way you desire.

Javascript then of course would be our controller. It can modify anything in the DOM both removing existing content and adding additional content. It can be used as a first layer of validation or even for animating various elements. It can even be used to the point of being a stand alone programming language for game development these days with frameworks such as Phaser or even mimicing the capabilities of a specialized language such as R.

Monday, July 14, 2014

Data Security: Properly Storing Passwords

One of the bigger things I've seen done wrong time and again throughout the years, would be people storing passwords improperly. (Even more in my last year as a consultant for my own short-lived firm, Ekohm.) That is to say, storing such sensitive data in an insecure manner, and in fact storing most sensitive data insecurely. What many forget is a simple rule... If you can read it, an attacker can read it.

First, let's cover some rules about what not to do...
  • Do not under any circumstances, EVER, transmit or store sensitive information in plaintext nor anything that's simply an easy conversion.
  • Do not store the data with a normal cryptographic algorithm. This is because encrypted data can be decrypted as easily as you encrypted it. Generally for secure encryption, you have a public and private key pairs. In the instance of simply encrypting on the server, all you're doing is creating with what is essentially a public key. So, in the event of an injection attack, let alone a breach, you're looking at all of that data being made available. An exception to this might be some kind of algorithm to mask email addresses or phone numbers and other potentially sensitive, but not quite as important as passwords, data. The advantage of this is stopping any meaningful data loss in the event of simple attacks like SQL injection.
  • In fact, don't store the user's password at all.
  • Do not reveal the user's securely stored password publicly, even to them. You shouldn't be able to in plaintext if you've done things properly, even if you wanted to do such. But you also shouldn't reveal any of the stored private data in general.
What you should be doing...
  • When transmitting data, enforce the use SSL/TLS. This should be done on pretty much any page where you're potentially going to be receiving data from users or visitors. You may throw the recent Heartbleed issue of OpenSSL around all you want, but that issue was addressed. (Granted, probably not as early as it should've been because apparently the US security community knew about it for 2 years or more prior. Take from that what you will.)
  •  Utilizing cryptographic HASHING algorithms. This is specifically true of when you store passwords. You don't need to ever know what another person's password is, it's a secret. This is why we use hashing algorithms instead of simple cryptographic algorithms. Hashes are one-way encryption, meaning it shouldn't be able to be reversed to reveal the original word. What you're doing is making sure the password is never unencrypted except for while it exists in memory. (AKA: Why heartbleed was bad.)
  • Utilizing a unique salt value for a user. A salt is used as an additive to additionally scramble the password. Usually for these I'll use a randomly generated binary value (stored as hexadecimal values) that changes when a user updates their password. Additionally, when storing the salt, I check to make sure its value isn't the same as any other user's salt. You must store the salt. This is your key and something of a public key.
  • When storing the password, you should be hashing it and then mixing it with the salt. The number of times you mix helps against the vulnerability in hashes, brute force attacks on the final binary hash value. The number of iterations is up to you, but the more you do it, the longer it will take for each additional password to be brute forced. This is what is referred to as stretching the stored hash. And the final result of this mixture is the second value you store that must be matched later, when a user tries logging in. You must store the stretched and salted password. The submitted password value will exist as the user's private key. Which combined with yours the specified number of times, will match the stored password value.
And that is how to securely store a password. I personally, currently favor a 512-bit hashing algorithm with at least 20,000 iterations to the final value that will be stored.

One last thing to keep in mind. No security is perfect, everything is ultimately vulnerable in some way. And it's just a matter of them finding the proper attack vector to exploit. So, you need to keep current on what's going on in the security world, in addition to the developer communities you involve yourself with.

Graceful Degradation (A Minor Add-on)

As I was fact checking my post the other day about graceful degradation, specifically in terms of Flash, I kept coming across people pushing Javascript as a method. Furthermore, pushing a function of jQuery to detect whether or not the plugin necessary for Flash is present and enabled.

My question then is, what happens when neither Flash nor Javascript are available? Then, do they have a noscript tag set to inform of the need of Javascript which informs of the need of Adobe’s Flash plugin? And this doesn’t seem ridiculous and like I’ll just go to another site, how?

The bottom line is that there’s no reason to ever use Javascript to detect Flash’s existence. Ever. Unless maybe, you're trying to save like 120 bytes from your HTTP reply, but that also seems kind of ridiculous since you're supposedly loading up the jQuery library to do such. And while it is unlikely, there are those who have both disabled, with their own reasoning.