I’m going to have to disagree with Bruce Schneier and Jakob Nielson on this one:

I, and many other users, are often in situations where we are in the position of logging into systems in the vicinity of people with which we wouldn’t want to share the password.

Let’s look at the arguments against masking from the original story:

  • Users make more errors when they can’t see what they’re typing while filling in a form. They therefore feel less confident. This double degradation of the user experience means that people are more likely to give up and never log in to your site at all, leading to lost business. (Or, in the case of intranets, increased support calls.)
  • The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security.

I’m not sure I agree with the first one at all.  Password entry is so commonplace now that only the freshest of the new users would decide to not use a site or product because it masks passwords.  Everybody has experience with it and knows what they’re getting into.

As far as overly simple passwords go, I think that the need to remember the password is the limiting factor here, not having to type it blind.  If you displayed the password back to the user as they typed it, I don’t think most users would choose any more complex passwords than they already have.  Copying and pasting passwords is actually a great idea here, but not quite like Jakob Nielson has put it.  If you have a password manager, like KeePass X, copy a masked password from there into a masked field, and it falls out of your copy buffer afterwards, you’ve got pretty good security even when someone is looking over your shoulder.  They could catch your password to unlock your manager, but looking over someone’s shoulder at the keyboard is magnitudes of order more difficult than reading a password off a screen, especially if the user can type it quickly (being one of the few passwords they actually have to remember).  Even if they do, that password won’t get them into a remote system, they’d have to get ahold of your password management db first.

The checkbox idea is alright, though:

Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.

I think more users would be at risk, more often than they think, if password fields were unmasked by default.  I would support having a checkbox like this checked by default in all situations.  Then a user will have to at least think for a moment and maybe assess their current situation before deciding to unmask.

If people start implementing non-masked fields because of this, I’m investing in a higher resolution camera with a good zoom.

Moyix made a really great point on twitter in response to this:

@McGrewSecurity Makes attacks like http://crypto.m2ci.org/unruh/publications/backes08compromising.html much more effective too :)

The link goes to a very interesting paper on reading data off LCD screens from the reflections on objects in the vicinity.  Not to put words in his mouth, but Bruce would, if he ever read this blog, likely argue that this is a movie-plot threat, but it looks pretty doable to me (and a fun project).

Moyix’s blog, “Push The Red Button” looks very nice too.  I’m definitely adding it to my reader.


These are not words that I often let my own computers tell me (for long).

When it comes to controlling resources, it’s relatively easy to keep people from reading things (access controls, authentication, cryptography, etc).  We’re pretty good at that.  If we own the medium, it’s even fairly easy to keep people from writing things to it.  We can’t, however prevent people from writing to their own media.

So what does this mean?  We have security mechanisms that work (more or less) for reading and writing, but controlling someone’s ability to copy is a Problem.

I ran into this the other day, in OS X’s Preview app, when I tried to copy and paste a quote out of a PDF :


Right.  So, given:

  • An environment that I could conceivably control, instrument, or log every aspect of
  • A file format that’s typically friendly towards copying text (Highlighted the quote with a text tool, so it’s being represented as glyphs, not images I’d have to OCR or curves I’d have to put back together).
  • Permission to read

…there’s no way this kind of protection can work.  If someone has the ability to write to some media, including their own (out of your control!) then giving them read access to some data is tantamount to granting them the ability to copy as well.  Error messages like this are nothing more than polite requests.

I’d have put a tutorial on how to get around this on here, but there’s really just one step:

  1. Use Skim.  It’s nicer anyways.

I like SunbeltBLOG a lot (and I recommend that you add them to your reader), however, like most of the content in my RSS reader that I really like, I occasionally find myself disagreeing with them. Today’s post, For shame: Thawte trusts Gromozon is one of those times. While I can certainly understand people not liking anything that helps out malware, I think this is a case of people’s expectations about what security mechanisms are supposed to provide not matching up with the reality. Another good recent example of this is the embassy password incident, revealing the fact that many people were under the impression that Tor provides privacy (which it doesn’t), when it’s designed to provide anonymity (which is does, if you use it right).

Picking this apart, let’s see what people think code signing is supposed to provide. This is easy: a lot of people are guilty of assuming that something being signed means that it’s safe to install. This comes from impressions that people have formed about what a signature means, and what role the certificate authority takes in the matter. Let’s take a look, starting with the title of the SunbeltBLOG post:

