Voice of the DBA

Tag: security

  • 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

  • Data We Don’t Want

    Filldisk.com might do this to your hard drive.
    Filldisk.com might do this to your hard drive.

    Don’t visit the FillDisk.com site, which I ran across a link to froman Arts Technica article that talks about a flaw in web browsers. It’s possible a security flaw, possibly an availability flaw as well. Apparently the new HTML specification allows for sites to use the Web Storage Standard to keep data on your hard disk. There is a limit in most browsers for how much data you can store per domain, but the FillDisk site uses sub domains to put random junk on your drive. The author of the site built this as a proof of concept and was able to add 1GB of data to an SSD on a laptop every 16 seconds.

    That’s a denial of service type attack that I hadn’t expected, but it is an interesting attack vector. I wouldn’t expect this to impact servers, but if servers are consuming web services, and using controls based on browsers, there is the possibility this type of attack might affect them. I’d hope this were limited to web servers and not impact database servers, but it’s certainly a concern if you have processes running on your database server that might retrieve data from a remote source.

    This makes me want to re-architect the way we build data driven application in the future, to prevent this type of vandalism. Maybe building an application level firewall that proxies all access to a database server. The idea of application servers was very popular a decade ago, but it seems few systems actually implemented this type of architecture. Perhaps this is because the web server/database server pairing is such an easy paradigm to build for most developers.

    Frameworks that allowed separation of the application through a middle layer could allow for caching of data in addition to more security. That could increase performance and scalability as the database wouldn’t be the single bottleneck for all requests.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Data Loss

    This piece was originally published in Database Weekly.

    Are SSDs less reliable?
    Are SSDs less reliable?

    Two words that no database administrator ever wants to put together are “data” and loss”. We go to great efforts to ensure that our SQL Server data is protected, backed up, available on alternate systems, even replicated to remote machines. Our goal is always to have zero data loss in all situations, even in those situations where we cannot prevent downtime from occurring.

    This past week an article at InfoWorld caught me eye with the phrase “solid-state drives suffer data loss” in the subtitle. The article is written about a study from HP Labs and Ohio State University that studied the effects of power loss on various SSDs. Using a number of “enterprise quality” SSDs from various manufacturers, the authors of the study cut power to the drives while they were in use, a scenario that I’d expect would happen periodically to systems. We reboot all kinds of systems at times without shutting them down at times, for a variety of reasons. I’d expect that file systems and low level software would properly handle these situations in a manner similar to SQL Server, with some sort of recovery running when power was reapplied.

    In the study, there were six potential failure types, and of the fifteen manufacturers whose drives were used, five of these failures occurred. The susceptibility of various kinds of corruption to power faults led the authors to conclude that systems with critical data should not use SSDs, test them thoroughly since they were not aware of ways to design a storage system to account for these potential issues. They did not say that SSDs were more unreliable than hard drives, but in this specific type of disaster, unexpected power loss, there could be problems.

    We can design around these issues somewhat with redundant UPSes, battery backing of SSD cards and more, but disasters in the form of an accident can occur. I’ve seen two occasions where large data centers lost power because of maintenance work on power distribution units resulted in improper fail overs. The more complex our system design becomes, and the more we use SSDs in databases, the more likely for some failure or corruption to occur.

    I wouldn’t panic and remove SSDs from systems, but I would ensure that any disaster recovery processes and procedures I had were up to date and working. You never know when you will need to recover from hardware issues on a primary system and have to restore on completely separate hardware. Advance preparations and practice are the only way to ensure you can successfully recover when the need arises.

    Steve Jones

  • The Group Account

    We want to avoid anonymity as well as too rigid security. Delegation is something we need in all our systems.
    We want to avoid anonymity as well as too rigid security. Delegation is something we need in all our systems.

    Managing security for groups, allowing access is selective ways to different individuals is hard. However it’s also something that many DBAs do on a regular basis. We deal with the challenges of row level security and tying particular pieces of data to particular individuals, groups, or other pieces of data. We work to ensure security and systems are flexible, allowing for disparate requirements to be managed with rights, schemas, and other mechanisms. And many of us do it well.

    I was reminded of the hard work we do with security when I read this piece on family accounts and the lack of support from Amazon and Apple. There are any number of comments and criticisms of the idea from people that ecosystems are bad ideas, or supporters of this idea have trust issues. Those are valid criticisms of the process, but that doesn’t change the fact that as our digital world has grown more closely linked, and many of us do want ways to share some of our digital assets with others, while retaining our privacy.

    This isn’t just a family concern, as many vendors don’t manage customer accounts well with all kinds of software. I’ve encountered many situations where an employee registers software under their email account and subsequently leaves for a new job. Finding licenses or being notified of patches becomes a problem, especially when the new administrator is often searching for information in some sort of disaster situation.

    I don’t have a great solution, but I do know that we want the ability to share assets, in much the same we could lend a book or wrench, or car to someone else in the physical world. At some point our cars, other secure application software, maybe even our databases will be authenticated in more secure ways. The future digital software that doesn’t allow for the re-assignment or information or rights to other individuals in an easy and secure manner will fail us.

    Steve Jones

    The Voice of the DBA Podcasts

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