September 2011 Archives

Learning UEFI

This weekend I put together (mostly as it turned out) a new fileserver for home. The box that's currently pulling that duty is 9 years old and still working just fine.

However, 9 years old. I'm happily surprised that 40GB hard-drive is still working. Only 58,661 power-on hours, and all of 3 reallocated sectors. But still, 9 years old. There comes a time when hardware just needs to be retired before it goes bad in spectacular ways.

The system that is replacing this stalwart performer cost under $400 with shipping, which contrasts starkly with the sticker price on the old unit which was around $1400 back in the day. This system is based on the AMD E350 CPU. Underpowered, but this is a file-server and that ancient P4 is still keeping up. I have a Drobo that I'll be moving to this unit, which is where the bulk of the data I want to serve is being kept anyway.

As for the title of the post, this E350 mobo has a UEFI firmware on it. That's when things got complicated.

End of year spending

It's that time of year for us to get our end of year spending priorities in. Each place I've worked has handled the EOY spending issue differently.

At my first job, civil service, we were on the calendar year for our budgeting year. Because of how the funding worked, we typically started spending heavily in October in order to use up excess IT budget. This was known as "Christmas in October". The reward for thrift, not spending as much as you were given, was to have your savings taken away from you so there was no incentive to do so. So, everything got spent.

At WWU, our budget year ended on June 31st which is smack in the middle of summer. Since Summer is Major Project Season for pretty much any US University, our EOY spending coincided with our annual upgrade-all-the-things spree. Thus, it was kinda hidden.

However, things did change while I was there.

For the first two or so years I was there the CIO gave each of his departments an actual budget for spending on technology. There was some spend-down in April under him, but not as much as that first job. Unlike that job, WWU did allow budget carry-over between years. Then we got a new CIO (retirements, don'tcha know) and he did things differently. He liked to give his departments budget for people and routine expenses, and dolled out funds for technology projects on a project by project basis.

Then 2008 happened and we went into negative-budget land. The concept of 'surplus budget' just didn't exist. There was a brief orgy of "spend it now!" before the budget boom came down, but that ended quickly. Then in 2009/2010 there was a pile of 'legacy' funds that we were told to spend on things to keep our infrastructure up and running until the fiscal environment recovered, since major upgrades were going to be off the table for the foreseeable future. I installed over $200K worth of storage stuff thanks to that.

Here at my current employer I don't yet know how things work. Since I am the entire IT department and don't have a budget, it's mostly just providing suggestions and quotes, with a healthy dose of explaining needs. Or, just like the rest of the year but with a longer planning horizon than usual.

Deep computing

It's no secret that weather forecasting is a problem that can keep many a super-computer up all night. Cliff Mass of the U of WA recently posted a nice writeup of what they're doing:

That sort of parallel computing problem is the kind of thing that really fired me up back in college. So. Cool.

Password generation determinism

"Unless a password generator is just taking raw output from /dev/random, it's using programming logic to determine the password. Programming is deterministic, so password generators are deterministic, and so are the passwords they generate.

Therefore, password generators do not produce good passwords. Q.E.D."

I saw a statement much like that one a while back. The questioner was concerned that programatic password generators were not yielding good passwords, since they were designed with deterministic logic and only took a restricted set of inputs to generate that password.

This is true to a point, but there are limits.

If you have perfect knowledge of how a password generation program works and what it uses for inputs, it is possible to derive correct passwords much faster than true random guessing would suggest. The only entropy in the system is introduced by the inputs. If that input size is (for example) only 8 bits regardless of how large a password is generated, the final password will have no more than 8 bits of entropy. You can create a table of all possible passwords this program can generate.

However, if you don't have perfect knowledge of how the password generation program works, the effective entropy can be much higher for an attacker. The effective entropy will be somewhere between the supplied entropy and the entropy implied by the password length.

So, turn this on it's head.

Take password stores. They take a user-supplied password which can have very bad entropy, perform a generally well known computation on it to get a string (frequently called a hash) that is actually stored. This is seen as effective security, so long as the computation is sufficiently robust and non-reversible. But, robustness is a moving target. MD5 is broken, WEP hashes are so broken as to be nearly cleartext these days, Windows LanMan hashes are very broken, SHA-1 is showing some weaknesses but is still pretty strong.

Password-derivation attacks focusing on automatically generated passwords are perhaps most effective when used against systems known to use generated passwords that users will actually keep. Unless they have something like OnePassword end-users will immediately change passwords that are 16 characters of random typeable-ASCII, but may keep something like, "shoes376emotional". The techniques for defending against password-guessing attacks are well known:

  • Limit the rate the system will accept login attempts for user accounts (increase the time required to guess the password)
  • Limit the number of times a login can fail before locking the account from further login attempts (increase the time required to guess the password)
  • Force periodic password changes (move the target faster than password-guessing could find the password)
  • Prevent stations with lots of bad login attempts from further access to the login process (force the attackers to use multiple stations)
No matter how you slice it, even with perfect knowledge of the password-generator an attacker is still going to have to grind through a lot of passwords to find the one that works. They'll be able to find it faster than the char-sets used in the password would suggest, but still need to plow through thousands of attempts. Most of the above methods have been baked into things like Active Directory for a very long time. The same can't be said for bespoke website authentication services.

Using a well known poorly designed password generation system that spits out passwords end-users are likely to continue using means that you need to move the goal-posts (force regular password changes) more often in order to prevent brute-force intrusions. Unless you're also supplying generated passwords for those changed passwords (I've never heard of such a system, but I suppose they could exist) the changed passwords are likely to be something slightly different ("shoes#&^emotional") to completely different than the ones the generator would spit out, which further reduces the likelihood of a successful password-guessing attack.

