Everything In Between

This evening over dinner after Poly-NYC‘s “Politics and Passion” meeting, I found myself in an unexpected debate over Internet ID, part of the US government’s plan to centralize Internet identity mechanisms. Although this is actually old news—over a year old at this point!—fears about it seem to be cropping up again this week on places like Reddit, and my Google searches return this 6-day old FauxNews article that links to a 12-month old CNET article cross-posted at CBSNews. (And, as an aside: WTF, Fox‽ You really are a piece of shit “news” network, aren’t you?)

Maybe what gave some people a new injection of Internet ID-induced fear was the fact that the truly horrid SOPA and PIPA Internet censorship laws were in the news this week thanks to the #SOPAStrike Internet blackout (which I enjoyed participating in). Or maybe it was because the latest versions of the Internet ID specifications are nearing their release date, so everyone’s a little on edge.

Whatever it was, though, I think that fear is misplaced. Most of this fear seems to stem from a real misunderstanding of the way Internet identities (not just Internet ID itself) work. Like so many things involving computer network security, something like Internet ID can sound scary when you’re not up on the nitty gritty details—that’s nothing to be ashamed of. Knowledge is power, and lack of knowledge breeds fear.

But Internet ID, or more formally known as National Strategy for Trusted Identities in Cyberspace (NSTIC) is actually not something to be fearful of. In fact, it could be a really good step forward, one that many Internet security, privacy, and free speech experts seem pretty excited about. And, what’s more, they have been for quite some time.

For example, Kaliya Hamlin is founder of the Internet Identity Workshop and an Internet identity expert who’s formally weighed in on NSTIC. She’s also a personal friend and someone I greatly trust to handle these matters with a lot of care, specifically to people who express an alternative sexuality. She’s done so time and again.

But don’t take my word for it! Listen to her thoughtful inclusion of how Facebook’s privacy-degrading actions late in 2009 would affect closeted users on Kink On Tap Episode 21: Welcome to the Privacy Wars. Her fantastic year-old piece, National! Identity! Cyberspace! Why We Shouldn’t Freak Out About NSTIC is still highly relevant today:

Our main conference Internet Identity Workshop held every 6 months since the fall of 2005 has for a logo the identity dog: an allusion to the famous New Yorker cartoon On the Internet, nobody knows you are a dog. To me, this symbolizes the two big threads of our work: 1) maintaining the freedom to be who you want to be on the Internet AND 2) having the freedom and ability to share verified information about yourself when you do want to. I believe the intentions of NSTIC align with both of these[…].

As another high-profile example, computer and Internet security expert Steve Gibson also recorded a netcast that dealt directly with NSTIC and explained it in remarkably clear detail. He dissected the way it functions, why it’s useful, where it can be improved, and what the big fears about it were.

Gibson rightfully concluded the fear is largely due to ignorance of the technology and a general mistrust of the government, but that the technical specification as it exists today is so good as to actually prevent the majority of the fears being espoused by people like those I spoke with who have not actually taken the time to grok the specifics. Here’s an excerpt from the transcription of the netcast:

LEO: I know some people, the idea of government doing this makes them nervous. To me it actually seems sensible because you need a centralized third party to certify it.

STEVE: Yes.

LEO: And I know people, a lot of people who listen to this show, don’t trust our government. And we probably shouldn’t trust government. But who better? I mean, you want Microsoft to do this? They have been, by the way, with little success. So I think it needs to be that. And then I think this is a nice – you liken it to certificates, and I think that’s a good – the web certificate system, I think that’s a good analogy. I think it makes sense to have third parties that are certified and that kind of thing. I’m excited. We needed this. I’ve been signing my email for years, to no avail. It’s all been the Web of Trust technique.

STEVE: Yes. And this document establishes the right principles. I mean, and I’ve read the whole thing. Everything about it, as I’m reading – and I’m skeptical of Big Brother, too. I don’t know how we’re going to do it. I mean, as a coder and technologist I think about all of the hurdles and the pitfalls and the challenges we face. But it’s clear that we need that. We need this in order to move forward and to really leverage cyberspace to the full extent possible, I mean, we have the technology.

