Nincompoops!
Recently, a list of 78+k password hashes to various Finnish internet forums was posted on the net. Apparently a number of bulletin boards were hacked, and the password hashes extracted. Some passwords were actually plaintext, suggesting that some software even stores passwords in plaintext.
The most striking aspect of the list, however, is the fact that a huge portion of the password hashes are not using salts. That is just plain depressing. How to properly compute and store password hashes has been know for decades, but still incompetent programmers keep repeating the errors of history.
There is a lovely English word for the programmers who have omitted to use proper password encoding methods in their forum software. “Nincompoops”. You know who you are. Shame on you!
2006-08-28The 2006 Stupid Security Competition
Privacy International has again opened the Stupid Security Competition for entries. I foresee that they will have no lack of potential winners this time around, take a look.
Looking at the numerous egregiously stupid security measures that have been executed during the last few years, I am stunned. I don’t know if I should laugh or cry, or both at the same time.
The award categories are:
- Most Egregiously Stupid Award
- Most Inexplicably Stupid Award
- Most Annoyingly Stupid Award
- Most Flagrantly Intrusive Award
- Most Stupidly Counter Productive Award
I wish the competitors good luck; in many categories the “security” organizations of several Western countries will give each other a good run for the money. I predict a shut-out; all categories will be won by bodies who can be traced back to one organization.
2006-05-17“Would you like some fish with that Chip & PIN?”
It is with a small amount of thrill that I have followed recent news about “chip and pin fraud”. Users of new chip and pin debit cards have experienced the rather unpleasant surprise of having their alledgedly secure card cloned and promptly misused abroad.
First of all, my sincere sympathy to anyone hit. I know what it feels like, as I had to change my credit card after fraudsters ran up a significant bill in just a few hours on my old one.
Another thing which should be made clear right now is that there is nothing fundamentally wrong with the chip and pin technology itself. It is still a reasonable substitute for the old magstripe and signature system. So what is wrong, then?
Time after time, I emphasize that one of the typical causes of security failures is change. This is exactly what has happened here. In the original magstripe system, the pin code was used quite rarely and even then in “trusted” enviroments—such as ATMs. Some fraudsters were able to use high tech gear to copy both pins and the magstripes, but this was rare. So rare that the losses were acceptable. But even then, it took years of suffering customers before banks even admitted the problem existed. So what changed?
With the chip and pin system, the already dubious concept of “trusted terminal” is outright foolish. Banks still claim “tamper proofness” and other silly stuff, but the fact is that there are too many terminals around to properly secure them. Every bar, gas station, diner, laundry shop, tailor, etc. will eventually have a terminal. Put it another way—there will be many untrustworthy terminals.
During the transition period from magstripe to chip and pin, cards will have to carry both systems. The US inability to convert rapidly to chip and pin extends this transition period further. The problem is that the pin code for the magstripe just must not fall into the wrong hands. Together with the magstripe, it’s just begging to be abused.
The banks were faced with a tough choice. Either have customers remember two pins, or use the same pin for both magstripe and the chip. With one pin, card cloning was inevitable. The banks weighed the pro’s and con’s and decided to go for a single pin.
The banks made a deliberate choice to temporarily risk the cloning of magstripe cards, hoping that the losses could be silently covered. Their gamble has backfired, and now they are facing a real PR nightmare. Customers are losing confidence in the chip and pin system, even though the real problem is with the magstripe system.
If magstripe fraud continues to rise, banks are faced with only two alternatives. Either they have to issue cards with two separate pins, or they have to remove the magstripe.
Some day, I may just dig into the bad implementation of wireless chip and pin readers. But that’s another story.
2006-03-21Backups for the Digital Photographer
Petteri’s Pontifications is definitely a site about photography worth a few hours of your life. Recently, Petteri seems to have been busy revamping his digital darkroom, and this includes doing a write-up on Information Security for the Digital Photographer. This inspired me to write a few lines about my own backup solution.
Some background. I have a collection of DV tapes, mostly with the usual shots of my children growing up. Currently, this amounts to roughly 200 GB of data. My DSLR camera produces an astounding amount of data on a constant basis – at this time I think my photo collection clocks in at around 30 GB. Add in a few system files, a bit of software and games, and I have a fair amount of data to back up. To put it another way – DVDs feel like floppy disks did a decade ago.
Harddrives fail. They fail often. In my case, I have lost about three drives a year—two years running. That includes both laptop drives at work and PC drives at home. Right now my Linux firewall is doing its best to keep up that track record. In my eyes, this makes single hard drives bad options for backups.
A key question you must ask yourself is “When disaster strikes, how much am I prepared to lose? A week? A month? A year? Or three year’s work, as a relative of mine did?” The answer to the question determines how often you back up, and how often you off-site a copy of your backups.
Another important question is “How far back do I want to be able to go in history?” Disaster strikes rarely, but errors happen often. You will want to restore individual files one day.
Backups need to protect against errors. The simplest form of backups retain only one copy—the latest one—of each file. The downside to this is that any corrupted files you back up will overwrite a perfectly good copy. Why is this relevant, you ask? Well, hard drives that fail tend to start out by corrupting files. Another important source of such errors is humans. If you overwrite the wrong file and don’t realize it until you overwrite your good copy, again you lose.
I needed a backup solution with the following properties:
- Effortless
- Fast in daily use
- Reliable
- Retains history
- Scales in capacity
- Robust on-line solution
- Many off-line alternatives
I have a NAS unit, currently a 1 TB TeraStation set up in a 750 GB RAID5 configuration. Any NAS disk would do, but RAID is a big plus. Some people prefer Firwire or USB2.0 removable drives, but my history with harddisks is not…encouraging.
I use EMC Retrospect to back up daily. The daily backup runs in 10-20 minutes, and covers all changed files on my workstation. The backup includes full verification of all copied files. Retrospect retains copies for each day of the last week, each week of the last month, and as many months as fits on the backup drive. I tried other, “cheaper” solutions first. My advice is: get a good solution right away. For instance, Acronis had the habit of first destroying the old full backups before starting a new one. If I interrupted a full backup, I effectively lost that backup set. Not reassuring.
When I download photos from my CF cards, copies are automatically made to the NAS unit. These copies are retained in addition to the actual backups.
My off-site solution is still in flux. Currently I use Retrospect to backup my photo collection to DVDs. Whenever a DVD fills up, about once a month, I can carry it to off-site storage. The DV stuff is too much data for this, so I just off-site the original DV tapes and hope they don’t rot [they will]. I am considering a removable disk as an alternative.
2006-02-10Using Petnames for Security
When I worked on my Master’s Thesis back in 1998 [wow, time flies], I spent quite a lot of time understanding the security semantics of names and naming schemes. At the time, I looked at SPKI/SDSI and X.509, and learned a lot. The whole concept still intrigues me, because it is at once very simple and very complex.
To put it simple, names cannot at the same time be global, secure, and memorable. You can only have two of the three, which is why SSL certificates have failed to provide protection against domain name based spoofing attempts.
Enter petname systems. The concept itself is not new, and was well understood when Ron Rivest worked on SDSI. Or at least that is what I believe, because I understood it back then.
But enough theory. Try it out yourself. Install the petname Firefox extension. It’s simple to use, and simple to understand. When you go to an SSL site for the first time, you give it a petname. From then on, you should always expect to see your petname when you visit that site. If the name does not show up, you see “untrusted” instead—a clear hint that something is wrong.
For you security geeks out there, this may be just the Thing™ to help your aunt, uncle, or whatever to avoid falling for phishing attempts. Perhaps even the best thing since sliced bread. Not that I like sliced bread.
2006-01-09Windows Active Directory authentication and Apache — SPNEGO
Today I had the opportunity to look into how to get AD authentication to work on Apache running under Linux. The last time I looked must have been some time ago, because back then the answer was “not possible”.
To make a long story short, Kerberos authentication works with most modern browsers. You just need to configure both the web server and the browser to understand and use it. In effect this enables the SPNEGO, or “Negotiate”, protocol.
The catch with using SPNEGO is that you don’t want your browser automatically sending your credentials to just any web server out there.
- With IE, you must add the necessary servers to the “Intranet zone”.
- With Firefox, you must configure the trusted sites in a user
preference
pref("network.negotiate-auth.trusted-uris", site-list); pref("network.negotiate-auth.delegation-uris", site-list);
I would steer clear of using the delegation-uris option unless you really know what you are doing.
Configuring Apache requires a module which implements SPNEGO. This would be mod_auth_kerb. Debian provides this in libapache-mod-auth-kerb, other distros are bound to support it as well.
2005-11-11The Joy (?) of Plug-In Patching
It looks like we are having a “fry the end users” week. FlashPlayer, RealPlayer and QuickTime all have vulnerabilities that allow remote code execution. The timing is important, unfortunately. These browser plug-ins are very popular, and I would bet most users have all of them installed. RealPlayer and QuickTime have automatic updaters, so a fair share of users is going to be protected quite soon. FlashPlayer has to be updated through a separate download, so it will take a while before that fix gets around.
The important thing to realize is that for any given site a user visits, there is currently a rather high probability that at least one of these plug-ins is vulnerable to attack. There is a window of opportunity of a few weeks, perhaps months, when attackers can penetrate most end-user PCs. This is not good. If I can see this coming, so can the attackers.
Update your plug-ins NOW!
2005-09-21Firefox 1.0.7 fixes IDN
A full fixed version of Firefox 1.0.7 is now out. It didn’t take nearly as long as the Firefox developers seemed to indicate at first. Perhaps they came to the same conclusion as me, eventually.
κυδος! (Kudos)
2005-09-13Firefox IDN buffer overflow
I am a strong supporter of IDN (Internationalized Domain Names), for a fairly obvious reason. Support for IDN has been shaky, however, as Microsoft has failed to support it promptly. Just goes to show that Microsoft still doesn’t handle internationalization properly.
A recently discovered IDN vulnerability in Firefox prompted the developers to temporarily disable IDN support in Firefox. This is yet another delay in the deployment of IDN, and it seems that we will have to wait for a fix until the next Firefox release.
I think that the Firefox developers made a mistake here. They should fix their bug and distribute a fixed version, not just suggest that people disable a feature. Most users would upgrade to a next point release, but I fear that many will not implement the smaller fix. This leaves a large population of Firefox users vulnerable for an extended period of time. I can already see the Firefox developers scrambling to get a proper fix out when a wide-scale exploit surfaces.
Bad call, guys. You just put your reputation on the line. Here, let me get this said ahead of time: “I told you so!”
2005-04-13Risks of Biometric Passwords
EPIC has released a good analysis of the security of RFID-equipped biometric passports. It seems that the american authorities continue on their blatantly incompetent course on privacy matters.
Let’s hope that biometric passports issued in the EU are better.