afongen

I hesitated to write this, but the question has come up several times recently, so here you go anyway.

I don’t like secret questions for password retrieval. You’ve seen these, I’m sure: when you create an account somewhere, you’re presented with a list of questions to choose from and answer. The idea is that if you lose your password, if you answer the question correctly you can reset your password. Classic questions include mother’s maiden name, pet’s name, favorite song, that sort of thing.

You see secret questions because they are cheap and easy. If a customer can self-assert and reset their own password without getting someone on the phone — or if it’s a web site for which you’ll never get any help anyway — that’s a Good Thing, right? The downside is that secret questions reduce the security of passwords. (Passwords themselves are broken, as even the New York Times reports, but that’s a story for another day.)

When passwords can be retrieved or reset as the result of answering “secret” questions, answers to those questions are essentially passwords themselves. Weak ones.

Let me say that again, because it’s important and not everyone pays attention the first time. Answers to “secret” questions are weak backup passwords.

Answers are not held to the same password policies that the actual passwords are. Many systems nowadays make you jump through all sorts of hoops to have a certain complexity to your password, often enforcing a mix of letters, numbers, and punctuation. This is important to prevent dictionary attacks, a brute-force technique in which attackers cycle through hundreds of thousands of possible words, plucked from dictionaries (a word like “snowball” or name like “Voldemort” won’t stand up long to attack). It is trivial and fast to crack most passwords.

Secret questions can often be answered in a single word, a word that would violate the password complexity policy but that is still allowed as the backup password.

Answers to secret questions are often trivially discoverable. It would not take a determined attacker long to find my mother’s maiden name, my home town, or the name of any of my pets. Not only that: they’re dictionary words. Dictionary words are weak passwords.

Questions may have a limited number of answers.

• Favorite color? Chances are good that most people will answer from just a handful of possibilities: blue, red, green, yellow…
• Year of birth? It’s a safe bet that there will be fewer than 80 possible answers, probably quite a bit fewer.
• Home town? Lots of people come from big cities like New York and Beijing.

When users can supply their own questions, chances are pretty good that they’ll choose poor questions, again with trivially discoverable answers. People are not good at choosing security questions. Not long ago I once walked through the office and asked a dozen coworkers what their security questions would be. The most common response? “Last four digits of my SSN.”

Four digits. I rest my case. You can argue that people could have lied, and I hope that some of them did. But seriously. Four digits.

You should also be concerned that if you allow users to create their own questions, you will inadvertently end up storing private or sensitive data (say, ahem, SSNs), which may violate your privacy policy.

The situation can be improved somewhat by well-chosen questions — NOT letting users choose their own — and perhaps using multiple questions, although something about that makes me uneasy. It’s far better to use something in addition to secret questions, such as demonstrated control of a resource: email, a cell phone, smart card, or fingerprint.

Password retrieval systems are often poorly designed and easily subverted. “Secret” questions are just one example. I have rarely encountered a password retrieval systems that lock accounts for repeated failed attempts in the same way that repeated failed logins do. Passwords are sent in cleartext emails, which is not just a problem by itself but also suggests that the passwords are stored in cleartext. Considering that we too often rely on just a password for authentication — a situation that has got to change — we should do better.

The Minneapolis/Saint Paul OWASP chapter is organizing two events that I want to tell you about.

First, Jeremiah Grossman is speaking at the September 9 chapter meeting. This will be a reprise of his talk at Black Hat, “Get Rich or Die Trying”:

Forget Cross-Site Scripting. Forget SQL Injection. If you want to make some serious cash on the Web silently and surreptitiously, you don’t need them. You also don’t need noisy scanners, sophisticated proxies, 0-days, or ninja level reverse engineering skills — all you need is a Web browser, a clue on what to look for, and a few black hat tricks. Generating affiliate advertising revenue from the Website traffic of others, trade stock using corporation information passively gleaned, inhibit the online purchase of sought after items creating artificial scarcity, and so much more. Activities not technically illegal, only violating terms of service.

You may have heard these referred to as business logic flaws, but that name really doesn’t do them justice. It sounds so academic and benign in that context when the truth is anything but. These are not the same ol’ Web hacker attack techniques everyone is familiar with, but the one staring you in the face and missed because gaming a system and making money this way couldn’t be that simple. Plus IDS can’t detect them and Web application firewalls can’t black them. If fact, these types of attacks are so hard to detect (if anyone is actually trying) we aren’t even sure how widespread their use actually is. Time to pull back the cover and expose what’s possible.