LEO: Yes, yes. Identity is critical. We’ve learned that lesson. And anonymity, while you – I think this is nicely done because you can have anonymity.

STEVE: Yes.

LEO: But there’s also a way to certify you are who you say you are. And I think you need both. So I think this is good. This sounds – I’m excited.

STEVE: Yeah, me, too.

The nice thing about technology such as that being built by NSTIC is that, unlike the need to rely on flimsy promises of the government’s benevolence, we can actually audit the specifications and open-source implementations of these technologies ourselves. And many people do. Steve Gibson did, and I trust him.

None of this is to say there are not valid concerns—there are. For one, Trusted Identity Providers are still going to be privy to most everything you do with one of your Internet ID identities, but I don’t see how that’s any worse than what we have today: your ISP, your DNS provider, and countless third-party advertising companies can and are tracking everywhere you go on the Web today. NSTIC, on the other hand, could give users like you and me both the technical and legal ability to have more fine-grained control over what such third parties see about us as we use the Web.

Technology that puts users back in charge of their identity? Now that’s an Internet law I can be proud of.

So, as I said in the discussion over dinner earlier tonight, rather than spend our time wringing our hands over this Internet ID stuff, we’ll all be far better off saving our energy to fight foolhardy initiatives like SOPA, PIPA, and other forms of political, social, and technical censorship.

Internet ID/NSTIC is not an enemy. It is going to be an important and useful tool for users like you and me.

One of the oddities of Apple’s Mac OS X platform is that some things that should be easy are obtusely difficult, and remarkably so. Changing the hostname of a Mac OS X Server is one good example. Another is changing the “Ethernet ID” (aka. MAC address, aka. link-level address) of a network interface card.

This should be really simple, as the correct command line is plain as day (where the string of colon-separated 00′s is your preferred MAC address):

sudo ifconfig en1 lladdr 00:00:00:00:00:00

There are numerous blog posts all over the ‘net that tell you this time and again, but each one seems to have comments from users complaining that it doesn’t work on their system. I ran into a similar problem not long ago when my MacBook Pro didn’t do what I expected. Just like others, whenever I tried to run the above command, nothing seemed to happen:

ifconfig | grep ether # Determine current MAC addresses
sudo ifconfig en1 lladdr 00:00:00:00:00:00 # Try changing MAC address for en1 (usually Airport)
ifconfig | grep ether # Confirm change; but uh-oh! Output is the same as before! Why?

Here’s how I fixed this problem.

The thing to know is that there seem to be a number of conditions that will prevent Mac OS X from successfully changing a NIC‘s MAC address. Some are obvious and some are not. As far as I can tell, these conditions are:

• having the interface “down” (i.e., if you’ve recently run ifconfig en0 down or an equivalent),
• being associated with (i.e., connected to) a Wi-Fi network with your Airport card,
• having the System Preferences application running,
• forgetting to “unstick” the current system configuration set.

It’s the last one that bit me. Mac OS X has a feature called “system configuration sets” or “locations,” as it’s termed in much of the GUI. These can be accessed via the Network pane in System Preferences, or via the scselect command from Terminal; it’s that scselect command which offers the key to changing a Mac’s MAC address.

On my MacBook Pro (which, for the record and if it matters, is running Mac OS X 10.6.7), I need to do all of the following before running ifconfig, as shown above:

• If I’m changing my Airport card’s MAC address, I need to disassociate from any network. (This can most easily be done by invoking airport -z from Terminal. If you don’t have this command, see my tips on where to find airport.)
• Quit System Preferences if it’s open.
• Tell the operating system to “delay changing the system’s ‘location’ until the next system boot” by running: scselect -n.

According to the man page for scselect:

scselect provides access to the system configuration sets, commonly referred to as “locations”. When invoked with no arguments, scselect displays the names and associated identifiers for each defined “location” and indicates which is currently active. scselect also allows the user to select or change the active “location” by specifying its name or identifier. Changing the “location” causes an immediate system re-configuration, unless the -n option is supplied.

