Voice of the DBA

Author: way0utwest

  • Algorithm Secrecy is not Security

    Should we disclose this information on websites?
    Should we disclose this information on websites?

    I find the field of cryptography and encryption to be fascinating. I present a talk on encryption and  constantly find people that don’t realize the security of an encryption algorithm doesn’t depend on what the algorithm is or knowing how it works. I can tell you that I’m using an AES or RSA algorithm and that doesn’t make it any easier to decipher the plaintext.

    This week Troy Hunt wrote a piece where he called for disclosure by websites (and really all applications) of the password storage mechanism. The badge above is an example of what he’d like to see posted on all websites. His explanation of what this might change in terms of Internet security is great, and while this might not actually make applications more secure, I’m not sure that many companies would want to be forced to disclose they are storing passwords in plain text. Consumers are becoming more savvy and realize this is a poor way of managing systems. I suspect that people will quickly learn what are strong and no-so-strong algorithms.
    Real security still requires developers to not only implement strong algorithms in their applications but also make these algorithms upgradeable. We used to use MD5 everywhere (now a bad idea), and in SQL Server 2008 R2, we are limited to SHA1. This algorithm is known to have problems and SHA2 is recommended. Unfortunately you would have to upgrade to SQL Server 2012 in order to use this algorithm. You can write your own implementation, and if you have high security requirements, I’d encourage you to do so.
    Key security is important, and this is to systems what password security is to individuals. Protecting your keys (and passwords) is ultimately the way in which we can dramatically increase the level of security in applications. This is the hardest part of managing encryption in your application, and I’d encourage you to seek out someone with experience to help you understand how to best handle  this.
    Ultimately a lot of security depends on layers, with some secrecy in place, but the secrets you keep should be the exact design and implementation of your entire infrastructure, not the algorithms used. If you build encryption into your systems, please do not design your own algorithm. On a regular basis the vendors and developers who think they’ve implemented strong encryption by hiding the details of their algorithm are usually unaware of how flawed this approach is. Please use well known, public algorithms for encryption, which have been tested and probed by mathematicians in a public forum.
    Steve Jones

  • Inconsistency

    Being inconsistent isn't necessarily bad.
    Being inconsistent isn’t necessarily bad.

    Jeff Bezos has done an amazing job building Amazon into an amazing technology company. I still remember making my first purchase when they were just a bookseller. Now I buy a lot from them, and the various other vendors that use their platforms. While they are well known as a retail powerhouse, they might just as easily be seen as an incredible software company that provides a wide variety of platforms and services from the cloud.

    I’ve also followed the rise fo 37 Signals, and Jason Fried, who I think has built a company the right way. In many ways the things I admire about that company are also things I admire about Red Gate Software. These are companies that not only run successful and profitable businesses, but they do so in a way that inspires people and gives them more than just a paycheck.

    Recently Jeff Bezos stopped by 37 Signals and gave some advice. He said that the people he had found in his life that were “right a lot” about various subjects were those that often changed their minds. That’s a strong, but thought-provoking statement to me. As I think about it, it’s how I tend to view the world. I have some strong, well thought-out (I think) opinions, but I’m open to the fact that I might be wrong. Not because I don’t understand the problem or situation, but because I might not have all the information. I am very open to the idea that I don’t know what I don’t know about many subjects, especially databases.

    This week, I want to know what you’ve changed your mind about in your career. It could be something in databases, or technology in general, but I’m wondering:

    What strong opinion did you hold that has been changed over time?

    Please avoid political or socials issues and stick to something in technology that’s you have altered your standing on. And if you haven’t changed your mind on anything, perhaps that’s something to think about as well.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Customizing SSMS – Hiding the panels

    This is a short series on some customizations in SSMS to make it visually more appealing.

    As a presenter, I’ve learned how to change the way Management Studio (SSMS) looks to make it easier for people to see the screen on a projector. I had wrongly assumed that so many people knew many of these tricks, which is a poor attitude on my part. That should be especially apparent as I saw a presentation recently where the speaker didn’t know how to make things easier to see.

    Note that I often caution writers not to assume too much from the reader, and here I took it one step further, assuming some topics weren’t worth writing about.

    Here’s one that I heard asked recently: how do you hide the side panels in SSMS?

    The Default View

    Here’s what SSMS looks like for most people.

    ssms_a

    The Object Explorer takes up a good portion of the screen on the left. For some people, they may have this:

    ssms_b

    Or even this:

    ssms_c

    In the last two images, the Solution Explorer and Properties panes are on the right. If you have these panes open, you might find yourself squeezing a query into a small space in the middle. If your resolution is 1024×768 (standard for many projectors), you might get very little on the screen.

    Customizing

    There’s a way to clean things up quickly and easily. All of these panes have this item in their upper right sides:

    ssms_d

    If you click the middle, pin icon, the “Auto Hide” will be enabled, and the panes will slide to the side. They’ll still be there, but now they’ll be in a side bar, like the Object Explorer is below:

    ssms_e

    If I hover the mouse over the “Object Explorer” button on the side, it will appear, or I can click it.

    I can always use the “View” menu at the top as well (or a shortcut) to expose any of these panes. However when I’m presenting, or want to make a quick change, the “auto hide” feature works very well for me.

  • The Gambler

    I'll be speaking here. Come shake my hand if you can come and register with the code "Jones"
    I’ll be speaking here. Come shake my hand if you can come and register with the code “Jones”

    In April of this year, the SQL Intersection conference is coming to Las Vegas. I’m speaking, along with Grant Fritchey and many others. It’s a fun event, in a city with a huge variety of things to do in the evenings after a full day of SQL Server sessions. At night I tend to look for networking chances to met new people and catch up with friends at night, though there have been a few times a comedy show has enticed me away from my hotel. I like Las Vegas, though I’m not a gambler. Despite the fact that most people think of visitors looking for their chance to sit at a table with dice or cards, there are many of us that go for other activities.

    I was at in a session recently and heard a speaker recommend that the audience run DBCC checks regularly. That’s good advice, and it’s what I recommend in my sessions as well. A person in the audience raised their hand and politely disagreed, saying that they almost never run DBCC CHECKDB. This person found it to be a waste of resources since they’d never encountered corruption in their career, and hadn’t known anyone in over a decade that had experienced on a SQL Server system. This person asked the speaker how many times the speaker had seen corruption (five was the answer) and then said across thousands of days of backups, it just wasn’t worth the resources to run DBCC CHECDB.

    If you feel that way, then you’re a gambler. You are accepting a higher level of risk than I do, and higher than I recommend. Consistency checks are designed to help us catch corruption. Since we never know when it will occur, we want to detect is ASAP so that we avoid, or at least minimize, data loss. If you run those checks and never experience corruption, those checks are insurance payments you’ve made and never needed to file a claim. However if you don’t run those checks, and experience corruption, you’ve placed a bet you’ve lost. Whether or not that cleans you out depends on the data loss your organization experiences and their tolerance for that loss. I’d seriously consider this a career limiting, or employment terminating, event, especially if the best practice recommendation from Microsoft and many experts is to run DBCC checks.

    I don’t recommend skipping your DBCC checks, but if that’s how you feel, think about coming to SQL Intersection (register with the code “Jones” to support me). You might enjoy that gaming tables at night, and I know the other speakers and myself would welcome the chance to change your mind about skipping DBCC checks during the day.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.