“For shame: Thawte trusts Gromozon”

Certainly sounds shameful, after reading what Gromozon does. But does Thawte really trust Gromozon? Is that really what the certificate means? If you follow the link from SunbeltBLOG to SpywareGuide then you’d be inclined to think so. They spell out what they think the certificate means:

  • The publisher: The software really comes from the publisher who signed it . Publishers most go through a process to verify their identity and that they are who they say they are.
  • The content: The software has not been altered or corrupted, and is therefore safe to install and run.

Hit the brakes there! You’ve gone a little too far. This was right, up until the last bit about “…and is therefore safe to install and run”. The certificate authority does verify the identity of publishers, and the process of signing code, and verifying that signature on the client does mean that it hasn’t been altered or corrupted between the publisher and client. It does not speak for the content, actions, and motives of the software or the publisher! People think that digital signing of code “solves” the problem of malware, however it only means that the malicious code has been there since the publisher signed the code. It may deter people from putting their signature on malicious code, since it can be tracked back to them easily, however this demonstrates that this doesn’t bother or stop some authors.

Go to the horse’s mouth. See what Thawte has to say about their code signing certificates. Having code signed by the publisher “effectively verifies the source of your software before it is downloaded”, and “Ensures that your active content or code cannot be maliciously modified” (“your” referring to the publisher). For the end-user of signed software, it gives them “recourse to the person who published it”. This is all consistent with signing something like Gromozon. The only time it really comes close to speaking of the content of the signed code is when it says that the process “Promotes the Internet as a secure and viable platform for content distribution”. This might be mistaken to mean the end-user’s security from malicious code, but it’s really in reference to the threat of modification by third parties.

So, code signing is a good idea, but people need to understand the problem that it is meant to solve, and the problems that it does not.


(I haven’t posted in a while, since I meant to do a post about various apps a security professional might want on their Windows Mobile/Pocket PC phone. Aside from other engagements, I’ve just been having too much fun playing with the different programs available for my phone to actually write anything down. It’s very addictive, but I promise you’ll see the fruits of all the tinkering on here soon. Really :) . )

Most security conscious people make use of their operating system’s “Lock Workstation”, “Lock Screen”, or similar locking functionality whenever they need to step away from their computer for a moment. It’s convenient, since all of your programs are still running and sitting there just like you left them, unlike having to start from a clean slate by logging out and back in. Some people may have picked up on using this security feature, due to an office culture of pranks (such as humorous wallpapers) pulled on those who leave their computers unattended. If your organization’s policy doesn’t put a damper on such pranks already, it can be an effective way (though not necessarily the best way ;) ) to get people to lock their screens.

One important aspect of screen-locking that people don’t normally consider is the environment in which the screen will be unlocked. If you’re sitting at your desk working on a confidential document and someone walks into your office, you can minimize the document before they see it (if you can’t, rearrange your office!). However, if someone is already in your office, followed you in during a discussion, or is otherwise in viewing range of your screen when you sit down to unlock your session, it will be a race for you to minimize the sensitive data once you have unlocked, and the chances of a glimpse are much higher. This can be an even more serious issue, when it comes to laptops, where the situations they are locked and unlocked in may vary greatly as they are carried around (imagine a worst case scenario of it being unlocked while hooked up to a projector).

So what do you do? You make a habit of hitting the “show desktop” (or equivalent) button to minimize everything before locking your screen. Then, once you unlock, you can selectively bring applications back up from minimization, as the situation allows.

As the title advertises, it’s a little thing. However, it doesn’t take much time, it’s easy to explain to your users, and can prevent some cases of accidental disclosure.


LonerVamp of terminal23 has written a nice blog post about anonymity on Internet Relay Chat (IRC):

staying anonymous – part 4 irc

I left some additional comments to it that should be approved any moment now ;) . Anonymity is harder than configuring your client to use a proxy, and LonerVamp does a good job of conveying that. It’s a matter of changing your behavior, and becoming tuned to recognize identifying characteristics of what you’re doing, and modifying them. You should always be looking for ways that you might blow your own cover and prevent those situations from happening before someone else comes around to blow it for you. IRC’s a great protocol to think about anonymity in, since there’s such a host of technical and social problems that might make things difficult.

Maybe I should start my own multi-part series on “Blowing Up People’s Anonymity” ;) .