[…]

-n Delay changing the system’s “location” until the next system boot (or the next time that the system configuration preferences are changed).

Once I perform the above rigmarole, I can then change my MAC address without issue. But I have to be ludicrously careful. As soon as I open the Network System Preferences pane or otherwise do something to change the system configuration preferences, I have to run through that rigmarole again before changing my MAC address will work as expected.

While working on $client‘s Linux server last week, I found myself installing a cron job that ran as root. The cron job called a custom bash script that, in turn, called out to various custom maintenance tasks client had already written. One task in particular had to run as a different user.

During testing, I discovered that the odd-ball task failed to run, and found the following error in the system log:

sudo: sorry, you must have a tty to run sudo

I traced this error to a line trying to invoke a perl command as a user called dynamic:

sudo -u dynamic /usr/bin/perl run-periodic-tasks --load 5 --randomly

A simple Google search turned up an obvious solution to the error: use visudo to disable sudo’s tty requirement, allowing sudo to be invoked from any shell lacking a tty (including cron). This would have solved my problem, but it just felt wrong, dirty, and most troublingly insecure.

One reason why sudo ships with the requiretty option enabled by default is, among other reasons, to prevent remote users from exposing the root password over SSH. Disabling this security precaution for a simple maintenance task already running as root seemed totally unnecessary, not to mention irresponsible. Moreover, client‘s script didn’t even need a tty.

Thankfully, there’s a better way: use su --session-command and send the whole job to the background.

su --session-command="/usr/bin/perl run-periodic-tasks --load 5 --randomly" dynamic &

This line launches a new, non-login shell (typically bash) as the other user in a separate, background process and runs the command you passed using the shell’s -c option. Sending the command to the background (using &) continues execution of the rest of the cron job.

A process listing would look like this:

root     28109     1  0 17:10 ?        00:00:00 su --session-command=/usr/bin/perl run-periodic-tasks --load 5 --randomly dynamic
dynamic  28110 28109  0 17:10 ?        00:00:00 bash -c /usr/bin/perl run-periodic-tasks --load 5 --randomly

Note the parent process (PID 28109) is owned by root but the actual perl process (PID 28110) is being run as dynamic.

This in-script solution that replaces sudo -u user cmd with su --session-command=cmd user seems much better than relying on a change in sudo‘s default (and more secure) configuration to me.

Clickjacking or, more formally, user interface redressing, is a class of security vulnerabilities similar to phishing scams. The technique uses web standards to trick unsuspecting victims into performing actions they were not intending to.

Clickjacking does not rely on bugs in any software. Instead, the technique is simply an abuse of the growing graphical capabilities that advanced web standards like CSS provide to web browsers. A good introduction to clickjacking is provided by Steve Gibson and Leo Laporte on their Security Now! podcast.

As far as I’m aware, only Firefox when combined with the NoScript add-on and Internet Explorer when combined with the GuardedID product provide any measure of protection against clickjacking attacks. To date no other browser can detect, alert, or otherwise help you to avoid or mitigate the risks of clickjacking attacks.

That said, there’s gotta be something users of other browsers can do. Well, it may not be as much as what NoScript can do, but there is something: use a user style sheet to help expose common clickjacking attack attempts.

clickjane.css helps detect clickjacking attacks for all browsers

Until browser manufacturers provide built-in protections against clickjacking attacks in their software (which is arguably the best place for such logic in the first place), I’ve started putting together a user style sheet I’m calling clickjane.css that attempts to instantly reveal common clickjacking attempts. Since it’s a CSS user style sheet, this approach should be cross-browser compatible so that users of any browser including Safari, Opera, and other browsers that don’t have other means of protecting against clickjacking attacks can use it.

I’ve only recently learned about this class of exploits and so I’m not supremely well-informed on the topic. As a result, the clickjane.css file is relatively sparse and currently only reveals what I’m sure is a small set of clickjacking attmpts. However, as I research the topic further and learn more about the actual underlying HTML and CSS that clickjacking uses, I’ll be updating the clickjane.css code to reveal those attempts as well.

