Voice of the DBA

Tag: security

  • Security Sadness

    I got this offer in email today.

    security_a

    My wife likes the X-Men, I’m not traveling, and this seemed like a good idea. I clicked and saw this page:

    security_b

    It’s from the Fandango domain, which I’ve used before. I have a United VISA. However I just can’t trust that I can actually enter this data in this form. It’s entirely possible this is a man in the middle attack, and that worries me.

    It’s sad that I can’t trust things like this anymore. It’s the same reason I don’t even talk to telemarketers anymore. Even when it’s a good cause, I just can’t trust any random “offer” that comes to me. I’m sure that I can’t even trust those offers I find myself, but it’s going to be a problem more and more. Whether it impacts commerce, I don’t know. Entirely too many people don’t care about security and $20 in free movie stuff would have them typing in their credit card number.

    I went to the United site and didn’t see the offer. I went to Fandango and same thing.

    Oh well, I guess I’ll buy my own tickets.

  • Secure Coding

    I was looking recently for some sort of guideline that would help me ensure that code was securely written. I stumbled upon the CERT standards, of which there are few, but one that seemed interesting was this one on Oracle and Java. I thought this first standard was a great explanation of good and bad code that you could use for this particular problem.

    I looked for something similar from Microsoft. I found this, which seems more like a random collection of links that don’t teach, or lead, anyone through the ideas of how to write better code.

    In some ways, Microsoft has produced a microcosm of the Internet. A mish mosh of lots of information with no organization applied at all.

  • The Danger of Algorithms

    There is a report that came out recently that shows how you can predict Social  Security numbers, an important piece of identity information in the US. This, according to this C|Net article, could result in massive fraud taking place if someone’s birthday is disclosed.

    So many sites want to get this piece of information from you, often to ping you on your birthday or give you some gift. I’ve always been wary, however, and usually put in April 1 instead of my real birthday. It makes for lots of birthday wishes on that day, but that’s OK. I appreciate the thoughts, even if they are a few months off.

    This does highlight the danger of using an algorithm to generate data. Unfortunately there are plenty of people out there that will maliciously find ways to mis-use data, and if they can guess how you generated the data, they can extrapolate that out to calculate what other data might exist in your system. I know most people that need to generate codes often don’t spend a lot of time ensuring they’ve picked a good method from a security point of view.

    The key here is to keep pieces of information somehow separate, to make it more difficult for a criminal of some sort to perform the extrapolation. That gets harder and harder to do, primarily because of the job many of us do. We gather data into SQL Server and other platforms, and make it easy to put this data together.

    As with many of the problems I see in today’s world, I don’t have a perfect solution to this problem. However I think that many of us handle data insecurely, often comparing actual values when a hash, or digital signature might work instead. I know some of that is because we don’t have great tools for working with digital signatures, but also because it’s a complex process.

    Credit card companies, banks, and other institutions often have complex rules for how they handle and process data. I think this more of their secure methods of handling data should be published and taught so that other companies can better learn how to build more secure applications.

    Steve Jones

  • Good Practices for Software Development

    Would you post your password on a wall in your office? Of course not, because other employees, the cleaning crew, even guests walking around your office would be able to access your system with your account. When I read Brian Kelly’s post on passwords in files, that’s what I thought of. Sticking credentials in a file, where they’re subject to any kind of search, is a bad idea.

    However this happens all the time. Combine this with a few other “common practices” like using sa to connect to a database and building dynamic SQL, and you might as well just set blank passwords and invite someone to have fun with your database. It’s sad that we continue to see these types of software development practices in 2014, and especially poor to see them from companies that sell software.

    There is so much information out there on building software that is of higher quality and is much more secure. However all too often I find developers just aren’t implementing these practices. There are probably a myriad of reasons why, and I wish we had more ways to better train people, disseminate the information, and enforce it’s use.

    Ultimately we can only do what we can. However I’d encourage those of you that see poor practices taking place to have a word with the developer (internally), or send a note to the vendor. If it’s more important to make a few more dollars than implement better practices, I’d encourage you to publicly call some attention to the matter. Maybe a little exposure to the dark side of software development will pressure managers to require more secure work over time.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.