Archive for August, 2010

How to guess your password…

Thursday, August 26th, 2010

Interesting post at
about how John Pozadzides would go
about hacking someone’s password.

While it’s nothing new, it does revisit good advice that everyone should
follow: avoid passwords that are based on names of people close to you,
don’t think that sticking a digit at the end of your password makes it secure,

What it does do is make the same mistake that lots of “password security”
advice does – which is to assume that an attacker can test millions
of guesses per second. That’s only true if the attacker has access to
the password hashes, which usually means that he’s already got physical
access to your computer or has compromised the security database of an
application you sign into.

That’s a big assumption and I would venture that it’s almost always false.

If an attacker has to test passwords by trying to sign into one of your
accounts using a script, he’s unlikely to get more than about 1 guess
per second and he’s quite likely to trigger a lockout after a few tries.
Moreover, many on-line login systems now use CAPTCHs, so he can’t even
script the attack.

In short: protected and inaccessible password hash databases, slow
interactive login screens, intruder lockout mechanisms and CAPTCHAs
make brute force attacks, even optimized with good dictionaries, pretty
much useless, unless your password is *really* bad.

John also suggests that your bank account is linked to your e-mail
address, so a compromise of your e-mail could also compromise your bank
security. That’s a bit of a stretch, in my mind. I can’t comment about
all banks, but none of the financial institutions that I do business
with even know any of my e-mail addresses.

So here I’m just curious: does your bank use your e-mail address as an
out-of-band authentication factor?

Developer access to production systems? Sure! (sometimes)

Wednesday, August 25th, 2010

Interesting blog entry on about whether and when to grant developer access to production systems.

It’s a good read – if you’re a developer or an admin – go read it.

The one thing I can add to the discussion is simply this: it’s not an all-or-nothing question. It’s reasonable, for example, to grant developers admin-level access to a production system in the context of resolving an emergency outage, or troubleshooting a hard-to-find problem, or performing a complicated version upgrade, or even as backup resources if all the normal admins are unavailable (home sick, etc.).

Operationally, it’s pretty straightforward to do that using a privileged password management system. That’s because PPM systems randomize passwords regularly (e.g., daily or even more often), so giving a developer the admin password to a production system does not imply that he’ll still know it tomorrow, or even that he’ll know the admin password for some other systems. A PPM system can also be used for workflow authorization of the temporary access grant, audit logs, etc.

the unpleasant intersection of government, security and privacy

Sunday, August 22nd, 2010

A couple of unrelated but similarly themed stories making the rounds:

  • Seems that someone is trying to intimidate Julian Asange (of wikileaks fame) by fabricating and quickly withdrawing criminal charges:
  • Seems like the Elections Commission of India is trying to muzzle a security researcher who pointed out that their electronic voting machines are vulnerable to tampering: and

In both cases, the uncomfortable theme is that governments can use their coercive power to try to silence critics, and that especially includes critics who try to shed light on uncomfortable truths…

12 character passwords required?

Thursday, August 19th, 2010

An interesting write-up at
and elsewhere. The original content for this appears to be here:

Sounds like the good folks at Georgia Tech have worked out how fast they can
crack passwords (i.e., validate whether a guessed password matches the hash
from a password database) using a GPU. They don’t seem to mention which
password hashing algorithm they are attacking, but they do point out,
in the way that responsible journalists never would, that an attacker would
of course have to have a copy of the password hashes first.

The first line of defense in most password systems is to prevent attackers
from getting the hashes. So long as that works, this whole class of attack
is irrelevant. Something sensationalist journalists (hey, that rhymes!)
fail to point out.

So what have we learned?

  • GPUs can be used to more quickly brute-force passwords, if you have
    managed to compromise the password database.
  • In cases where the password database remains inaccessible to attackers,
    this is irrelevant.
  • Take any sensational claims about security with a grain of salt.
  • Passwords are insecure! Passwords will be gone soon! (Yeah, right.
    We’ve heard that for 20 years, and it just doesn’t seem to come true).

Good corporate citizenship…

Tuesday, August 17th, 2010

Wow – we used to think of Microsoft as a scary company.

In just one week Oracle has promised to eliminate live source code repositories for OpenSolaris, effectively making it “not quite open” ( and filed a lawsuit against Google over its use of the Java programming language (

Nice to see that they are putting Sun’s assets to good use.

To the folks at Oracle: is this the sort of behavior that your customers ask for?

E-mail, social media passwords the same: who cares?

Monday, August 16th, 2010

Two blog posts in one day – that’s a first! 🙂

Interesting read at (OK, I first found it on slashdot).

The gist of it is that many users have the same password on social media sites and web-based public e-mail systems.

My first impression is …. so? Those are low-value assets, and users choose convenience over security because their (correctly) think that “well, if someone hacks any or all of these accounts, I really don’t care much about it.”

Just because we *can* make things secure doesn’t automatically imply that we *want* to make *everything* secure. Some things are basically sacrificial in nature.

Full disk encryption – costs and benefits

Monday, August 16th, 2010

A nice write-up about deploying full disk encryption to client devices:

A couple of interesting tidbits:

  • Key recovery is key (pun intended)
  • Deployment rate seems to be about 10-25 PCs/IT staff/day. Brutal for enterprises.

A good read, in any case!