Naturally, contributions and assistance in any form are most welcome! Learn more about clickjane.css as well as how to use it at the Clickjane CSS Github wiki.

Before and after clickjane.css

Here are two example screenshots of a benign clickjacking demo.

1. Before:
   

   Screenshot of Safari before clickjane.css is used to expose clickjacking attempts.

2. After:
   

   Screenshot of Safari after clickjane.css is used to expose clickjacking attempts.

Good habits you should get into to mitigate clickjacking risks

Here is a list of behaviors that you should make habitual while you browse the web. Engaging in these behaviors can dramatically reduce the likelihood that you will be victimized by a clickjacking attack.

• Explicitly log out of any service you have logged in to when you are done. That log-out button is there for a reason: use it!
• Avoid providing your browser with “Auto-Complete” information for critical sites, such as your bank.
• Make sure you are running Flash Player 10 or greater, which mitigates this vulnerability for Adobe Flash content.

More resources to learn about clickjacking

• Hackademix.net – More clickjacking links to the OWASP presentation, the white paper, and a blog post showing several CSS-based exploits.

Translations of this article:

• Belorussian (thanks, Bohdan Zograf)
• Ukrainian (thanks, Alyona Lompar)

Creative agency management tool company Workamajig.com is a sizable operation with an international client base. Their product used to be called “Creative Manager Pro” which I can only assume they changed because it wasn’t actually creative enough. Anyway, it turns out that Workamajig has what is without doubt the absolute worst error message I can possibly think of from a security standpoint.

The error, which is triggered on login regardless of whether or not the username and password you enter are correct (presumably because the issue occurs while trying to authenticate), displays the username and the password the user has entered in cleartext and then (as if that wasn’t bad enough) encourages the user to email this information to their support department!

Yes, we have made the company aware of the problem. No, they have not fixed it yet. Proof in the form of a screen capture from literally 10 minutes ago:

Workamajig.com login error echoes the entered password in cleartext and encourages the user to send this to their support via email.

No, these are not real credentials, but an uninformed user may very well enter access credentials that are valid. Since this issue is not triggered by invalid credentials, that means valid login information for god knows how many Workamajig user accounts is very likely sitting in the SMTP logs of countless mail servers. Since in many countries these logs are federally mandated to be saved for at least two years, if I were a user of Workamajig I would seriously consider changing my account password ASAP, as well as changing any other account that I used the same password for!

I can’t be sure from this screen shot, but I sincerely hope that user’s passwords are passed around in the application as well as stored on disk as salted cryptographic hashes. Of course, after seeing this, I wouldn’t be shocked if that wasn’t the case. The good news is that the login screen to their application is only accessible with an SSL/TLS connection, which does prevent someone from snooping on the wire. Nevertheless, there are still many attack vectors that SSL/TLS doesn’t protect against if the rest of the application is not secure or, say, if you’re encouraged to bypass those protections by sending emails with sensitive data in order to request technical support.

Anyway, hopefully this gets fixed sooner rather than later. At the very least, don’t encourage users to email cleartext passwords. That is pretty much always a Very Bad Thing.

Update: It took only a couple of days for Workamajig to notice this blog post, which is great because it means I woke up to a forwarded email in my inbox in which a Workamajig representative said:

On the issue of showing the user id and password in an error message, [we] will be changing the way that error message is displayed. […] Just to clarify the user id and password is just on the screen of the user that is logged in, and that message to copy and paste is a standard messages and it is just intended for you to copy and paste the error message; you are not required to send the user id and password.

I haven’t encountered the same issue again (but then again I only tried to login to my account twice in between then and now), so I can’t verify that the error message really has changed but I’d give Workamajig the benefit of the doubt. If you’re using Workamajig and notice a change in the way this login error is handled before I do, leave a comment to let me know it’s really been changed.

