Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

  • Hash Storage: Make Attackers Work

    So you hash your passwords? Good. Do you salt? That’s good. Do you use a strong hashing algorithm (PBKDF2/bcrypt/scrypt)? Great! But how do you store the hashes? What happens when you get hit with a SQL injection attack?

    I’m a big believer in defense in-depth – not that marketing garbage about stacking layers of blinky-light boxes, but using techniques to add extra work for an attacker. You might not be able to stop every attack, but the more work they have to do, the better the odds they won’t get everything they want.

    Read more…

  • OPSEC, The NSA, and You

    It’s been two weeks since news broke about the NSA collecting massive amounts of data from Verizon; and likely everybody else. There’s also PRISM – whatever the hell that is – it seems there’s no agreement on that, and I doubt there will be anytime soon. What really matters here though, is we have proof that people are watching – and if it’s happening in the US, it’s probably happening everywhere else.

    Read more…

  • Password Hashing: No Silver Bullets

    In the dark days of the web, if a service hashed your password instead of storing it in plain text, they were doing good. As sites were hacked, and credentials stolen, a silver bullet emerged: always hash and salt passwords when storing them. Many, many services were built with this design – LivingSocial is a great example. SHA1 hashing with a 40 byte salt – once upon a time, that was considered reasonable protection. Today, you’ll be blasted by industry insiders and the media for that.

    Read more…

  • First, Do No Harm: Developers & Bad APIs

    Primum non nocere (first, do no harm) – an iconic phrase in modern medicine, yet also applicable to many other fields. This is something I wish more people would think about, developers especially – and primarily when writing new APIs. In general, developers don’t have an impressive history with security – quite frankly, developers suck. Seeing as I consider myself a developer, that’s painful to admit.

    Chris Andrè Dale posted an interesting article some time ago that got me thinking: Why it’s easy being a hacker: A SQL injection case study – Chris pointed out the problems with educational material that developers are using, and just how bad the examples are. SQL injection is everywhere and very few examples encourage developers to do it the right way – for that matter, very few are telling developers that there is a right way. I’m sure we’ve all seen similar issues in other areas, not just for SQL injection.

    Read more…

  • Piracy is not Theft

    For many years now groups like the MPAA and RIAA have tried to convince the public that piracy (that is, copyright infringement) is theft – and many people have come to believe this, but it’s not true. In reality, copyright infringement is far more analogous to trespassing than it is to theft in its core concepts – and even moreso in the digital world.

    To make it clear, I am looking at this from a largely historical perspective, looking at the origins of copyright and how it was intended to be used. This gives us a better view than the current laws that have been greatly influenced and complicated by politics and money from those that have a vested interest in maximizing copyright protections and broadening its definitions.

    Read more…

  • You can’t fix stupid…

    For those outside of the IT field, developers are looked at as miracle workers – through us, business leaders think anything is possible (and they often see no reason why we can’t work our latest miracle by the next morning). In reality though, we do work miracles; we save companies vast amounts of money every year through increased worker efficiency and automation, we enable new lines of business that wouldn’t be possible otherwise, and reduce energy costs because we keep the office lights turned off. Well, that’s more or less how they see us.

    Read more…

  • What’s your Code Legacy?

    When you move on to your next challenge how will those that inherit your code think of you? Noble or notorious, innovator or insane? This is a question that all developers should ask themselves frequently; though too few ever do. You should always write with the assumption that someday a new developer will take over your code, and they will question every decision and assumption you’ve made. When this happens, what will they think of you?

    Read more…

  • I Love My Job

    I love what I do, and I work with a great team. While it’s still far from perfect; I can say that I do love my job. For the last couple weeks though, I’ve had to remind myself of this several times. I’m sure we’ve all done it, in this industry it’s hard to avoid. You read an email or receive a phone call and repeat the mantra “I love my job, I love my job, I love my job.”

    Read more…

  • What It Takes To Be A Great Developer

    Recently a programmer I know decided that it was time for a career change, leaving the IT field entirely. This gave me cause to think; what does it take to be a great developer. Many people go through school believing they have what it takes, only to receive a rude awaking once they enter the real world.

    Before I go on, I think it’s important to define what I mean by developer, and the differences between a developer and a programmer. Here are a few key aspects that every great developer must possess:

    Read more…

  • Blog Traffic: Another View

    There are hundreds of guides on how to get more traffic directed to your blog, and most are wrong. Seth Godin recently posted on this topic, and I have to disagree with most of his points. While there are a few basically good ideas, there are many more that I just don’t see holding up.

    Here’s what I look for in the blogs I visit:

    • Writer is an expert in the field. If the writer seems to have only a passing knowledge of the subject, I typically don’t return.
    • Articles are of a reasonable length. If the articles are too short they don’t contain enough information to be of use, on the other hand if they are too long, they require too much of a time investment. I’ve found that 600-1,000 words typically works out well for most items.
    • Don’t write about things nobody cares about. Many people are tempted to write about things that nobody else cares about, if it won’t benefit the bulk of your readers, then it’s probably not worth writing about.
    • Keep to a single, basic topic. I look for blogs that follow topics I’m interested in, the further it strays from what I care about; the less likely I’ll come back. For me, I care about technology, not the writer’s local news, the more news posts, the less the odds of me coming back.
    • Keep is site simple and useful. If the site is too complex, it distracts from the quality of the work being published. The site should have a simple theme and not be overload with useless links or icons.
    • Be transparent. I like blogs were the writer exposes a bit of herself, don’t be afraid to post your name or who you work for. The more information authors posts about themselves the more credibility they have.
    • The site can’t be an ad-farm. I’m not a fan of ads, but I understand high traffic sites are expensive to run. If the site looks like its only purpose is making money from ads, I won’t stick around. In most cases, if there are any banner ads, or more than two text ads, I’ll probably lose interest. Ad locations and colors should be carefully selected, if done properly, they add value, if done carelessly, they will kill reader loyalty.

    This is by no means a formula to get millions of hits, just my view on what I look for, and the rules I try to follow. Each blog is different, and the readers of the topic you are writing about will determine what works and what doesn’t. Just try to make sure you’re writing about what people care about.

    Read more…