Slides of the talk are posted on his blog. Grossman does good presentations. This promises to be excellent.

Second, on October 21, we’re planning a one-day conference at the Saint Paul campus of the University of Minnesota. Details are still being worked out, but speakers include Jeff Williams (CEO of Aspect Security and an OWASP founder), Brian Chess (Fortify Software), and Richard Stallman.

Yes, Richard Stallman. I didn’t expect that! Looking forward to it. (No, that link doesn’t explain who he is. It’s just damn funny.)

Registration for the October conference hasn’t opened yet, but from what I understand we’re going to be able to make it free of charge. Wow.

I’ll let you know when there’s more information.

When last I wrote, I was busy working on a few talks. They went reasonably well.

MinneWebCon was a lot of fun, an engaging, upbeat conference. There were almost 250 attendees, about two-thirds of which were from the University of Minnesota, which put on the conference. Eric Meyer delivered a keynote in which he discussed craftsmanship in the web professional. How very relevant. Amy Kristin Sanders’s midday keynote offered useful insights about internet law that I cannot do justice to. In Mark Heiman’s enchantingly engaging talk about the search for a social networking tool for Carleton College alumni, I learned about Elgg, an open source social networking platform that looks pretty damn good. I’ll have to take a closer look.

The smartest bit of scheduling was to put unconference sessions immediately after lunch. Rather than nodding off on a full stomach, we got engaged in animated discussion, keeping energy high for the afternoon. Brilliant. The social networking session largely highlighted Twitter, which fit in well with the active back-channel Twitter chatter going on. Tony Thomas wrote a little about that.

My own presentation on JavaScript went almost as well as I hoped, although I ended up not being able to touch on Ajax except immediately afterward in a quick response to a question as I was unplugging from the projector. My emphasis was on taking functional pages and layering helpful behaviors onto them with unobtrusive JavaScript. Video will be available at some point, and I’ll be making my presentation notes available here (and there) soon.

And by the way: in case you didn’t know, jQuery is fantastic.

Many thanks to the MinnWebCon organizers for putting on a great conference and for allowing me to participate. I’m looking forward to next year.

Unfortunately, I was having so much fun preparing for my MinneWebCon talk that I gave short shrift to prepping for the two presentations I had scheduled at the MnSCU IT conference this past week. Thankfully I deliberately chose topics on which I could speak extemporaneously if need be. They turned out okay, but (as always) not as good as I had hoped. My first session explored the limits we’re bumping into with Ajax, especially user interface challenges, nontrivial client-server data communication problems, and the fallacies of distributed computing — setting the stage for the emergence of rich internet application technologies like Flex, AIR, and Silverlight. None of these technologies actually solve the problems, except making it easier to create better-looking UIs, but they should be watched closely. Hell, I’d use Flex in a heartbeat for certain things like, oh, an ERP.

I also spent a few minutes pointing toward all the activity going on around programming languages, concurrency, and flexible approaches to databases (non-relational, sharding, etc.), all related to rising expectations of what software should be able to do and how quickly we should be able to create said software. I talk about this stuff all the time, but hardly anyone seems to believe me. I hope that I at least planted a seed or two that will bear fruit in future discussion, and was heartened upon my return from the conference to see Tim Bray take it up:

Near as I can tell, we’re simultaneously at inflection points in programming languages and databases and network programming and processor architectures and Web development and IT business models and desktop environments. Did I miss anything? What’s bigger news is that we might be inflection-point mode pretty steadily for the next few years.

I don’t know whether I’ll put together notes. I suppose I ought to.

I was a little worried about the session on software security principles, since I had completely changed course on what I wanted to do the night before, but it turned out to go quite well. I wanted to start a discussion, examining common software development scenarios where I often find vulnerabilities, letting the group identify security principles that should guide development. WIth the help of a few security-minded individuals and a lot of people not afraid to put themselves out there even when they weren’t sure of themselves, we did just that. It was a good, active conversation. I was a concerned that one guy who brought up a quite valid point — that by moving our ERP from Win32 client-server to a web application, we’ve increased exposure and risk — was discouraged by the response. I talked with him today, though, and found that he wasn’t at all discouraged and that he had learned what I wanted people to learn:

• the threat is no longer amateur;
• software is rarely designed with security in mind, and that’s where the attacks are taking place;
• there are core principles that should help guide software design and development, such as not trusting input, using least privilege, and so on.

