Handling Password Fields

With the advent of the heartbleed debacle you’ve probably spent a bunch of time changing your passwords. I know I have. Having to update several passwords has opened an old wound: the really really stupid policies and coding behind password fields.

My passwords are generated automatically by my password manager. They’re long random strings containing both cases, symbols, and digits. They’re very secure. Of course a lot of sites don’t like that. They’re too long, or they have symbols the site doesn’t like, or some other fool thing. I saw all these complaints while I was changing my passwords.

Here’s Terence Eden with a hillarious post on entering passwords. He’s got all the problems (and some that are, maybe, just a bit fanciful). Except for the obvious humor, they’re all real and all very annoying. But the worst, absolute worst, is the common practice of not telling you what the password policy is. You try a password and get an error message. You try another and get another error message. It’s like a text adventure game. I know, how about xyzzy1? Eden’s post captures this craziness nicely.

A good general rule, which I subscribe to, is that if there are any restrictions on the password then the site is insecure. That’s because if they’re doing it right—using bcrypt, scrypt, PBKDF2 or something similar—then it doesn’t matter what password you enter2. If you’re not using bcrypt or one of its siblings then it’s almost a certainty that you’re not properly hashing and key stretching so that when your user database is captured it will be an easy matter to recover the passwords.

Eden suggests some rules to reduce user frustration. The first, of course, is state your policy up front so the user doesn’t have to guess. Of course, if you’re doing it right you don’t need any rules because you won’t have any restrictions. Yes, yes that means that users can input stupid passwords but most stupid passwords will pass the normal rules anyway. Password123 anyone?

Footnotes:

1

I tried that one but nothing happened.

2

OK, if you’re too lazy to deal with variable length inputs, choose a max password size of 1024 or something that no one is apt to actually use. They all get hashed down to the same size anyway so the initial size doesn’t matter. The point is that arbitrary restrictions are a sign of weakness.

Posted in General | Tagged | 4 Comments

Sacha Chats with Tom Marble

Sacha Chua has posted another interesting episode in her series of video chats with Emacs users. This time it’s with Tom Marble who talks about and demonstrates his Emacs-based invoicing system. Marble is a consultant and wrote the system to track the details and hours of his consulting work and to generate nice looking invoices for billing.

Marble also talks about using Emacs for his Clojure work and he demonstrates some of his work flow. As usual, Chua has him take us through a quick trip of his .emacs file. The video is just over 57 minutes so plan accordingly.

If you like the video and want to see more, Chua has a page with links to all her Emacs chats. I invariably learn some tidbit of Emacs goodness that I didn’t know so the videos are definitely worth your time.

Posted in General | Tagged | Leave a comment

The NSA and Heartbleed

Bloomberg is reporting that the NSA knew about and exploited the heartbleed bug for years. The NSA is, of course, denying that but if you’ve been keeping score it’s pretty easy to figure out who to believe.

If it’s true that the NSA knew about the bug and kept the information private so that they could use it, it’s a nice illustration of something that Bruce Schneier has said repeatedly. The NSA is making us less safe not more safe. It’s virtually impossible to know if a site has been exploited by heartbleed so it’s entirely possible, or even likely, that criminals or foreign state actors have been exploiting the bug. The NSA’s primary mission is protection of the country’s communications. If they failed to act to close a devastating hole in a widely used SSL implementation then they’re obviously failing in that mission. Failing on purpose.

Posted in General | Tagged | Leave a comment

Mickey on Running Shell Commands with Dired

The essential Mickey over at Mastering Emacs has another post in his series on dired. This time it’s about running shell commands on multiple files from within Emacs. If you’re a Unix user and used to using find and xargs to do this sort of thing, you should definitely check out Mickey’s post. Using dired is easier and you don’t have to leave Emacs or even bring up a shell of some sort in a buffer. Unless you’re a dired expert, Mickey’s post will teach you things you didn’t know. And while you’re there, be sure to follow the link to his post on how to work with files spread out across many directories. The two posts tell you pretty much everything you need to know to use dired in situations that would otherwise require find and xargs.

If you’re like me, you probably started using dired as a convenient way of listing files so you could pick one to load into a buffer. Later, maybe, you started doing simple operations like deleting a file or perhaps renaming it. It’s when you first realize that you can work on multiple files at the same time that you begin to realize how powerful dired is. For example, watch Magnar Sveen use multiple-cursors to change file names in a writable dired buffer. Of course you can do this using dired commands too but it shows how flexible dired is and how it can adapt to your way of working. Mickey’s post shows how you can apply external commands to multiple files in a variety of ways. Very useful information.

Posted in General | Tagged | Leave a comment

Latency

Every programmer understands, at least in a general way, the relative latency of various computer operations. For example, we all know that accessing a value from a CPU register is faster than accessing that value from an L1 cache is faster than accessing that value from an L2 cache is faster than accessing that value from an L3 cache is faster than accessing that value from memory is faster than accessing that value from a disk.

We might even have an idea of what those speeds are. Typical values might be .9 ns for accessing an L1 cache versus 120 ns for a main memory access. If you’re like me, it’s hard to compare those values. They seem essentially the same: really small.

Here’s a wonderful spreadsheet that makes those comparisons come alive1 by normalizing the values to a one second cycle time. With that, an L1 cache access takes 3 seconds and a memory access 6 minutes. No need to do mental calculations here; we can see immediately how much faster the L1 cache access is. To continue the comparison, a disk access takes 1–10 ms; normalized to the 1 sec cycle time that’s 1–12 months. See what I mean about making the comparisons come alive?

