Voice of the DBA

Category: Editorial

  • The Level of Security These Days

    Passwords aren’t going anywhere. While I would have thought there would be more advances by this time, and there are, the basic password is still required in many places, especially for resetting an account. Even those MFA places where I can click a notification or enter a code, I still sometimes need a password.

    That’s fine, and I think MFA is a good solution, but it doesn’t alleviate the need to have a strong password. Troy Hunt has written about this topic because we as a collective do a poor job of building passwords. Especially with regards to length. Some of that is poor app (and database) design where we unnecessarily limit password length. However, some of the issues are our fault, as we continue as a group to use poor habits and practices.

    There are many guidelines to use with passwords, one of which is the length. The length you should use keeps increasing because hardware power keeps growing. Because of new attacks and techniques, we ought to review what we think is strong on a periodic basis. My password manager defaulted to 8 characters when I started using it over 20 years ago. Since then I’ve increased that to 12, and now 15. I ask for mixed upper case, lower, and numbers, along with symbols. These are so random that every time I need to give one to my wife to enter in, she’s annoyed with the length and mix of keys that need to be pressed.

    I haven’t seen the brute force table from Hive Systems before, but I like the visual. It helps you determine how strong your password is with modern hardware. This is a similar graphic to the one I used in an encryption talk years ago, where it showed how much it would cost to rent compute power on AWS to brute force crack various algorithms. In case you were wondering, about 5 years ago you could crack a 512bit key on AWS for less than US$75.

    I like the graphic, and it shows that my 15 character passwords should be safe for years. This Friday, I’m wondering if you’re comfortable with your password lengths? Are they crack-able in less than a year? Take a look at the graphic and let us know.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The Right to Repair

    I’m a do-it-yourself (DIY) person in many ways. I work on equipment on the ranch, repair or improve things in the house, and often tackle electrical or mechanical tasks. I’ve replaced hydraulic hoses, changed oil, replaced brakes, changed outlets, wired up lights, and more. I keep a hand cleaning degreaser handy and use it regularly.

    I think many people who work in software development are the same way, and often I find they want to rebuild things themselves rather than adopt or improve what’s there. Many organizations have a fair amount of NIH Syndrome inside that results in money and resources spent on software that might be better used elsewhere. I think some of this is going away as current trends in software make use of APIs, OSS, and services to cobble together a workflow rather than just building something from scratch.

    However, that’s not always something we can do. In fact, we often can’t take apart commercial software and fix it, not even when it’s broken and in need of repair. That same philosophy is starting to pervade products in the real world, which is disappointing to me as someone that likes to be able to repair something I own.

    There is a good article on the right to repair over at Make magazine. In this case, the argument is that there are certain restrictions manufacturers put in place to limit the ability of individuals or third parties to repair products. In the physical world, I think this is a problem for actual devices, but it’s also becoming an issue as software pervades the operation of many physical devices. One of the higher-profile complaints has been with tractor service.

    I don’t know how we reconcile the right to repair and own something with the intellectual property rights of software. It is a thorny issue, and one that I am not sure of how I would want to frame the rights, but I do hope that we at least ensure that physical products people own can be repaired by individuals, including the ability to “reset” software as needed.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Is CosmosDB the One?

    The question asked of Keanu Reeves in the first Matrix by many of the characters is whether he is the one. THe one that can save the world, and make a difference in their war. It’s a fun movie, and one I’ve enjoyed many times. Keanu doesn’t really believe he’s that special until the end. That’s in contrast to the products that most vendors build. Most of the times I think developers, marketers, salespeople, or all three think that whatever they’ve recently released is the best thing ever.

    CosmosDB is mentioned in a piece as the potential one database to rule them all. The article talks about some of the basis and value that come from the platform, which Microsoft continues to push as the database that can store any kind of data and meet the needs of any application. Whether you believe that or not, I find many articles and blogs from developers that are experimenting and building systems on top of CosmosDB.

    I do think the consistency models for CosmosDB are interesting, and having a variety of these models across a distributed RDBMS table would be great. I’d love to be able to insert data into a table, have it not available as a live value until committed on other nodes, and avoid locking my table. I realize I’m asking for something that seems like a bit of magic, but I bet Microsoft could add this to the SQL Server relational engine.

    CosmosDB is very interesting to me, and it’s an item on my list that I want to learn more about. I think there are certainly domains of problems where CosmosDB would fit very well. If any of you are working with CosmosDB, I’d be interested in knowing why and how it fits for your particular environment.

    There was a quote in the article that I thought was interesting. A Microsoft Technical Fellow said, “No data is born relational. In the real world, nobody thinks in terms of schemas — they think graphs or maybe JSON document if you’re an IOT device…”

    That’s interesting. If I produce a JSON document, am I not thinking relational? Do I not expect that most strings, values or arrays will exist in most of the documents? Am I not thinking schema, even ragged schema, from the beginning? I’d think most data relational. It’s just not easy to get it into that format when you deal with many instances of data.

    Of course, dealing with many instances of data is hard for most humans. That’s why we built relational databases.

    Steve Jones

  • The Chief Data Officer

    I don’t know if I’d be a chief, but I am glad that more companies are recognizing that data is one of the most valuable assets in most companies and starting to hire Chief Data Officers (CDO) to manage governance and security projects, as well as oversee data quality and management. With Chief Information Officers (CIO) and Chief Technology Officers (CTO), it appears that technology is becoming a force in the executive ranks.

    Most of the companies I’ve worked for only had one chief-anything to do with technology. It seemed that anything to do with computing fell under that individual. Adding a CIO and, now, a CDO shows that there there is a complexity in working with computer systems. The infrastructure and architectures of systems are important, but how we capitalize on information is crucial. I see a CIO as more of a business role than a technology one.

    The CDO seems to be a specialist that owns the data and ensures that it is well cared for, protected, and more importantly, managed appropriately. That would include knowing what data we have, how it is classified, how data should be protected, when to dispose of it, and how to assess the risk of keeping data around. It seems like a mix of strategic and tactical areas that a CTO or CIO might be tempted to consider low priority issues.

    I think data is one of the most important assets in many companies. We are always searching for ways to better understand our environment and make decisions that improve the way our organization works. We depend on data, and these days data is often something we lean on heavily. We need to protect it, especially as more regulations appear all the time that require us to change how we use and handle data.

    I don’t know how many of you have a CDO in your organization, or how quickly this will become common. I do know that the growing importance of the functions of this role are impacting more and more people who deal with data. While they might feel like a pain to adjust to, the more that we pay attention to how data is handled, the better off we all will be.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.