Nary a day goes by when I don’t use my computer for some extremely personal stuff. I would consider it a Very Bad Thing if some of this information (my bank account details or private SSH keys, for instance) fell out of my control.

Everyone has sensitive files that they keep on their computer and, fortunately for Mac OS X Users, Apple has made it ridiculously easy to create a cryptographically secure containers for such files. You can think of a container like this, which is just a standard Mac OS X disk image (.dmg) file, like a vault that you open, put stuff you want to keep safe inside, and then close again.

Here’s how you go about making and using one.

Create the container, an encrypted disk image

1. First, open up your copy of Disk Utility.app, which is located in your computer’s /Applications/Utilities folder. (As an aside, this program is a bit like a swiss army knife for handling disk operations in Mac OS X. You should definitely find out what else it can do).
2. Next, select the File → New → Blank Disk Image… option. This will cause the New Blank Image window to appear.
3. Fill in the typical details such as the disk image file’s name and where you want to save it to. In addition, you’ll be presented with a number of options such as Volume Name, Volume Size, and Image Format. The defaults are usually adequate except for Volume Name, which you should customize so that when you mount the disk image the disk label is meaningful for you, and the Image Format, which I recommend you switch to “sparse disk image.”

   Sparse disk images can start small and grow automatically as you write more files into them. If what you want to keep secure in this manner are very large files, say gigantic high resolution PhotoShop documents, then you might consider the sparse bundle disk image format instead.

   Also, obviously, set the Encryption to a value other than “None.”

   Here’s an example screenshot from my Mac:

   

   Screenshot of the New Blank Image window showing meaningful values entered, Encryption field set to 128-bit, and Image Format field set to sparse disk image.

4. Press the “Create” button and you’ll be presented with a standard password selection dialogue. This is the password you’ll use to mount the disk image and is analogous to the idea of setting the combination on your vault’s lock. It’s critical that the password you choose is a good one. Ideally, your password is a totally random string that may include any printable character. Since that’s hard to remember, you can have the Mac OS X keychain manage your passwords for you.

Encrypt some files by writing them to the disk image

Now that you have an encrypted disk image, a secure container for your sensitive data, you can make use of it just as you might any other disk image on Mac OS X. For instance, say I have a top secret file called “My Killer Business Plan.pages” and I don’t want anyone to get at it. All I need to do is copy the file into my encrypted disk image, as the following screenshot shows:

It should go without saying that you want to delete the original, unencrypted copy of the file you’re copying into the encrypted disk image, but I’ll say that anyway. Don’t leave unprotected copies of your files lying around. Also, be certain to unmount (eject) the disk image when you’re done using it because the only thing the password protects is opening the disk image, not the files contained within it.

External references

Here are some additional places where this technique is discussed. Check out these additional articles about this topic elsewhere for more information and other perspectives:

• Mac OS X: How to create a password-protected (encrypted) disk image
• Mac OS X: About Encrypted Disk Images
• MacOSXHints.com: Create an encrypted disk image that grows as required

In some communities, this is sort of old news, however I’ve recently become aware of an exciting and affordable security product called the YubiKey, manufactured by Yubico. The YubiKey is a $35 USD one-time password second-factor authentication token that uses 128-bit AES encryption to provide identity verification. That’s a mouthful, but what it really means is this: using a YubiKey to log in to stuff makes your logins about as secure as a military installation. Here’s how.

When you log in to just about any Web site or Internet-enabled service, say Basecamp for example, you traditionally simply type in a user name and matching password. This is known as one-factor authentication because all you need to do to log in successfully is use a matching pair of user names and their passwords. Since the user name is not hidden, the only piece of the puzzle that’s providing any security is your password.

Now, a password is something you have to remember, so this factor is called "something you know." Of course, if someone else also knows your password, this means that person can log in pretending to be you. Thus enters the need for a second factor for authentication.

The YubiKey is a physical USB fob device with a unique ID. That is, each YubiKey in the world has its own ID, meaning that no two are identical. This implies that if you have a YubiKey with you, no one else can have that same YubiKey anywhere else in the universe. Thus, this gives you a second factor with which to authenticate yourself, specifically it’s "something you have."

