Voice of the DBA

Category: Editorial

  • 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.

  • 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.

  • Resetting DMVs

    I'd prefer more control on when I reset DMV data.
    I’d prefer more control on when I reset DMV data.

    Recently I was working on an indexing presentation and looking for missing, duplicate, and unused indexes. As I set up demos to show the effects of indexing, I was constantly adding and deleting objects, and even resetting the DMVs to show statistics by starting the instance. The documentation for some DMVs, like sys.dm_db_index_usage_stats include a note that the counters are initialized to zero when the instance is restarted. If a database is taken offline, or detached, all rows referencing the database are removed.

    That got me thinking. Why is this data removed? I’m sure some of the data is stored in memory and automatically reset, but is this the best way to handle this data? Wouldn’t it be better to persist this data and allow the DBA to reset values when they were ready? I know we can store this data in a table periodically now, but I think keeping this inside the system views would make sense as an option in SQL Server. When we shut down a database, persist this data inside the database. That would be closer to my vision of self-describing databases, which contain all their own metadata.

    I know there might be performance impacts to persisting this information, but I can also see benefits, especially when you might have system crashes or problems. Being able to recover the information from DMVs, even incomplete information, brings us closer to a robust, flight-recorder kind of system that monitors itself and allows administrators to review information that might help them discover the causes of any issues.

    I don’t think that every piece of data needs to be guaranteed to be written to the DMVs, or that the system should slow down to do so, but give the DBAs some control here. If we have the need for more extensive logging, or we want to retain whatever information we can, allow it to persist in the DMVs, or at least make snapshots of DMV data easy to take and store. It’s another form of logging that I’d appreciate having available from the platform.

    Steve Jones

    The Voice of the DBA Podcasts

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