I recently had a discussion about web app security and we were talking about the not-so-distant past when SQL-injection was the scariest thing since polio.  90% of these attacks didn’t try to return everyone’s credit card information from a database (people knew pretty early to be careful when storing this stuff), they were attempts to simply return a username and password.  

As a result, many people would go to a site that doesn’t need very much security (like a forum), and run some sort of sql-injection to return all username/password combinations from the database.  Then they would spend the whole day going from bank-website to bank-website, trying each and every one of these combinations (not only do most people use ridiculously simple passwords, they also re-use them for multiple sites) and they may get one login from one bank.  This could turn into several thousand dollars by draining that single account.  

Now, I know things have changed quite a bit, and bank websites have stepped up security standards a good deal.  I also realize that convincing people to be smarter about their login passwords would be a major challenge. However, I’m always shocked to find out that some web developers still store passwords in plain text in dB column called “password”.  

That brings us to one of the simplest methods for securing against password retrieval, that many people just don’t do. Now, there are many ways to secure against sql-injection, but let’s pretend for one minute that, somehow, someone gets the information in your database.  It doesn’t matter if it’s through injection, or getting your shared-host login from something, or someone having direct access to your server.  But let’s just say someone has your dB data, and they have all of the stored username/password combinations.  

The easiest thing to do is use a digest or hash for password storage.  You never actually need to retrieve this password, you simply need to compare a password against it.  By comparing the same hash of the input password against the stored hashed password, you are achieving the same thing. Your logins work exactly the same, except you have 4 extra lines of code.  

For another small method to improve security, add some secret letter/number/symbol combination to the word before storing/comparing.  Because most people have terrible passwords, if someone does get the information, they could get the passwords from sites that build dictionaries of MD5, SHA1, etc. combinations.  So by adding a small snippet to the end of the password, not only are you improving security against a dictionary attack, but you are differentiating this password from the user’s password that may be used some where else.

Most developers, I hope, will have learned nothing new from this article and will consider it quite obvious.  That’s a good thing.  But after hearing from a few individuals who still used plaintext storage of passwords, I felt as though this might help someone.  

Recently I have been discussing with some fellow coders the benefits of plugins, and when you should write your own code.  I basically wanted to throw out a couple of ideas and hope for some discussion on the topic.  Let me know what you guys think and I’ll do a follow up soon.

Some Background

I, like many of you out there, started programming back in the day by messing around with computers, writing little calculator programs, making websites, etc.  But I really didn’t get into it much more until I started college, where I immediately started programming with C++.  

Most of my classes started out with projects where we had to write everything (no STL!), and all of my code was from scratch.  Once I started doing more of the “development” in “web design and development”, I still practiced the idea that the only code I know is good is the code I write.

But now I can see…

Then one day, the skies parted, trumpets sounded, and my designer Steve said “Hey, have you heard of Ruby on Rails?”  

I immediately started developing with nearly pure Rails, using the built-in-just-about-everything and loving the fact that anything I couldn’t code (or didn’t want to) was usually readily available in plugins ( I love file_column!).  

I will say this, RoR is good code.  And it’s constantly being improved.  For the most part, the plugins are also good code.  And many times, a plugin works perfectly into your project to save you time and add functionality.  

Good Programming

Ask any real programmer, and the efficiency of code is not only about how it performs, but how long it takes you to create.  So obviously there is a trade-off between using plugins and writing your own code.  

That being said, if you are a web designer who is using rails to help you out, or just trying something new, use the plugins: they are great and it will save you days of coding and headaches.  

If you consider yourself a developer (or hope to), you should still use plugins.  If you code everything, you’re going to waste time. However, don’t completely rely on them.  If you want to be a programmer, you need to know how things work, because some day there won’t be a plugin for you, and you’re going to need to know what to do.  

Also, plugins are meant to be helpful for a range of situations.  Therefore, there is going to be some overhead.  If you are concerned with performance, and a plugin isn’t “perfect” for what you’re trying to do; you might need to code from scratch (or at least be prepared to customize the plugin code).

Here’s the thing…

All things considered, I will say that my natural tendency is to code most everything myself.  I like to know where everything is, and exactly what the code is doing.  I also appreciate when the code is only doing exactly what I want it to do.  If it’s impractical to write something, by all means I will ( and do ) use plugins.  

If you want some good coding experience, and have the time, try writing something yourself that you wouldn’t normally do.  Even if you don’t end up using it, you’ll learn a bit more about RoR (or any other language) and you may just have some good code you can use again.

Agree? Disagree? Don’t care?

I’m just one guy.  Let me know what you guys think.