For people like him for whom this is all new, next time I will prepare handouts. If you’re looking for a preview or something to use now, I suggest you start with the excellent resources from the Microsoft patterns and practices group, including Guidance Share. It is not all Microsoft-specific, and there are some real treasures. For a quick run-down of security principles, see this blog entry by J.D. Meier, which lays them out nicely against Microsoft’s security frame.

To my mind, the highlight of the conference was Mike Janke‘s whirlwind tour of the MnSCU network and data centers. We really need to see more of that. Watching his presentation leaves no question of the scale and complexity of the problems of doing IT for an organization the size of ours, and the tremendous job that Mike and his team have done.

The real conference is of course not the sessions but the connections made with people there. Many good conversations were had, but I still didn’t connect with everyone I had hoped to. Folks, you know who you are. Let’s not wait until next year, okay?

Whew! My conference season is pretty much over, so excuse me while I go tackle that growing stack of books.

Earlier this year David Litchfield published a paper about what he calls lateral SQL injection (PDF), in which he demonstrates how to exploit PL/SQL procedures that don’t take user input. It’s a rather clever bit of work that shows that data types such as DATE and NUMBER, normally considered safe from injection, are in fact not.

But what caught my attention was his inspiration:

Whilst watching an episode of ‘Bones,’ something happened in it that made me think of not accepting something believed to be true, i.e., in this case that it’s not possible to SQL inject via DATE or NUMBER data types.

I love it.

I’m busy preparing for three talks that I’ll be giving in April.

The first will be at MinneWebCon, a web conference at the University of Minnesota.This is their first time putting on this conference, and even were I not speaking at it I would probably attend. The sessions on user experience, social networking, and online video look interesting, and I read today that there will be unconference sessions, too. My talk will be an introduction to JavaScript. The MinneWebCon organizers don’t expect the audience to be hardcore developers — a glance at the sessions makes that clear — so I’m keeping it basic but still trying to make it useful and get across important ideas. I always try to stress a few concepts whenever I talk about JavaScript:

• The importance of unobtrusive JavaScript — playing nicely with web standards and writing JavaScript that injects itself into a page to layer on behavior.
• JavaScript is not a toy language. It’s frequently dismissed as a cute little trinket, but its importance in web apps nowadays argues that although it has its warts, it has a certain quiet strength. I deal with a lot of Java developers who eschew JavaScript as “nothing like Java” but who then make the mistake of writing JavaScript code as if it were Java Lite. JavaScript is not a less powerful Java: it is best used on its own terms.
• Security. JavaScript is so ubiquitous and it is so easy to make security mistakes, I would be remiss not to discuss security. Especially since I’ll be bringing in a little Ajax.

We’ll be looking at JavaScript from the perspective of introducing basic enhancements to page behavior, illustrating those three concepts along the way. In an hour can’t get too deeply into JavaScript syntax, especially for non-programmers, but I will be showing how to leverage libraries, especially jQuery.

The next two sessions will be at the annual IT conference for Minnesota State Colleges and Universities. (There’s not a good link right now, sigh.) This is a gathering of IT staff from our colleges across the state, staff development, networking, and so on.

The first session is on software security principles. In the years that I’ve been working with developers on software security — coaching, training, giving talks at conferences like this — I’ve focused a lot on common flaws and vulnerabilities: how to test for them, how to prevent them through early design analysis and development techniques. It’s become clear, though, that there’s something fundamental missing. Understanding of vulnerabilities and their exploits is incomplete unless a developer also understands basic principles of software security. Until a developer — or architect, or project manager — has a foundation in the core principles that guide secure software development, they are likely to make the same sorts of mistakes that lead to security problems, even if specific vulnerabilities are planned for.

Basically, I don’t want to keep finding myself in arguments about whether or not it’s worth doing input validation. So I’ll cover principles like “input is evil,” least privilege, defense in depth, secure failure, that sort of thing. Since an hour of theoretical mumbo-jumbo isn’t likely to do anything except put people to sleep, I’ll be sure to explore how these principles play out in the software development process, and how common vulnerabilities such as the OWASP Top Ten can be addressed by keeping the principles in mind.

Yeah, I get a little ambitious.

