Terse Systems

Remember Me Cookies for Play 2.0

| Comments

I’ve been working with Play 2.0 for a while now, and in many ways it’s the ideal web framework for me: it’s a light framework that gets a request, puts together a result (either at once or in chunks using an iteree pattern), and provides some HTML templates and form processors for ease of use. It lets you change code and templates while the server is running, and gives you an asset pipeline for compressing LESS and Coffeescript into minified CSS and Javascript out of the box.

That being said, it’s a new web framework, and the biggest issue right now is all the boring infrastructure that goes on top of it to make a framework deal with authentication, authorization, and even boring things like resetting a password.

On the Java side, Yvonnick Esnault has a good starter application (disclaimer; I contributed some code), or you can use Play Authenticate.

On the Scala side, play20-auth is a good starting point for an authentication system. However, it didn’t do token based authentication, aka “Remember Me” cookies. Adding this feature turns out to be tricky if you’re new to Scala, because extending the request pipeline in Play 2.0 Scala requires that you know a functional style of programming called “action composition”.

So here’s a boilerplate project play20-rememberme that does authentication with remember me functionality (although it doesn’t have the password reset or confirm features added to Play20StartApp).

UPDATE: Now works with Play 2.1.

The User Illusion

| Comments

Slides from the May 17th Five Minutes of Fame. This one is on consciousness and a book called The User Illusion. I read the book and thought it interesting, but it was only after reading Blindsight and following Peter Watts’s blog that it clicked as something that happened outside of science experiments.

That, and I’d really been hankering for a good science talk. There’s nothing quite like science; even when it comes to something as wishy-washy as consciousness, it can still give you surprising answers.

And video!

The short version of the slides:

When you see, you see what’s already been processed and filtered. Illusions are when the system doesn’t work; you don’t see when it does work. In other words, we see “car accident” as presented to our consciousness — we don’t consciously put it together from our visual input. I’ll spare you the customary link to the “You wouldn’t know if a Gorilla showed up” study, but it’s fairly clear the brain only passes on the Cliff Notes version to the executive layer.

Consciousness lags well behind. When scientists measure the movement of a finger, the electrical potential rises a full second before the finger moves. But we report making the decision to move half a second before the finger moves (Libet). We become aware of making the decision after it’s already happened.

Some scientists conjecture that consciousness may simply be unnecessary (Rosenthal). Others think that consciousness may be a result of conflicting subconscious systems (Morsella, Hofstader, Metzinger), and the Watts commentary points out that consciousness seems to be strongly associated with inner conflict and/or pain, although I’m not spoiling his punchline.

Despite what Heph says, I don’t think the talk is depressing. When you think about consciousness, you assume that it’s a good thing, but realistically we’re far happier and productive in flow, without that nagging voice inside our heads. Rather than life being suffering, suffering itself is the act of consciousness.

The talk itself went down well, with the coveted seal of approval. The 5MoF itself was surprisingly wide ranging — Eclair Bandersnatch showed up in a barbie mask and wig to talk about art, Danny O’Brien gave a talk on The Cosmopolitan Anarchist and recapped the news on Byron Sonne, Liz Henry read poetry from her new book, and Josh Juran presented FORGE, a GUI based on manipulating what appeared to be symbolic files on the filesystem — a programming paradigm that apparently came from Plan 9 and hurts my brain every time I think about it.

We’re doing the same thing next month, and I’ll probably be talking about Transcranial Direct Current Stimulation (if I’m not, y’know, drooling in a corner). So! If you have a thought that’s been burning a hole in some mental sidepocket, you should sign up.


| Comments

New Five Minutes of Fame presentation. This one’s a presentation about a little known book called Systemantics (a.k.a. The Systems Bible).

This is a hard book to get hold of, but a worthwhile one. Systemantics doesn’t make a lot of sense without the context of Systems Theory, which is responsible for the word “cybernetics” and a whole bunch else, mostly talking about systems in the context of the complex feedback loop of a nuclear power plant.

Systemantics is a little bit different: it talks about the feedback loop involved in organizations, and how the system has an independent life (and will to live) outside of any of its participants. It’s a book about how systems actually behave, and how what an observer may consider to be a bug looks like appropriate behavior to the system. It’s about the system as you know it at 2 am, the system complete unto itself in all its ineffable complexity.

That being said, much of it is applicable to complex computer systems as well — in fact I’d say that Systems Theory is far more applicable to my day job than most CS Theory is, and if there’s ever going to be a Software Engineering curriculum then I’d want it to include this book.

Interviews Without Puzzles

| Comments

Technical interviews have their own particular lore, and their own history. Over the years, there are some interview practices that have sunk into the group subconscious of engineers, to the point where they’re used so commonly we don’t even question why. Puzzles, for example.

There are a few famous interview puzzles out there. Microsoft has “Why are Manhole Covers Round?” Google has “You are shrunk to the height of a nickel and your mass is proportionally reduced so as to maintain your original density. You are then thrown into an empty glass blender. The blades will start moving in 60 seconds. What do you do?”

The standard answer to the first puzzle is “So they don’t fall in.” The answer to the second is that assuming you have the same proportionate strength, you can jump out. (There’s an inverse square root effect between muscle and body length, so density is not a factor.)