How many passwords do you need to keep up with? Even if you’re not working in IT, with accounts on many systems, you might be surprised if you count them all up. You probably (at least) have passwords for your home, laptop, and work computers, email, banking, another one each for the bills you pay online. Then, most people will have a lot more: instant messaging accounts, web-based email, forums, social networking sites, online shopping, etc.

Along with this, we have what is considered to be good password policy, which most will agree goes something like “at least 8 characters, mixed case, digits, special characters”. If you have, say, ten different systems that you sign into, this becomes a burden. Memorizing one secure password isn’t so bad, but each additional one becomes more difficult to the point of being nearly impossible. A few things happen at this point for most people:

  • One strong password for everything – Obviously a bad idea, no matter how great of a password it is. Your security would rely on the weakest link of all the places you use that password. A compromise of a forum you read in your spare time’s user database winds up giving attackers the root password for mission critical servers.
  • Tiered passwords – One strong password for things that “matter” to you, and weaker “throwaways” for everything else. This isn’t so bad, but you still have containment issues if any of the important systems are compromised. The weaker passwords are easier to break, and the attacker may still be able to give you a bad day with just the “unimportant” sites.
  • Writing down passwords – A lot of people are going to tell you that this is a huge mistake. Realistically, this depends on your situation. Sticky notes on your monitor may be a bad idea if you’re in a large, open-plan office with easy access for the public. It might not be as bad if you work at home, assuming your monitor doesn’t face a window directly. Then you only have to worry about family and friends. In either case, an eastern European script kiddie isn’t going to be able to see them (unless, of course, you live in eastern Europe). Perhaps keep them in your wallet. Then you’ve narrowed it down to people who mug you.

In this post, I’m going to be discussing a way you can manage your passwords in a list, encrypted, and protected by a single master password that you must remember. With such a list, you’ll be able to use longer, more complex, and unique passwords for each of your accounts. The trade-off is that you will have put all of your eggs into one basket. Assuming your master password is strong enough, the attacker will need to compromise the system you store all of this on, and log you typing it in (at which point, you’re pretty much sunk anyway). This isn’t such a bad tradeoff.

In a discussion on the McGrew Security BBS the other day, a friend recommended “pwman” as a great application for this purpose. Pwman has recently undergone a Python-rewrite, and is actually very easy to use and tweak for your individual needs. I’ll discuss how to install pwman3 (the new python version) on Ubuntu Feisty 7.04, as well as the packages it depends on. I’ll also discuss a small modification I’ve made to pwman3 to make it generate more secure passwords.

Installing Pwman3

The Ubuntu repositories have pwman3 v0.0.5, so if you’re not up for a bit of tinkering, you can go ahead and “sudo aptitude install pwman3″ and be in pretty good shape. The latest version, which I’ll be using here, is 0.0.6, and is available here.

To get things ready, you’ll need a few dependencies. The pwman3 documentation says it needs “python-celementtree”, “python-crypto”, and “python-pysqlite2″. The first two are in the Ubuntu repositories, so you can go ahead and install them. “python-pysqlite2″ isn’t there, so download the latest 2.x.x release of pysqlite from here (2.3.3 as of now).

To install pysqlite 2.3.3, you’ll need to install “build-essential”, “libsqlite0-dev”, and “libsqlite3-dev” from the Ubuntu repositories. Once you have these dependencies, you can extract the pysqlite .tar.gz, and run the following in the directory that it creates:

sudo python setup.py install

Now, you should be all set to install Pwman3 0.0.6. You can extract it and install it the same way as you installed pysqlite:

sudo python setup.py install

Modifying Pwman3

Before we start using it, there’s something I’d like to change about pwman3. When you set it up to store a password, it gives you the option of generating a new password. This is a great feature, as you can potentially have some very secure passwords for each account you store in it. Unfortunately, by default, the password generation will only generate passwords that contain upper and lower-case characters. We can dramatically increase the difficulty of cracking these passwords if we add digits.

Take a look at /usr/lib/python2.5/site-packages/pwman/util/generator.py , which contains the password generation code. It’s well written and fairly complex. It seems there’s some functionality for “leetify”‘ing the passwords it generates with symbols, however I believe that I would prefer to have my passwords generated with “pwgen”, which is available in the Ubuntu repositories. Install pwgen and take a look at its man page to see how it works.