My second session at the MnSCU IT conference is called “Beyond Ajax.” When I first conceived of the talk, it was more along the lines of “Why Your Software Sucks.” (I had an angry few months, what can I say?) It then morphed into an exploration of rich internet application technologies starting to rise to the fore: Flex, AIR, Silverlight, even JavaFX. Then, thinking about the two sessions that I’ve outlined above, I realized that I didn’t have enough time to learn Flex and Silverlight well enough to do a kick-ass presentation. Besides, for an audience that for the most part is maybe just now getting into Ajax development, I need to develop more background of what’s driving the adoption of non-Ajax RIAs.

So instead, the talk will be about why creating a well-designed Ajax app has proven difficult or unsatisfying:

• We’re still stuck with the limitations of browser user interfaces.
• Writing cross-browser code is still hard.
• Creating compelling cross-browser UIs is even harder.
• Many developers don’t understand JavaScript like they should.
• Security has grown more complex.
• Ajax accessibility is still largely unknown and misunderstood.
• Although the client-side part of an app can now do more (and be more complex!), without a lot of work application workflows have not changed much and are still hampered by HTTP.
• Architecture of data flow between client and server is a significant challenge, often falling victim to the fallacies of distributed computing and resulting in a degraded user experience.
• There is a strong inclination to use Ajax to create non-browserlike experiences, often to the detriment of the user.

I don’t know yet whether I’ll bring mobile devices into the picture.

Into this setting come Flex, AIR, Silverlight, and so on. I can’t get too deeply into them, much as I’d like to. Still, the focus of the talk is on rich internet apps — mostly why, not so much how. Look for that next year. :)

I also hope to spend a few minutes (lightning talk style?) discussing parallel industry trends that will have impact on in RIA development in the near future: cloud computing, approaches to concurrency, non-relational data stores, and a panoply of new languages and platforms to address these concerns. This is all stuff that’s been rolling around in my head for the last year or two, and I’m tempted by a bit of self-indulgent examination of how it’s all connected.

Like I said: I get a little ambitious. That last bit is likely to get cut as not contributing to the core message.

So if you don’t hear from me for the next month or so, know that I am busy. But I am having fun.

Robert Hansen, aka RSnake, whom you might know from his insight on web application security over at ha.ckers.org or perhaps his book on cross-site scripting, will be speaking at our local OWASP chapter on Monday. It promises to be good.

Pre-registration is encouraged to give some idea of how many to expect — the venue for last month’s meeting had to be moved because so many people registered.

Update: Hansen appears on today’s Future Tense.

I have been eyeing Gary McGraw and Greg Hoglund’s new book, Exploiting Online Games, for a while now, probably since before it was published. Seems like a no-brainer considering my recent tinkering. But I haven’t bought the book, partly because I’m buying nothing new, partly because I’ve got a stack of other books to get through.

McGraw’s recent appearance on Phil Windley’s Technometria podcast has really got me itching to get this book. Not only do they discuss why criminal abuse of online games has been on the rise in recent years (there is so much money to be had!), but explains why one might care even if games hold no interest:

If you look at online games, they have architectures which are very similar to the ones everybody’s all excited about, with SOA, and Web 2.0, and Software as a Service, where you have sort of a fat client model connected to a central server. And the security lessons that we have to take from online games are *huge*. It turns out that the kinds of attacks, the kinds of problems, the kinds of mistakes that developers make, and the kinds of exploits that those can lead to are already present in the online game world, and so we can get a real peek into the future as far as SOA and Web 2.0 systems go now.

No, really. Please, please, pretty please with sugar on top.

I frequently run into problems that developers either can’t figure out or had no idea existed, problems that stem from fundamentally not understanding HTTP.

For example, every few weeks I find myself evangelizing the Post-Redirect-Get pattern. Simplified, it goes like this:

1. User submits form with POST (“buy this stuff!”).
2. Server processes form, sends redirect to the browser to go to the results page.
3. Browser requests results page with GET.
4. Server sends results page.

One trick in doing this is that if you want to display a message about the transaction in step 2 on the page in step 3 (“you bought the stuff!”), you need to temporarily stuff that message into session then remove it when you’re done. Rails makes this easy by introducing the Flash, but it’s becoming more common in other frameworks, too.

Simple enough, and it solves all sorts of problems that I won’t get into now. But I still run into conceptual difficulties:

