LANGSEC: Language-theoretic Security

Wow.  Just wow.  See "LANGSEC explained in a few slogans".

Short, easy-to-grasp explanation of why complex protocols create new problems.

I'm happy with REST and the stack of stuff under it (HTTP, TCP/IP, etc.)

Once upon a time (2001), I invented by own version of a RESTful protocol outside HTTP.  That was cool.  Very simple, and very fast.  But relatively inflexible.  The syntax was more like FTP and SMTP; the semantics where mostly just CRUD rules and RESTful state transfers.

I was way too dumb to leverage HTTP methods and the genius of a URI.

Technology Refresh

I've been refurbishing an older project -- written in 2008.  Probably with Django 1.0.1.  Certainly with Python 2.5.

The Django 1.3 release has been around since March.  The change underscored the importance of technology refresh.

The best part was to delete code.  There were two significant reasons.

• The testserver command allowed me to eliminate a bunch of low-value test harness.   Without this command, we had to create our own test database, start a server, run integration tests, and then kill the server.  With this command, we simply start and kill the server.
• The RESTful web services can be securely integrated into the main web application.  A simple piece of middleware can authenticate requests based on headers containing ForgeRock OpenAM tokens.  It may be that this was always a feature of Django, but over the last few years, we've figured out how to exploit it with simple middleware.

Few things are better than removing old code and replacing it with code written (and tested) by someone else.

In  addition to the deletes, we also rearranged some of the dependencies.  We had (incorrectly) thought of the Django project as somehow central or essential.  It turns out that a bunch of other Python libraries were actually core to the application.  The Django web presentation was just one of the sensible use cases.  A suite of command-line apps could also be built around the underlying libraries.

In addition to this cleanup, we also replaced the documentation with a new Sphinx project.  The project originally used Epydoc markup.  This meant that every single docstring had to be rewritten to use RST markup.  The upside of this is that we corrected numerous errors.

There Was Pain

This wasn't without some pain.  

Was the cost worth the effort?  That's the real question here.

I think that many IT managers adopt a silly "If it ain't broke, don't fix it" policy that focuses on short-term cost and short-term value.  It ignores long-term accrual from even tiny short-term cost savings.

Here's are two important lessons.  

• Money saved today is saved forever.
• Savings accrue.  Forever.

It's important to avoid short-term thinking about cost and benefit.

Color Schemes

I worked with this a few years ago to tweak up some web pages.

http://colorschemedesigner.com/

I just rediscovered it.  It's a cool toy.  You get some colors that all "go" together.  If you're careful with your .CSS definitions, you give people this page and let them fuss around until their positively silly with color palettes.

Good Summary of Bad Security Assumptions

This isn't the OWASP Top 10 list, but it's still very handy.

Top 10 Dumb Computer Security Notions.

I'm particularly fond of the "security can't be perfect; since it can't be perfect, why bother?" approach.

One other notion that amuses me is the silliness of changing a password every 90 days.  The argument is that "it's harder to hit a moving target".  That's obviously false.  A good rainbow table and a bad password without salt can be broken in about half an hour.  There's no "moving target" here.  At 30 minutes to crack a password, the only way the target can appear to move is making every password a 1-time-only password based on some kind of external source (like a token generator.)

The need for ping

Years ago, when designing an interface to a vendor's web services, I did the following.  This isn't a genius move, but it's worth emphasizing how important it is.  And what's most important isn't technical.

1. I built a simple spike solution to access their service.
2. I morphed this into a "sanity check" to be sure that their service really was working.  Mostly, I cleaned up the code so that it was testable and deliverable without embarrassment.
3. I morphed this into a "diagnostic tool" to bypass the higher-levels of the application and simply access the vendor (and optionally dump the results) to help determine what wasn't work.  This involved adding the dump option to the sanity check and renaming the command-line application.
4. I morphed this into a "credentials check and diagnostic tool".  This was -- ahem -- merely taking the hard-wired credentials out of the application.  Yes.  The first versions had hard-wired credentials.

That brings us to the version in use today.  The "vendor ping" application.

The default behavior is a credentials check.

One optional behavior is to dump the interface details.

Another optional behavior is to allow selection among a small number of simple interactions just to be sure things are working.

Unplanned Work

What's important here isn't that I did all this.  What's important is that the deliverables, user stories and project plans didn't include this little nugget of high-value goodness.

It gets run fairly frequently in crunch situations.  The actor in the story ("As system admin...") is rarely considered as a first-class user of the application.  Yet, the admin is a first-class user, and needs to have proper user stories for confirming that the application is working properly.

Statically Typed Language Nonsense

Read this: "Here Comes Functional Programming" by Larry O'Brien in SD Times.

people who should know better continue to assert that statically typed languages are "safer, because the compiler can catch errors that otherwise wouldn't show up until runtime." While it's true a statically typed language can detect that you've assigned a string to a double without running your code, no type system is so strict that it can substitute for a test suite, and if you have a test suite, type-assignment errors are discovered and precisely diagnosed with little difficulty.

Thank you.   A language like Python, which lacks static type declarations for variables, is not evil or an accident waiting to happen.

The article is about functional languages.  But the static declaration statement is universally true.

I'm Confused by this Marketing Ploy

Got this a few weeks back.

My job is to persuade bloggers to link to our site. 

I really love my job! We have a friendly team and good management, but unfortunately I have no idea how to convince a blogger to link to us, I'm afraid I might lose my job because of it :( 

And that is why, instead of sending letters to thousands of different blogs, I am reading yours.

Couldn't parse it.

It seems to be a calculated Pity Ploy.  "I'm afraid I might lose my job...I am reading your [blog]."

The product seemed cool enough.  The pitch, however, was too sketchy for me.