To make pwman3 use pwgen for password generation, make the following change to the generate_password function, which starts at line 40 of /usr/lib/python2.5/site-packages/pwman/util/generator.py :

def generate_password(minlen, maxlen, capitals = True, symbols = True):
    #(password, hyphenated) = generate_password_shazel(minlen, maxlen)
    #if (capitals):
    #    password = randomly_capitalize(password)
    #if (symbols):
    #    password = leetify(password)

    import subprocess
    p = subprocess.Popen(['pwgen','-scn',str(minlen)], shell=False, bufsize=0, stdin=subprocess.PIPE, stdout=subprocess.PIPE, close_fds=True)
    password = p.stdout.read()
    password = password[:minlen]
    hyphenated = password

    return (password, hyphenated)

As you can see, I’ve commented out the existing generate_password code. First, I start a new pwgen process with arguments for “secure” password creation, mixed case, numerals, and a minimum length. I then read the generated password from pwgen’s standard output, and remove the newline character. The “hyphenated” value that was generated by generator.py’s code doesn’t seem to be used by the rest of pwman3′s code, so I simply copied password into it, where it will be thrown away upon return.

By default, pwman3 supports a command history, which it keeps in ~/.pwman/history . This is probably a bad idea, as this plaintext file might reveal information about your accounts and activity, so open up ~/.pwman/config and change the “[Readline]” section to look like this:

history = /dev/null

You can now remove ~/.pwman/history

Using Pwman3

It’s very easy to use! It has a simple readline-based console interface, with help that displays a list of commands that are valid:

weasel@hacktop:~$ pwman3
Please enter your new password:
Please enter your new password again:
Pwman3 0.0.6 (c) Ivan Kelly <pwman@bleurgh.com>
pwman> help

Documented commands (type help <topic>):
EOF    delete  exit    filter  help    list  new     print  save  tags
clear  edit    export  forget  import  ls    passwd  rm     set

pwman> help tags
Usage: tags
Displays all tags in used in the database.
pwman> help filter
Usage: filter <tag> ...
Filters nodes on tag. Arguments can be zero or more tags. Displays current tags if called without arguments.

When you first use pwman3, it will have you chose a password to protect its password database. Make this password strong and memorable. From there, you can add accounts to the database with “new”, “edit” them, “filter” on tags, and “list” all accounts that match the current filter. To view more information on an account, you can “print” its number.

Thanks to all of the participants in the BBS for spurring discussion that can lead to posts like this!


So the smoke has cleared and the dust has settled on the judging, discussions, and drama surrounding the Southeastern Collegiate Cyber Defense Competition, and the final rankings have been released. We did better than we had been previously led to believe! The top three teams (out of 9 teams) are:

  1. Louisville
  2. UNC Charlotte
  3. Mississippi State

We wound up in third place! Not bad at all :) . Once again, I had a really great team with me at this competition and we both had a whole lot of fun regardless of how things turned out.

In other news, I have an official release, web page and all, for the NetBIOS Name Service spoofer that I have been posting a tutorial about over the last several days:



The Southeast Collegiate Cyber Defense Competition was a lot of fun! I had a great team on my hands that not only made the 16 hours of competition time manageable, but also made the trip, mornings, and nights a blast as well. We did not place, although I felt that we did an excellent job of defending our network against the Red Team. The competition was also about the business and systems administration side of things, however, and the focus on this was much higher than we had expected, having not attended the previous year. We weren’t as prepared in those areas as we were more concerned with security (our area of interest anyway).

It’s fine with me, though, as I didn’t mind not getting 1st through 3rd, so long as we didn’t get completely owned! I have a reputation to consider ;) . We had a lot of fun with it, and I think everyone we brought with us learned something new, often not even as part of the competition, but from our extensive discussions on the way up there and back.

UNC did a wonderful job of putting on the competition and it amazed us how much preparation went into putting it together. Everything went fairly close to schedule, and the judges had mountains of correspondence with the teams to sift through to make their decisions. All of the room judges and couriers were incredibly friendly, and the Red Team played the role of a proper villain and made a great presentation at the end.

The nights were fun, piled up in a hotel room doing last-minute research, preparations, and discussion. The last night there, we went and saw “300″ and it is every bit as amazing as everyone has stated.

Now that I’m back and getting rested up, I’ll be posting content again on a regular basis starting tomorrow!

© 2012 McGrew Security Suffusion theme by Sayontan Sinha