• Maybe a developer thinks that the browser works directly with Java objects (or PHP, or C#…) and can just manipulate and share these with the server somehow in stateful way. Nope. HTTP is stateless, and your HTML form is just that: HTML.
• It could be that a developer believes that the message can be sent back to the browser in the response in step 2 and be somehow available after the browser gets the HTML page in step 4. Um, no. Not the way you’re thinking.

The nitpicky and clever among you will point out that with trickery and by misunderstanding or misconstruing what I’m saying, it’s possible to do those things. For instance, you could use Ajax and DWR to communicate “directly” with Java objects from browser-based JavaScript. True… but not the point. It’s still not like the browser is a Java client communicating over RMI. Nothing like it. There’s a reason I put “directly” in quotes.

But how about that second example? You could stuff a message in a cookie in the response, and re-use that cookie in the results page. Right? Well, yes. Very good of you to notice.

Dreaming up these workarounds implies that you understand HTTP at least well enough to know its limitations and its mechanics. I’m not talking about you, I’m talking about people who just do not conceptually understand an HTTP transaction. And it’s not just at work, it’s not just among Java programmers, I encounter these issues all over the place and on all sorts of platforms.

I can’t really blame the developers, at least the junior ones. The APIs that we work with nowadays to write web apps remove us from the nitty-gritty of HTTP, just as we are removed from the pain of TCP/IP programming. That might be a good thing, but it leaves us with a leaky abstraction.

So what? So I’ve got a little pet peeve of a pattern. Big deal. What else is HTTP gonna get you?

Unless you have even a basic understanding of HTTP, there will be whole classes of vulnerabilities and design flaws in your web applications. You’ll have insecure session management, for starters, and probably cross-site request forgery bugs. I frequently encounter inadequately restricted URLs because of a misled belief that if a link to a page/resource isn’t exposed, that no one can get there.

Note that I wrote design flaws. These are not just developer problems, code-level vulnerabilities. Poor session management often starts with poor architecture and design. Misunderstanding the basic protocol behind the web can contribute to design problems that manifest in broken code.

How do you learn HTTP? Google around. The third chapter from the out-of-print Web Client Programming with Perl is a good start. If you like paper, I highly recommend Chris Shiflett’s HTTP Developer’s Handbook.

Here’s the trick: it’s not hard! Spend just a few minutes to understand the basics of HTTP. You’ll be a better developer, and your apps will be better for it.

I’m going to No Fluff Just Stuff for the first time this weekend, Friday through ThursdaySunday. I’ve been looking forward to it awhile, as I hear mostly good things about these conferences. Looking over my planned itinerary, it’s clear that I’m a Neal Ford fanboy. :)

But here’s the thing. This Friday there’s a workshop on bioinformatics and entertainment computing at Metro State that looks like it’ll be great. Chris Melissinos, Sun’s Chief Gaming Officer, will be speaking there, as will Warren Sheaffer, a faculty member at Saint Paul College who’s been doing Good Things with virtual worlds and with teaching Java. Plus, bioinformatics is one of those fields that has just fascinated me since my days as a Perl hacker. Perl was (is?) a big language for data processing in bioinformatics.

Okay, yeah, back up a sec. Chief Gaming Officer at Sun. How damn cool is that? Please don’t be surprised that he has interesting things to say. If you’re confused about why Sun would be doing this, watch Chris’s interview with Scott McNealy.

If my employer hadn’t already sprung for NFJS, I’d go to that workshop. Sigh. It’s still a tough call. Looks like I’ll meet Chris and Warren tomorrow, which will help ease the pain somewhat.

But I’m not done. Oh no.

Gunnar Peterson and Brian Chess will be speaking together at a seminar in early November. Gunnar is known for his writing and presenting about web services and decentralized security, among other things (he introduced me to the idea of misuse cases), and I always enjoy seeing him speak. He’ll be one of the fine lineup at this year’s OWASP AppSec conference giving a two-day seminar on web services and XML security. Brian is founder of Fortify, a leader in the static analysis tools market for software security. Brian recently gave a good interview with the Java Posse. At the event in question, Gunnar will talk about security architecture and governance, and Brian’s topic will be static analysis. This will be a morning well spent, I figure.

However, on the same day, there’s a symposium at St. Cloud State University on Information Assurance, Network, and Software Security. I don’t know anyone who’s speaking or their work — a gap beween academia and industry? — but I am very glad to see this happening. I’d be going if I were not more sorely tempted elsewhere.

What to do, what to do…

This xkcd has left me rolling on the floor laughing:

Update: it hadn’t sunk in that I had a fixed-width design until the image of the comic was borked. It has now been resized, and I’m likely to go looking for another design.