When you combine something you know (for instance, a password) with something you have (such as a YubiKey), you have two-factor authentication. Authenticating yourself with both of these factors is obviously more secure than relying solely on one factor because in order to compromise it an attacker needs to compromise both factors; the attacker would need to know what you know (figure out your password) and steal something you have (physically obtain your YubiKey).

If you’re familiar with one-time credit cards such as those that PayPal offers, you can think of the YubiKey like one of these cards, but instead of being used to make online purchases, it’s used for logging into stuff (and, of course, you don’t need more than one physical YubiKey). Of course, for authentication to work with the YubiKey the application or service you are logging into has to be able to understand that you’re using one of these authentication devices.

The good news here is that the entire process of using a YubiKey is a well-documented, open-source, and open-spec scheme so it’s easy for service providers to implement. And, because Yubico is also an OpenID identity provider, you can use your YubiKey to log into any site that supports the OpenID protocol right now, such as (you guessed it) Basecamp! There’s even a WordPress YubiKey plugin so you could theoretically use your YubiKey to secure your authentication to any of your WordPress blogs.

The YubiKey spec is, itself, completely independant of the OpenID spec and vice versa, which is what makes the combination so formidable. What’s so cool about this process is that the site you’re authenticating to, such as Basecamp or your WordPress blog, doesn’t have to know anything about how you’re authenticating because the OpenID provider (Yubico in this example) simply returns the answer—a perfect example of a well-constructed API at work. Either you have successfully authenticated to your OpenID provider or you haven’t, and the site can respond accordingly.

And if that’s not cool enough, want to know the coolest thing about the YubiKey? It’s environmentally friendly! The YubiKey web site states that the robust, ultra-thin and battery-free design increases lifetime and reduces environmental impact.

I’m more than seriously considering getting one of these myself, and even beyond that, getting one for all of my fellow site editors on some of the community web sites I help maintain. This is especially important for sites dealing in confidential or otherwise sensitive information, such as those which hold financial records or have other privacy concerns. Securing the authentication of privileged users such as the site administrators seems a natural step.

Even better yet, because the only cost to implementing this system is developer resources and the cost of the physical YubiKey device, I’m also seriously considering baking this right into any new sites I develop. At $35, a YubiKey is actually cheaper than an SSL certificate, and even though they don’t protect against all the same attack vectors, I think a device like the YubiKey is clearly a vastly superior solution in the majority of use cases.

I never really had a compelling reason to begin to propagate an OpenID identity before but now, at last, I do.

Security provisions are one of those “things” that Mac users have been snooty about—for good reason—for decades. However, I’d dare say that, even though the UNIX architecture of the underpinnings of Mac OS X is much more secure than most other popular operating systems (cough, Windows, cough), much of the security benefits that Mac users have enjoyed are really security-by-obscurity, which is not very secure at all. With the added popularity of Mac OS X, lots of responsibility suddenly shifts from the vendor (Apple, Inc.) to the individual users (this means you) to keep your data secure.

Apple has been on point, however, providing good security utilities built right into the operating system and easily available to end users. Of most common use is probably “Secure Empty Trash” which securely deletes files that you put into the trash. The counterpart to this function available in the Finder is, too few Mac users know, the srm or secure remove command-line utility.

srm can be thought of as simply a version of rm that overwrites file data before unlinking it from the file system. It comes with a few more options than rm comes with all geared towards tweaking just how it overwrites files. My favorite is -m, which the manual page says:

overwrite the file with 7 US DoD compliant passes (0xF6, 0×00, 0xFF, random, 0×00, 0xFF, random)

I had the perfect occasion to use srm today: I was transporting my SSH private key from one laptop to another via a temporary drive. I wanted to securely remove all traces of the private key file from the temporary drive after installing it in the new computer. (See this SSH public key tutorial if you don’t know why this might be important.)

After copying the private key file over, removing it securely looks like this:

srm -m private_key_file

