Not More Than 16 Characters?!?

Microsoft, you’re killing me. This is the warning I received when typing in a password for Office 365:

More More Than 16 Characters

I blinked when I saw the warning, “Your password can’t be longer than 16 characters.” I couldn’t believe that I had gotten that warning, so I erased what I had typed for a password and started typing 1, 2, 3, etc., to see if this warning did trip at 17 characters. It did. Why in the world is there a limitation on password length if you’re going to do a hash my password? And if you had to pick a limit, why 16 characters? Why not 50 or 100 or 255?

I’ll give Microsoft credit for password complexity requirements:

  • Require uppercase
  • Require lowercase
  • Require number
  • Require a special character from a select list

However, we know that password length tends to be more important as long as you stay away from dictionary words. Therefore, if you’re building a system that takes passwords, don’t limit password length and use secure hashing algorithms and store the hash.

Protecting Against Delete without Where

If I’m doing any manual work with T-SQL, I always begin every set of data change operations with BEGIN TRAN and I have the COMMIT TRAN commented out at the end of my script. Why?

Quite simply, because I’m wary of having a DELETE clause without a proper WHERE clause. I’ve made that mistake in my career and it’s easy to do if you are tired, pressed for time, or both. This allows me to verify I’ve only changed what I intended and then I highlight and execute the COMMIT TRAN to finish the operation. However, there have been times when I neglect this habit. 

Which is why seeing Steve Jones’ post about a new feature in SQL Prompt made me smile. If you have it installed and are about to execute a DELETE without a WHERE clause, it prompts you to verify this was your intent. As Steve writes, sometimes it is. But when it isn’t, that warning can be a life saver. 

I won’t abandon my BEGIN TRAN habit, but I will certainly take advantage of this new feature in SQL Prompt. 

A Different Type of Currency

Recently, a member of the community lamented that folks weren’t willing to provide an email address for free training. This reminds me of an old saying popularized by Heinlein, but one that was used a lot in the Perl community: TANSTAAFL (There Ain’t No Such Thing As A Free Lunch). While the training was advertised as “free,” it really wasn’t. After all, the person had to pay up something: his or her email address.

Once upon a time, we didn’t think anything of this. However, then SPAM became more than a nuisance. And despite increasingly advanced mail filters, SPAM still gets through. SPAM campaigns are still effective. While percentage wise they seem not to be, converting at far less than 1%, the upside for spammers is sending out a bunch of emails doesn’t cost very much. So it doesn’t take much to turn a profit. Those conversion rates are stil good enough to keep the spammers happily in business. That’s why folks are still at it. 

Worse than that, now we’re seeing phishing and spear phishing attacks, where adversaries are trying to have you click on malware or a MitM (Man-in-the-Middle) site or just a mock-up of a legitimate site that doesn’t actually take you to the original site (it usually just throws an error indicating the site s unavailable and to try again later), the latter two to capture legitimate credentials to use at the sites they pretend to be.

And that brings me to my final thought about providing email addresses: they are increasingly becoming the username to log on to various sites, such as the PASS site. So giving up your email means giving up your login unless you’re a paranoid type that has multiple email adresses just to serve to split things up. Not many fall into this category as it’s a real chore trying to keep up with a lot of email addresses.  So if you give up your email, then someone who wants to be malicious now has part of the information he/she needs to log on to those sites as you. 

Therefore, I can’t fault folks when they don’t want to provide email information for something described as free. Whe you give up your email address, you don’t know what the person or organization is going to do with it. A lot of organizations resell email addresses to other organizations. This is legitimate business, even if we personally disagree with the practive. There’s also the black market where individual email addresses aren’t worth much, but if you can sell them in bulk, then the multiplier means a tidy profit. It’s even better if you are selling validated email addresses, which are obviously worth more, because spammers know they will be able to reach a legitimate person.

I also can’t fault folks who ask for the email address when they provide resources to the community. After all, they’ve worked hard (hopefully) to be able to make those resources worthwhile to whomever wants to use them. However, if you ask for an email address, what you’re providing isn’t free. You’re just asking for a different form of currency.  You are asking for both information and identity. So don’t be surprised if someone (especially folks like me) chooses to forego accessing a resource instead of providing the email. At the end of the day I have to make a decision on a value proposition: is what you are providing worth what I am giving up? Some folks win, other folks lose. That’s just the way it is.

Slides from 2016 Techno Security & Mobile Forensics Conference

I’ve completed both of my presentations at the 2016 Techno Security and Forensics Investigation Conference (#technosecurity). If you were able to make it to one of my talks, thank you for choosing to spend your time with me. While my slides will be available from the conference site, I’m posting them here along with the scripts I used.

Monday – Securing the ETL Pipeline

In the archive I’ve also included a second slide deck with scenarios to consider with respect to what I was discussing in the presentation. I used these scenarios for a SC Midlands ISACA class that was an extended version of the same presentation.

Tuesday – What Auditors and IT Pros Absolutely Must Know About SQL Server Security

I’ve included the setup scripts, the queries I ran to audit SQL Server, and the clean-up scripts used in the demo. If you have a non-production SQL Server where you have sysadmin rights (Developer Edition is now free, BTW), these should all work for you.

Sights that just scream, “No!”

I’m at a conference, specifically a security conference. So I looked at the available WiFi connections. Among the conference and hotel specific connections and the MiFi and cellphone uplinks I spotted this one:

Wireless Connection - Free WiFi for Bums

That just screams, “No!” TANSTAAFL.

Congrats to MSSQLTips on 10 Years!

MSSQLTips has posted about their 10 years as a resource to the SQL Server community. It’s where I do the bulk of my writing these days, mainly because I like the problem/solution format. However, the folks at MSSQLTips didn’t just write to acknowledge their 10th birthday. 

They also posted about donating to charities and making this a global effort with the hashtag #MSSQLTips4Change. MSSQLTips is donating $10,000 over the next year to various charities. They are hoping we as a community will also help spread word of these charities via social media. Also, if we feel inclined, to donate ourselves. 

The first charity has been announced: Soles4Souls. Please spread the word!