Another month, and another T-SQL Tuesday. I have some blog posts I've been meaning to write, but the scheduling of T-SQL Tuesday and my determination to keep my record of never having missed one keeps me going. This month is hosted by Sebastian Meine (@sqlity), and is on the topic of Passwords.
Passwords are so often in the news. We read about how passwords are stolen through security breaches on a regular basis, and have plenty of suggestions on how using complex passwords can help (although the fact that tools such as 1Password put passwords on the clipboard must be an issue…), or that we should use passwords that are complex through length but simple in form such as a sentence – and we naturally see xkcd.com jump in on things with poignant commentary on life in a tech world.
Instead, I want you to think about what a password means.
A password means that you have secret information that only you have. It's what 'secret' means. As soon as you tell that secret information to multiple places, it's not secret any more. Anyone who has seen my passport knows where I was born, and there are plenty of ways to work out my mother's maiden name, yet these are considered 'secret' information that can be used to check that I'm me.
These days, I carry multiple RSA tokens around with me, so that I can log into client sites, or connect to bank's internet banking. The codes on these devices are considered secret, but actually, they contain a secret piece of information that can be used to identify me, through the codes they generate. Combining a password and these codes is considered enough to identify me, but not in a way that can let someone else in a few seconds later when the numbers change.
When I develop SSIS packages for clients, or just about anything that needs to connect to sensitive data, I don't try to figure out what passwords need to be included. Where possible (frustratingly it's not always), I don't include passwords in database connections at all – it's secret information that I shouldn't have to know. Instead, I let the package run with credentials that are stored within the SQL instance. When the package is deployed, it can run with the appropriate permissions, according to the rights given to the user identified in the credential. The trust that is established by the credential is enough to let it do what it needs to, and all I need to tell the package is "Assume you have sufficient rights for this." I don't need to store the password anywhere in the package that way, and I'm separated from production data, as every developer should be.
I studied cryptography at university, although that was nearly twenty years ago and I hope things have moved on since then. I know various algorithms have been 'cracked', but the principles of providing secret information for identification carry on. I believe public/private key pairs are still excellent methods of proving that someone is who they say they are, so that I can generate something that you know comes from me, and you can generate something that only I can decrypt (and by using both my key pair and yours will allow us to have a secure conversation – until one of our private keys is compromised).
Today we need to be able to identify ourselves through multiple devices and our 'secret' information is stored on servers, protected by passwords. Our passwords are secret, and anyone who knows any password we have used before could try to see if this is our secret information for other servers.
I don't know what the answer is, but I'm careful with my information. That said, I was the victim of credit-card skimming just recently, which the bank detected and cancelled my cards.
Just be careful with your passwords. They are secret, and you should treat them that way. If you can make use of RSA tokens, or multi-factor authentication, or some other method that can trust you, then do so. Hopefully those places that you entrust your secret information will do the right thing by you…
Be safe out there!