The biggest vulnerability presented by poorly designed password generation systems are for systems that:

  • Don't rate-limit login attempts
  • Don't lock-out accounts after a certain number of bad login attempts
  • Don't force password changes
  • Don't do any kind of IP-reputation lockouts after repeated bad logins
A lot of built-from-scratch web authentication systems don't do any of the above four points, instead they focus on keeping the password hashes secure and having a password-recovery option for people who forget their passwords. Putting an insufficiently entropic password generator on top of it compounds the bad idea.

Can password-generators produce good passwords?

They absolutely can produce cryptographically good ones (a simple one: draw 8 bytes from /dev/random, get the sha1 hash of those bytes, convert the first 16 bytes of the hash to UTF-8, rerun bytes that don't translate, bam! Good 16-character password). Producing good passwords that users will be able to remember is another much more complex problem.

Are bad password generators unusable?

Since bad is relative, it depends. Such poor generators could be sufficient for producing short-term temporary passwords, which limits their vulnerability window. Usable, but only intelligently.

Scalability 2011 has been canceled

| 1 Comment
Actually, all of StackOverflow's DevDays has been canned. Too few people registering. The gory details.

I had been really looking forward to that conference, as it covers the kinds of problems I'm dealing with right now.
Matt Simmons has had it up to here with booth-staff at technical conferences that don't know the products they're trying to sell. I totally know what he's talking about, if the person I'm talking to at a booth is only there to hand out glossy fliers and take my contact information so a sales engineer can call me next week, I wish I didn't bother stopping by. If I wanted to view their website, I'da, you know, viewed their website on my own time. I don't need a sales droid to hand me a printed out PDF. I want them to be able to answer technical questions about their products, that's why they're at a technical conference.

Another kind of problematic sales-staff is the person filling the role of Walmart Greeter. They're there to smile happily at you when you approach and forward you to someone who can answer all of your questions. Unless the booth in question is Walmart-scale, this role is largely unneeded. I appreciate the customer service touch of being warmly greeted, but it goes over a lot better for the vendor in question if my first contact can answer my questions.

The final problematic sales-staff person is the ostensible topic of Matt's post, the people that are there to act as a kind of live advertising poster for the booth. Frequently this role is shared with the Greeter, though not always. Sometimes you're fully expected to not talk to these people. They catch your eye because they're attractive, and in so doing you also get a view of the booth they're standing near. They might be in some kind of thematic costume (full HALO armor for Microsoft), or dressed provocatively (bikinis). As you walk right by them, you know they're not there to talk to you about product.

Matt's suggestion is to treat everyone in the booth as if they know what they're talking about, and to complain when you find someone that doesn't.

Very simple.

Some people are quite obviously part of the booth set, such as that HALO person hanging out by the XBOX display. Others, such as the rather attractive woman with a handful of bi-fold glossy pamphlets, aren't explicitly part of the scenery and should at least be able to field some technical questions. So ask them.

And yet, Matt is catching some grief in the comments section. More on that below the fold.

OpenSUSE and Java

I was just catching up on email when I ran into this interesting tidbit

Up to now, openSUSE users had the choice of using openJDK (GPL with classpath exceptions) or Sun/Oracle's Java. The Sun/Oracle Java was licensed under the "Distributor's License for Java (DLJ)", which allowed Linux distributors to package and redistribute Sun/Oracle Java. Recently, Oracle announced that openJDK 7 is the new official reference implementation for Java SE7. They no longer see the need for the DLJ licensed Java implementation and so have retired that license.

openSUSE chooses to proceed with distributing the GPL licensed official reference implementation, openJDK. We will no longer distribute newer versions or updates of the now proprietary licensed Sun/Oracle JDK. Existing installations of the Sun/Oracle JDK are still licensed under the now retired DLJ.

openSUSE users who wish to continue using the Sun/Oracle JDK (including new versions thereof and updates) should now download directly from For now we keep the current sun-java packages (under the DLJ license) in the Java:sun:Factory project and will not update them anymore.

I suggest to document in the openSUSE wiki how to install the Sun/Oracle JDK version from Oracle under openSUSE.
Which is to say, Oracle is killing the license that allows OpenSUSE to provide Sun/Oracle Java as a part of the repo.

As a user of java apps in the line of my work, this deeply annoys me. What few management java apps work well on Linux (it's always a surprise when something does), seem to work best with Oracle Java not OpenJDK..

It probably won't be just OpenSUSE affected by this.