The spreadsheet considers actions such as sending an IP packet from NY to San Francisco or to the United Kingdom and booting the system. Take a look at the spreadsheet. The values are truly amazing. As a teaser, booting the system takes 32 millennia.

Of course, normalizing the times to a one second cycle time doesn’t really give us more information, it just makes the information more understandable. Looking at the values you begin to see why things like locality of reference really do matter.

Footnotes:

1

I can’t figure out the provenance of the spreadsheet to give proper credit. If you know, leave a comment.

Posted in Programming | Tagged | Leave a comment

Working Through SICP

As I’ve said many times before, I’m a huge fan of The Structure and Interpretation of Computer Programs (SICP), Hal Abelson’s and Jerry Sussman’s seminal work on computer science. It’s a tremendous resource and one that’s available on the Web for free along with a series of lectures by Abelson and Sussman based on the book. It will, I promise you, teach you things you didn’t know and change the way you think about programming.

In the last couple of days, I’ve come across two articles that offer advice on why the SICP journey is worth taking and ways to make the trip easier. The first, WHY AND HOW TO START YOUR SICP TREK by Kai Wu explains what the excitement is about and what well known computer scientists have said about it. Wu explains why the effort required to work through the book is a worthwhile investment and offers some advice on how to proceed.

The second, Learn SICP, Make Friends, provides similar motivation but offers an iPad program that allows you to collaborate with other people working through the text. If working through SICP by yourself seems too daunting, this may be a good alternative.

If you haven’t yet done so, I urge you to take the trek. Be warned, though, it takes some work. The text is well written and easy to read but you really need to work almost all the exercises to get the optimum results. Watching the videos as you read the book is also a good strategy but, again, you really do need to work those exercises.

Posted in Programming | Tagged , , | Leave a comment

Another GnuPG Tutorial

I’ve written many times about GnuPG and other programs that support the OpenPGP standard (the last time here). I really, really wish that everyone would start using it. That would certainly put a crimp in the NSA’s operations.

Over at Digital Era, a site dedicated to discussing tools and methods for protecting our digital privacy, there is a nice tutorial on using GnuPG. The tutorial assumes you’re using Linux but the information is applicable to most Operating systems that support GnuPG. It’s well worth a look if you haven’t yet installed GnuPG or similar system.

Of course, getting Linux users to start using GnuPG is a lot easier than getting your Aunt Millie to start encrypting her email but that’s what’s required to get the NSA and other snoopers out of our email. Nonetheless, it’s a necessary first step: Today email; tomorrow our phones.

Posted in General | Tagged | Leave a comment

Left Turns

Do you avoid left turns when you’re driving? I do. I’ll take different routes to destinations that are across the street from each other to avoid making a left-hand turn against traffic if the destination street has more than light traffic. I do that mostly because I hate getting stuck in traffic waiting to make a turn.

It turns out, though, that it’s the smart strategy and even the green strategy. UPS, who famously uses operations research to plan their routes and other operations, has studied the question and found that avoiding left turns saves time and gas even though it may result in a longer route. One UPS driver estimated that 90% of his turns were right-hand turns and said that UPS really, really hates left-hand turns.

I don’t know about you but I love this kind of thing. It’s geeky and practical at the same time. I especially like results of this sort when they’re counter intuitive as this one is. In any event, if you, too, avoid left-hand turns you no longer need feel silly; it’s the practical thing to do.

Posted in General | Leave a comment

Narrowing to Multiple Regions

One of the joys of writing this blog is the things I learn from the comments. The other day, I wrote about fancy-narrow and that provoked an interesting discussion between Wilfred and Phil. Wilfred compared fancy-narrow to narrow-to-region-indirect. I assumed that narrow-to-region-indirect was a standard command or function that I wasn’t familiar with and put it in my todo queue to investigate. Phil beat me to it and discovered that it was actually a very useful piece of custom code.

The idea is that you clone the current buffer one or more times in such a way that you can narrow to different regions in each of the clones. If the utility of doing this is obscure to you, Zane Ashby has a nice post that gives one use case as well as showing code for a function to do it. As Phil remarks, before he saw that code he used to do the same thing manually.

You might think that you could open a file in a buffer and then split the buffer the appropriate number of times to do this but that doesn’t work because narrowing in one of the buffers narrows in all of them. The trick is to create indirect buffers, which can be narrowed separately. Changes made to the text of any of the indirect buffers is reflected in all the clones and the base buffer so that when you’re finished you can just delete the clones and save the base buffer.

You can find the code to automate this in Ashby’s post or a slightly different version by grayswx in this paste. If you have the need to work in different parts of a buffer at the same time—especially if you want to use different modes in each—this technique (and the function that implements it) could be just what you need.

Posted in Programming | Tagged | Leave a comment

The New Luddites Strike Again

From time to time I take note of some particularly egregious example of stupidity from the new Luddites. The last time was here; see that post for links to the others. Today, we have another example in Judith Shulevitz’s article in the New Republic on how Siri is messing up a whole generation of children.

Shulevitz starts with a vignette about her daughter playing with her iPhone and interacting with Siri. After a while, the daughter gets frustrated with Siri’s inability to hold a full-fledged conversation and tells her she’s fired. That’s not the problem, though. The danger is that Siri will get smarter and be able to hold better conversations. From there it’s a speedy descent into psychobabble. There’s the problem of Siri’s failure to live up to the “maternal expectations” of the child. Then we move onto the possibility that Siri and other modern interactive devices will engender a slave owner mentality in our children.

I won’t bother pointing out the obvious silliness in all this. You should read it and see for yourself. I’ll say it again to these people: If you don’t like the modern world, you’re welcome to ignore it but, please, leave the rest of us alone.

Posted in General | Tagged | Leave a comment