Is your password secure?

Sad to say, chances are, it isn’t.

Do you use an English word as your password?  Maybe with a number appended to it?  Not good.  Dictionary attacks are commonplace.

Let’s see, do you use a bit of information in your password that’s easily obtainable?  Like your birth date or spouse’s name?  Again, you’re asking for it.

Now the kicker: do you use the same password on multiple sites?  Oh oh.  My personal pet peeve.  Think of your password like a lock.  Would you put the identical lock on your house, cars, safe, etc?  What if you lost your key?  You’d have to change all the locks.  What’s worse, with the Internet you don’t always know when the key is lost.  Actually here’s one time we do know: Sony’s been hacked (again) and 40,000 username/password combinations have been posted for all to see.  So if you’re in that list, and you used the same password on other sites – well, I don’t need to tell you.

To test password uniqueness, Hunt compared the Sony data to a database of
Gawker usernames and passwords, which were hacked and released late last 
year. He found that of those accounts that used the same email address on
both sites, 67% used the same password on both systems.

Here are some basic rules to follow when coming up with a password:

1. Use a different password for every site.
2. Make it long.  How long?  Well it’s easier to say what’s not long enough, and that’s 6 characters.  Go 8 or 10 characters or even longer.  You could use an entire phrase.  Research shows size trumps content.
3. Use a mix of character types.  So upper and lower case letters.  Some numbers.  And at least one special character (non-alphanumeric).
4. The best passwords are random ones, and people don’t generate the best entropy.  Actually even machines have a hard time generating a truly random number.  But given the differences, you’re best off using a utility to generate a random password for you.  Yeah, yeah, you’ll need some way to keep track of all those passwords.  Welcome to the information age.

-Krip

How to protect against SQL injection attacks

SQL injection is the act of injecting some characters (e.g. SQL) into a SQL statement causing it to perform an unintended (e.g. malicious) action.  It most often occurs when some criteria fed to the query is provided by user input (or is editable by a user – say the querystring in a URL or a field on a web form).

A number of things contribute to making this type of attack possible including: 1) insecure code, 2) unnecessarily highly privileged database access accounts.

Things you can do to protect against SQL injection:

1. DO NOT execute any T-SQL by concatenating values, particularly where user input is involved
2. Use parameterized SQL instead – this ensures that values are escaped such that a T-SQL command cannot be terminated
3. Use stored procedures where the T-SQL is static and criteria values are passed in as parameters (then use in conjunction with point 2 above)
4. Do not grant your database accounts used by your application unrestricted access to databases.  DO NOT grant them DBO rights in a production OR test environment.  This is a HUGE BENEFIT of stored procedures.  Stored Procedures can be granted execute rights and SQL Server’s chaining system (known as ownership chains) will automatically allow those operations to run against objects (e.g. tables) without explicit rights there.  Grant rights directly to tables only if application code must run SQL directly.  Even then pay attention to SELECT vs UPDATE rights.

References:

1. How To: Protect from SQL Injection in ASP.NET (MSDN article from Microsoft Patterns & Practices)
2. SQL Injection (MSDN article with great tips on protecting against this)

-Krip