But here’s the thing. The first answer is incorrect. Manhole covers are round because they can be round. They could be square or triangular just as easily.

So as an interviewer, if you pick random interview puzzles out of a book and you think you know the “right answer” to the puzzle, you run the chance of not hiring someone because the answer he gave was actually the correct one.

A more common problem is that a clever interview puzzle is usually well-known. As soon as you figure it out, you’ll tell all your friends, and they tell their friends. Eventually, you can google for the answer.

Back in the day, Zen Schools had the same problem. They were looking for insight and flashes of realization, initially, and wanted a way to test for this. Some people thought up excellent questions that could test the subtle understanding of self, reality and perception required of Zen students. More and more, the koans were used as the standard by which students’ understanding could be measured. Eventually, someone had the bright idea to put together a book of koans — complete with “acceptable responses” — and through years of formalization, the age old question “What is the sound of one hand clapping” turned into a meaningless ritual.

Even if you don’t use well known puzzles, interviewing with logic puzzles in the long run optimizes for them. Through discussion, shared experiences and research, people will generally know that they should study for a general class of logic puzzle. And the company will start getting more people that will do well at those puzzles… but that doesn’t mean they know programming any better.

Fermi questions, those “How many elevators are in New York City?” questions that are popular in interviews, have a clearer structural weakness. They have no right answer at all, and can be completely circumvented with the right training. Once you know the rules, you can come up with completely the wrong answer and still be “correct” according to the law of the game.

I also have a philosophical problem with Fermi questions. Yes, they’re pointless, but it’s not just that they’re pointless. Asking a Fermi question says that you don’t really care what the answer is. Asking a Fermi question tells your candidate that you want them to guess.

Engineers are trained out of guessing. Engineers are trained to nail down as much as they can before solving any problem, because invalid assumptions and requirements are dangerous and expensive. But that’s not why engineers don’t like to guess.

Why is because most engineers remember vividly what happened the last time someone came up to them and said “When do you think we can go live? Just make a guess.” When it comes to Fermi questions, a cagey and hesitant engineer isn’t a bad candidate, but an experienced one.

So what do I recommend? This book is good to get a broader sense of what interviews are supposed to do, and you can ask spot questions about language and system knowledge, then rate them on the Programmer Competency Matrix. But the best way to figure out how someone attacks code is to bring out some buggy code and ask for help debugging it, or bring out a design and talk about how you’d implement it, talk about the engineer’s background, print out the engineer’s github project and ask about it. They’ll appreciate it, and so will you.

Failing With Passwords

| Comments

Did a talk about implementing password security right last night at Five Minutes of Fame.

If you don’t want to go through the slides, here’s the TL;DR version:

TL;DR User Security

  • Use a password manager like LastPass or 1Password (with Dropbox) and use their password generation.
  • If no manager available (routers, OS logins, etc), use pass phrases with non-English words or acronyms (see xkcd)
  • Assume sites get compromised all the time and you never hear about it. NEVER reuse a password.
  • If you’re at a coffee shop or hackerspace, use a public VPN service.
  • OAuth / Twitter / Facebook based authentication is putting your auth credentials in their hands.

TL;DR Encryption Security

  • Use bcrypt. Bounce up the factor every few years.
  • Do not limit password field length. (bcrypt takes up to 55 bytes of input.)
  • Run a JS password tester to reject weak passwords.
  • Run a password cracker regularly to test your security.
  • Suggest to your users that they use passphrases with acronyms, punctuation or LOLspeak.
  • Generate random passwords for your users.
  • Consider removing password masking.

TL;DR Operational Security

  • Use HTTPS for both rendering and submitting login page.
  • Show Cain and Abel video to everyone you work with.
  • Use HSTS headers with HTTPS.
  • Use Synchronizer Token to prevent CSRF attacks (or use a decent web framework).
  • Use a captcha / throttle on password attempts.
  • Use double validation for registering accounts (register sends email, clicking email link heads back to site).
  • Use one time use password reset links.
  • Send email notifications on password change attempts.

Extra Credit

  • Add Honeypot Logins.
  • Use login token IDs with hidden check bits and math invariants that indicate tampering.
  • Implement a secret in the session management system to keep state on the client and verify it on server interaction for better session authentication.

OWASP also has cheat sheets which look useful if you’re putting a site together. It still disturbs me how freaking MANUAL so much of this is, but I suppose web frameworks can’t do everything for you. There are some options if you’re on Rails.

It was a surprisingly tough talk to give. At first I was like, “lol, look at all the companies with crappy security”, but it’s a murky field in general. For example, the XKCD cartoon about passphrases is missing the problem that most people type passphrases in standard English, and only use about two thousand words in general conversation. It may look like there’s more entropy generated, but if your attackers know that your customers use passphrases, you may have just made their jobs much easier.

Also, brute force cracking is surprisingly effective. MD5 and the SHA-* algorithms are inappropriate because GPUs chew through them very quickly, but the newer FPGA chips can do a reasonable implementation of bcrypt in hardware. It’s an issue that computers are fast, but a bigger problem is that they just keep getting faster.

The biggest thing has to be to not let your users pick crappy passwords. Even if you have bcrypt with all the factors, if your users are entering “12345” as the password, it’s not going to make a difference.