Thanks to everyone who participated in T-SQL Tuesday #58.
Here is the list of participating posts.
This list contains all the posts I was able to find and they are listed in no particular order. Please let me know, if I missed any.
There are also rumors of a few stragglers still being written. While the official rules don't allow for this, if you follow all rules, but got the week (not the month) wrong, I might still be able to add your post to this list.
Rob Farley (B|T) was the first to post. Rob reminds us that passwords are really a "secret" and that we should be careful, with whom we share that information. As professionals, we should also try find ways to not require clients to share their secret passwords with us.
Boris Hristov (B|T) encourages us to communicate across teams. While that is important in many areas of software development or IT in general, missing communication around password changes can be disastrous.
Aaron Bertrand (B|T) adds to his long list of Bad Habits posts. In this edition, he reminds us that using the SA account is a (very) bad practice. Particularly, as it requires publishing the SA password which in turn makes it close to impossible to change it. (If you need to change it after all, refer to Boris' post.)
Russ Thomas (B|T) investigates how passwords for registered servers in SSMS are stored. He concludes that the current encryption methodology of this information seems a lot stronger than in older versions of this software. However, the algorithm is still not published, and therefore the security cannot be confirmed.
Andy Levy (B|T) recommends 1Password (which is also my favorite password management program). Andy also reminds us that security is like an onion and you need many layers. In the context of passwords that includes using two factor authentication wherever possible.
Wendy Pastrick (B|T) gives us a mnemonic device to generate and remember complex passwords. You will always have a few accounts that you cannot manage with the passwords manager, like the password for the password manager itself. For these few cases use Wendy's method.
Jason Brimhall (B|T) takes on a similar topic as Boris. He reminds us that you do not only have to communicate when changing passwords, you also have to document the new password (preferably not on a sticky note). Otherwise, you might end up in serious trouble down the road. In Jason's case, the lack of documentation caused the SQL Server service account to be locked out. That is a really rather bad situation to find yourself in.
David S (B|G) reminds us that really only the password length matters. A complex but short password is a lot easier to crack than a simple but long password, at least as long as you do not use something easy to guess.
Kenneth Fisher (B|T) explains how password hashing works. He concludes that "123456" is a bad password. You will need to read his article to figure out how these two messages are related.
Steve Jones (B|T) introduces Password Safe and tells us the story of how Password Safe together with a well-crafted script enabled him to manage the required regular password changes in a large-scale organization.
Finally, in my (B|T) own post for this T-SQL Tuesday, I compare five different options to manage the administrative passwords in your SQL Server environment.
What a party - Thanks to everyone who showed up. See you next time.
You must be logged in to post a comment.
Pingback: T-SQL Tuesday Topics | Voice of the DBA
Pingback: 2014 T-SQL Tuesdays – T-SQL Tuesday
Pingback: T-SQL Tuesday #058 – Passwords – T-SQL Tuesday