Subscribe to the RSS Feed.
A Digital Legacy
With the death of our national leader in December 2007 and with the loss of the original YWAM IT website over a year ago, I started thinking about how I am managing the communication assets for YWAM in my country. I realized that if anything would ever happen to me, there would be no way (or an extremely difficult way) that my leaders would be able to recover a myriad of important things, like several YWAM Latvia websites, email accounts & other confidential services.
So, I have decided today to do what I've been thinking about doing for a couple of years now & that is to create a simple text document that will contain all of the login information (usernames, passwords & URL's that apply) that I will forward on to my leaders for safe keeping.
Not only will this ensure access to important information for leaders should they need it, but it will also help in creating a good path for handing off these things to other staff who will come after me.
In addition to creating this document (which I intend on not only emailing to my leaders, but also printing out as a hard copy for storage in a safe), I plan on creating some backups of files & databases, which is a lesson we've learned from ywamit.com.
I know this may seem like something that should be considered incredibly rudimentary & a given for anyone working in IT, but let's face it: the most of us have little to no formal training in IT or best practices. So, with this article, I hope to raise some awareness for this extremely important, yet sorely overlooked issue that we as a mission must come to grips with.
Bottom line: the more technology we use, the more we need to consider contingency plans. After all, we are still working with man-made machines which are not infinite.
sending passwords in a plain textfile?
This topic - human failure in IT - is exactly what I'm struggeling with also, since like ... a year ago or so. Reading news of the informatics security scene, I'm flabbergasted how many of our assumptions of how the computer works are just based on naive good-faith - similar to relying on the chair to hold you even if you never tried this particular chair before.
But before I elaborate in a future article, one thing I discourage you to is to send a plain-text Email with passwords in it. This information is far to valuable - even if it were only your private email account - to be disclosed to public like this. It's like a postcard: anyone you likes to can read what you read, either because he was part of the delivering process, or because he tricked himself into the delivering process because he expected you to send an email like this. So which possibilities remain?
1) Send it by snail mail. Depending on your geographic location, that may be insecure as well - you should know how much you trust your post office.
2) Encrypt the Email. PGP / GPG is a great thing to do; with some IT knowledge you can integrate it into your Email client (e.g. enigmail for Thunderbird) or Computer (to decrypt in your clipboard, e.g. WinPT); if this knowledge cannot be assumed, may be hushmail.com comes handy (Webmail-Service with PGP Encryption).
3) Encrypt the File. Programms like KeePass are designed for storing mission-critical data/files like passwords. The whole database is protected by one (hopefully good) password and/or password file - which then has to be transmitted seperately, on a different communication medium - because the chances that somebody can eavesdrop your Emails & telephone (or snail mail) are significantly lesser than just one of both.
So personally I would opt for 3): set up KeePass, write an Email to explain to your recipient how you set it up; then store all relevent data into this, protected by a 20-character-random password (KeePass can also generate good random passwords); then send a letter containing the password. This should be a good compromise between security and costs (time to learn how it works included).
(Be aware, that backups of websites are almost as critical as passwords, as they often contain passwords (hopefully in a obfuscated form, but anyway). E.g. the drupal config file contains access params to the database, and the drupal database contains the user passwords in a little-encrypted form (md5))
Post new comment