Author: way0utwest

  • High Security Prices–Always Encrypted 2019 needs Datacenter Edition

    I was recently doing some work on Always Encrypted in SQL Server 2019 and needed to set up an HGS server. I went through most of the setup, and then encountered this issue:

    2019-04-24 07_52_51-Window

    After embarrassing myself to other MVPs and Microsoft, I realized I hadn’t read the requirements for the secure enclaves. I need 2 machines, but the SQL Server has to run on Windows 10 or Windows 2019 Server – Datacenter Edition.

    Grrr, I had built a machine for this and need to tear it down and restart the process. It’s not that hard, but it’s annoying.

    I should learn to read more carefully.

  • Long Live All Passwords

    I remember the first time I had to create a password for a system. It was an application that a friend and I wrote, and we wanted to separate the ways that we stored data, so we added a login routine to the system. It stored a (plain text) password, but hey, this was 1983. We loaded the password and made a string comparison with the entry by the user.

    Since that time, most organizations I’ve worked in have had password policies in place on the network. These passwords often had expiration dates, with short warnings for users to change their passwords. The requirement to change never seemed to come at a good time, and with the requirement to not reuse one of the last 5 or 10 passwords, this resulted in users often adding a 1, 2, 3, etc. to the same password. As an IT pro, I often tried to get users to choose new passwords, which fell on deaf ears.

    Microsoft is rethinking the idea of passwords expiring. There’s a piece that explains how they feel this requirement is not helping security. This is similar to a piece at SANS that notes the practice is not helpful. Changing passwords has a cost to your organization in extra tickets for a help desk, lost productivity from dealing with expiration, and frustration from users. What’s worse, far too many users just “update” a password with a number or year. Neither of which is effective.

    The current advice is MFA (multi-factor authentication), passphrases, and password managers. Personally I try to use all of these where I can, and choose long passwords. It does seem that many companies are updating apps to allow longer passwords and 2FA. I’d like to see this embedded into more frameworks, making it easier for developers to implement secure authentication systems. That, or use existing systems out there, like oAuth, though there is an argument how secure this is. Even if there are issues, it’s likely better than what most developers would build.

    In SQL Server, we have group Managed Service Accounts (gMSA), which are a good way to avoid password management, and ensure complex passwords. We should disable, and set a complex password for, the sa account. While I wouldn’t advocate changing this regularly, I would have alerts if the account is enabled.

    Like most people, I try to avoid changing passwords unnecessarily, especially these days where I have accounts at dozens (or hundreds) of places. I do, however, ensure that all are different and unrelated. At least then if a password is compromised, I don’t worry about someone logging into a different service I use with the same credentials.

    Steve Jones

    Listen to the podcast at Libsyn

  • A Busy Few Weeks and Vacation

    I’m taking a short break from blogging with a 3 week trip to Australia and New Zealand. I’ve got quite a bit of work to do, as well as session prep for a busy schedule (5 different sessions to deliver) on quite a few time zones away from home.

    And a little break in the middle as my family joins me in NZ.

    Look for some blogging to pick back up the week of June 17.

  • Republish: Too Large a Workload?

    I’m on the ground in Australia, but who knows what time it is. No idea if I can work, so you get Too Large a Workload? again.