It’s that easy.

To be confident that your file is truly overwritten with garbage, you can use the -n option. This is one way to retain a file, but completely corrupt it. Observe:

Meitar:~ meitar$ cat testfile
Hello world.
Meitar:~ meitar$ srm -mn testfile
Meitar:~ meitar$ cat testfile
?
 ?)c?I
      P?Meitar:~ meitar$

That garbage you see after the second invocation of cat shows that the file really was trashed, that is, overwritten with garbage data. Now, a simple rm testfile can do the rest of the work.

As always, man srm will give you all the other juicy details.

Since Mac OS X 10.2 Jaguar, Mac users have been accustomed to the ease of use of Apple’s very cool Keychain Services technology. The Mac OS X Keychain basically a secure database of all your passwords, sorted into files called (unsurprisingly enough) “keychains.” Each user account on a Mac OS X system has a login.keychain, and the system itself also has a system.keychain.

Whenever you tell an application to “Remember this password in my keychain,” what you’re doing is writing a new encrypted entry into your user account’s ~/Library/Keychains/login.keychain file. Then, the next time the application needs to access a restricted resource, it just asks Mac OS X to get the password for it. Of course, all of this happens automatically, so except for that single checkbox most users probably don’t know that the keychain even exists.

What’s even more awesome than all of this automagic password storing action, though, is the fact that Apple has also provided an easy-to-use application to manipulate the keychain yourself. What good does this do us? Plenty! Observe.

Say you’ve just signed up with a new ISP. They send you a username and a password to log on to their ADSL network with. Of course, they send this password to you on paper—how insecure! Instead, after changing the password to something else first (something other than mypassword, which is the example password I’ll use here), we can use Mac OS X Keychain to securely store the password and retrieve it later.

1. First, launch the Keychain Access application located in the /Applications/Utilities folder of your startup drive.
2. Next, click the “Create a new Keychain item” button (the +) button near the lower left-hand corner of the window. The Add Keychain Item sheet appears.
3. Enter a meaningful name, such as “ADSL ISP Account” in my example, in the Keychain Item Name field.
4. Enter the username or account name associated with this password in the Account Name field.
5. Enter the password into the Password field.
6. Click the Add button.

That’s all there is to it. To later retrieve your password if, say, you ever forget it:

1. Launch the Keychain Access application.
2. Locate and double-click the keychain item that stores the account and password information you want to retrieve.
3. Tick the “Show password” checkbox. You’ll be presented with a dialogue box that asks for your keychain’s master password. Unless you’ve already set it to something else, this is the same password you use to log in to your Mac OS X user account.
4. Enter your keychain password and click “Allow.” If you click “Always Allow” instead, Keychain Access will not prompt you for your login keychain’s password the next time you ask to see this particular password. I never press that button.
5. Your password’s plaintext is now visible.

This effectively obviates the need for third-party applications such as Password Gorilla, PasswordWallet or KeePassX which are great programs, but all suffer from a lack of a good user interface. Furthermore, there’s no reason why we can’t store short arbitrary strings of sensitive information in the keychain temporarily. Sure, it might clutter up your keychain, but you can always search the entries using the standard Mac OS X filter search bar at the top right of the window.

In fact, Apple’s been kind enough to offer an interface to do just that in an even more effective way, called Secure Notes. These are simply plain text strings of arbitrary length that can be stored securely inside your keychain, and that use the same interface to access (requiring your password to view). The only real difference is that instead of a single line, you’re given a fully scrollable text area in which to type your secure note.

Moreover, because keychains can be synced to multiple Macs with .Mac Sync (or a third-party synchronization solution), you can always have access to all your passwords regardless of which physical Mac you’re using. Best of all, since you never have to remember another password ever again, you can quit using the same password for multiple accounts, and you can always use really hard-to-crack passwords.

If you are wondering why it seems that everyone today is so defensive, you need look no further than your own television set, or newspaper. Bruce Schneier says it best: stop the war on different. And, going hand-in-hand with that slogan: refuse to be terrorized.