Saturday, November 7, 2015

Blog: Resurrect or Die?

This blog has been idle since 2012. Does anyone care?

Like many, I let this blog die. I think that’s happened for a variety of reasons, both personal and professional.


Most of what I was posting was clearly not going to make any difference to myself or anyone else. Posts that announce [random software] has [random vulnerability] could just as well have been machine generated. The state of software security is at best, marginally better than it was a handful of years ago, and some random guy blogging about it isn’t gong to change that.

A few posts were and are still relevant. No matter what I do, I’ll maintain access to those.


Having more than one open Oracle Sev 1’s per team member was brutal. We were in a situation where a small handful of us were working a seven-day pace for months. A few months of that and I was more than ready to back off from my immersion in technology and recuperate a bit. Hobbies got more interesting, and being able to disconnect from 24x7 operational responsibilities was essential.


Having multiple layers of leadership turnover simultaneously created a work environment that was unpredictable and chaotic. Uncertainty affected staff moral, working environment went from stressful but fun, to simply stressful. I got a new boss, and along with that a significant job change. 

Blogging is dead

Of the hundred-odd  blogs that were in my RSS feed, only a handful are being maintained. The center of gravity has shifted. I miss following bloggers – as well formed, thoughtful ‘long form’ writing still interests me far more than short, disconnected 140 character messages.

So – let die gracefully, resurrect, or something in between?


Tuesday, August 7, 2012

The very four digits that Amazon considers unimportant...

"The very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification..." Honan wrote.
Four digits, when combined with my home address and bank account number were all it took for me to gain on line access to a dormant checking account at my bank and enable fund transfers. If I were fond of the various auto-pay options, there would be a dozen or so companies that would have my checking account number, any pretty much anyone in the world can find out my home address (I own a house, so it's in various public records).

Segmenting ones on line life into non-overlapping buckets seems like the best way to break the daisy chain that led to the hack and data loss. I've followed that principle. I try to maintain separate, non-overlapping e-mail addresses and passwords for any on line account that either is connected to something that could cost me money if it were compromised, or is used for account verification for any of those accounts.

I have lots of e-mail accounts and addresses. It's a pain in the azz, and it's only a partial solution.

Read:  ARS, Wired

More thoughts here.

Friday, July 6, 2012

In MumbleWare versions 8.2 and below, the SA password must be set to propq

An e-mail from a vendor, somewhat anonymized:

From: ****
Sent: Wednesday, April 11, 2012 08:22 AM
To: ****
Subject: MumbleWare Case 123456789

Hello ****,
Thank you for contacting MumbleWare Product Support.  I am writing to you in reference to case number 123456789 regarding your request to change your SA password. In MumbleWare versions 8.2 and below, the SA password must be set to propq. If a different password is used, MumbleWare may not be able to communicate with the database and error messages will be generated. The attached KB article references the fact that the SA password must be set to propq in MumbleWare versions 8.2 and below. The second KB article lists the steps involved in moving from MumbleWare 8.2 to 8.3.   
It's only been a decade since we first asked  the obvious question "Can we change our SQL Server SA password without breaking your application".

I guess we finally can.