For some time now, I’ve been on a mission to see if I could go “full iPad.” I should provide some basic context:[Read more…] about Going Full iPad
I’ve recently been in several discussions about Microsoft’s MVP Program – with a podcast episode on it publishing 17-March – and it’s gotten me thinking a lot.[Read more…] about OPINIONRANT: The Microsoft MVP Award Program and the PowerShell Community
Well, yet another data breach from yet another business that couldn’t afford top-shelf security, or didn’t understand the need for it. At this point, I think we should probably assume that all our data has been stolen, and it always will be.
We’ve focused for a long time on the idea of “let’s keep our information secure,” and it hasn’t been too long before we started to admit defeat with ideas like, “don’t use the same passwords on every site, so that if one is breaches, the others remain secure.” I think it’s probably time to move to an assumption that nothing can stop our data from being stolen.
That can actually change how you act.
For example, consider making everyone in our life invest in a password manager of some kind – even if, God help us all, that’s a paper journal you buy on Amazon. We really do need distinct passwords for each site, and they need to be phrases like “I-am-Using-Twitter-Right-Now-12345” or something. Forget 8 characters; make ’em long. Doing so makes it significantly harder for bad guys with hash tables to reverse-engineer your password, should they obtain hashes in a breach.
Press everyone to use tap-to-pay whenever possible, and kvetch to local merchants who don’t yet support tap-to-pay. NFC payment systems create a unique, per-transaction code that’s essentially useless anywhere else. If that number gets captured in a breach, it doesn’t matter. More websites need to start accepting Apple/Samsung/Whatever Pay as well, so that we’re not asking them to store permanent credit cards which will eventually be breached.
When asked to create “security questions” for account recovery (“what’s your mother’s maiden name?”), use a distinct, fake answer for each website, and note those in your password management tool or journal. For example, I’ve one website where my “mother’s maiden name” is DarthAvon. But there’s more you can do to protect yourself than making fun of Mom.[Read more…] about At this point, you should probably assume your data will always be public.
As many of you know, Missy Januszko and I wrote The DSC Book some time ago. As we’ve moved on in our careers, we’ve not had the time to update the book – although we still feel it’s valuable and is worthy of being updated and expanded. So we’ve come up with a solution.
Effective immediately, The DSC Book is now an open-source project, “owned” by DSCCommunity.org. It remains available on Leanpub for a minimum price of $0, and if you choose to pay more, all proceeds go to The DevOps Collective‘s IT scholarship programs. The GitHub repo is public.
If you’d like to contribute to the book – and that includes noting any typos or other errors, as well as adding or updating material – please fork the repo, make your changes, and submit a pull request.
Missy and I want to thank everyone who supported us by purchasing the book, and we want to thank everyone who’ll contribute to the book’s contents in the future.
Yesterday’s post was in response to a colleague who’s been asked to speak at an upcoming conference panel. Part of the title of the panel is “Breaking Silos,” and I love that phrase.
A colleague was recently asked to speak at a conference panel, and one of the suggested talking points was, “How to evaluate new technologies for your business (e.g. set/lead or follow trends and standards?).”
In almost any instance like that, given a choice between X and Y, I almost always try to go with “Purple.”