Unfortunately there’s no information about hash algorithms, or salt mechanisms.

The recently released Firesheep Firefox plugin demonstrates how simple it is to sniff logins and sessions on open, shared networks.  I spent a little bit of time playing with it; it is dirt-easy to install (OSX requires a workaround when running it in combination with FileVault — the fix is to move the extension directory somewhere outside of FileVault, such as the Firefox application directory in /Applications and to create a soft link back to the extensions directory.)  Although French ISPs are generally very good about providing their customers with home routers/firewalls with wireless encryption enabled by default, and it is thus pretty difficult in Paris to find open networks in comparison with other countries (except for the open access Free/O-Zone/SFR/etc. commercial ones), there are always a few.  Jumping on one of these, I had someone else’s Facebook account within 3 seconds (no, I didn’t use it, not that interested in other people’s private lives.)

In short, the plugin allows even a non-technical user to open a sidebar in a browser, click on “start sniffing”, and within fractions of a second, obtain both session cookies and username/password combinations for a wide range of popular web sites (Facebook, Twitter, and Gmail, among others, are configured by default, while the plugin allows easy adding of more pages.)  Sniffed accounts show up as icons on the sidebar — by clicking on one, you’re immediately logged into that user’s web account.

Taking this a step further, the (not as user-friendly, for now) Idiocy Python script (thanks to Thomas for pointing it out) automatically posts a link to this page “explaining what has happened” to a compromised Twitter account.

This is not entirely a problem of unencrypted wireless networks.  Any sufficiently determined user can attack a wireless network secured with WEP or certain types of WPA.  Even WPA2 may be vulnerable to brute force password cracking (standard password/passphrase best practice applies), although due to its key management methods, a compromised WEP environment allows a sniffer to access traffic from all users since the same key is shared.

Furthermore, malicious administrators with access to any sort of network choke point have access to this traffic anyway.  Most users are protected from such abuse by circumstance or pure statistics;

• many (especially European) countries have extremely strict limitations on what an employer can legally do in terms of intercepting traffic
• a network administrator likely has much better things to do than sniff traffic
• any choke point handling a large enough amount of data to be significant as a threat faces the above problem, but even more so

Security through obscurity is not a problem, but as has been pointed out elsewhere, if you’re in a group of people running from the bear, you don’t have to be fastest, just don’t be slowest.  Generally, any sort of network encryption (yes, even WEP) is a good start, and users of mobile data services and fixed-line networks are generally not at realistic risk.  WEP keys can be compromised in a few minutes under optimal conditions; using reinjection and deauthentication, enough packets can be captured reasonably quickly for this to work.  I maintain, though, that an attacker faced with an unencrypted network and even a weakly encrypted one will first go for the former — but a WEP network is only as secure as the most malicious person using it (whether they got on legitimately or not.)  Mr. Lakofski has a very valid point about shared WEP networks (e.g. hotels) insofar as their user base is a lot wider than a private one (which you should set to WPA2 anyway.)

Lastly, there are other, more amusing ways of collecting user data, beyond trojans, keyloggers, and this sort of thing.  A really amusing bit of evil villainery would have been for Eric Butler to have actually included a password stealing trojan in Firesheep itself — thus obtaining massive numbers of unsuspecting would-be crackers’ credentials as they connect to Facebook to boast about their “exploits”.  Yes, that would be illegal and bad, but still pretty funny.

Most popular websites allow SSL; Facebook, Google search, Gmail and Twitter all allow https:// connections (although in Facebook’s case, clicking on a Facebook link within the site redirects to a non-SSL page.)  Other services (LinkedIn, Amazon, Plaxo, and most social news sites e.g.) redirect https:// URLs to plain-text, at least for pages that do not involve entry of payment details or password changes.   Still others mix SSL- and non-SSL elements in their pages, which is about as good as having no SSL at all.  Most modern browsers, and some older ones, display a warning when this is the case.

Widespread SSL use is a good thing.  While it is computationally more expensive than cleartext, even SSL using self-signed certificates is an improvement — this is why I object strenuously to the way some browsers handle self-signed certificates; obnoxious warning messages discourage casual users from using crypto for the sake of crypto (rather than authenticating a web site.)  SSL is not necessarily a fix, due to the fact that a cookie not marked as ‘secure’ is still transmitted in clear text.  Once a user is authenticated, the certificate may be intercepted using passive man in the middle.  There is not much you can do about this, except to bug website owners / web app coders to fix the problem.

SSLStrip can also force a transmission to drop into cleartext.   One fix for this is Strict Transport Security, currently supported in several browsers.  FFixer also lets you force SSL (Facebook chat may not work.)  Another workaround is HTTPS-Everywhere (currently Firefox 3 only).

Gunnar Atli Sigurdsson of the University of Iceland has recently released FireShepherd, which floods nearby open wireless networks with packets designed to disable nearby Firesheep instances at ca. 0.5 second intervals.

Computerworld has an article about protecting against Firesheep that’s worth a look.

Update: the Blacksheep Firefox plugin seeds bogus session information to see if Firesheep is being used, then warns if it detects an attempt to hijack that session.  It’s not a defense, but could be a fun toy.

Die in a fire, you Nigerian shit.

The first symptom, as far as you can tell, is probably a bunch of your friends asking you casually, what the kind of crap is that you’ve been sending them.  It’s only when you ask them to show you the messages they’re referring to that you realize that some Nigerian, Russian, Chinese, (or, for that matter, American, French, Japanese, what-have-you) son of a bitch controls your account and is blasting out garbage to all your friends.

Even more nefariously, a lot of these are plausible-sounding messages, like one I received recently from an email contact purporting to be stranded in Madrid after his wallet, passport, keys, phone, and plane ticket were stolen, begging his friends to call him on a local number for instructions on how to wire some emergency cash.  Frequently, the only thing that gives such messages away at a cursory glance is the piss-poor spelling and grammar used by the scam artists responsible.

This post is sort-of directed at the non-technical people, who maybe don’t check their personal mails all that often.  Yes, it’s confusing, and yes, it’s not fair, and yes it’s hard work.  So are taxes.  If you’re not lucky, not only do all your friends now think you’re an idiot, but all your email has been deleted.

First, see if the mail is still around.  Check the trash and ‘all mail’ links.  Maybe you’re lucky.  Google does not restore deleted mail from backups.

To make sure nobody is able to hack your account again (i.e. with backdoors) go to

https://www.google.com/accounts/ManageAccount?service=mail&hl=en

Under “personal addresses” go to “email addresses” (top right).  Make absolutely sure that any addresses for which password recovery is enabled are only ones you trust.  Otherwise an attacker could just say “hey, I want a password reset sent to my address”.  Smart attackers leave their own addresses there.

To understand how this could have happened, here are some more common ways in which someone can “hack” your gmail account:

• trojan on your PC
• sniffed password (you do use SSL by default, right?  It’s a gmail option to always force SSL)
• sniffer on a shared system (Internet cafe)
• untrusted app
• xss / cookie stealing

Trojans

That is short for “trojan horses”.  These are often self-replicating viruses either downloaded from malicious web sites that were hacked (in some cases you won’t even know, you may be using an older browser like Internet Explorer 6) or via an unpatched Adobe Acrobat, or Flash.  May also come from someone attacking your PC by network, say in an Internet cafe.  You may not see these;  you open up a website like you usually do, but it’s been compromised, and boom, that’s it.  Invisible, annoying.  Or, your laptop/workstation may be attacked remotely, using a security hole in the operating system.

How to deal with them?  Regularly update your browser to the latest version and install operating system security patches.  Make sure you have an up to date virus scanner.  Do regular scans.  Turn on your PC’s firewall (google for Windows firewall or Mac firewall.  Both systems have a semi-decent one built in that will at least give you rudimentary protection.)  Avoid using open wireless networks and visiting sites you don’t know whenever possible.

Sniffed password

You do have a strong password, right?  Strong passwords have

• 8 characters or more
• a mix of upper/lowercase letters
• numbers thrown in
• non-alphanumeric characters (e.g. !, ?)

Use mnemonics to more easily remember passwords (Ih8h@ck3rs!) or pass phrases (actual sentences) if a website / application supports them.

Your password can still be stolen by being “sniffed” — this means that you are logging into Gmail without the connection being encrypted.  Have you bought stuff online and seen the little lock at the bottom of the page?  That means your browser is using encryption to make sure anyone listening in cannot “sniff” your password.  SSL, or “secure socket layer” is that little lock on the web browser.  To enable it by default in gmail, go to settings->general->browser connection.  Set it to ‘always use ssl’

Next, check your applications and make sure there’s only stuff there that you yourself enabled.  Delete anything you didn’t.

Lastly, on your gmail main page, go to google labs (the green erlenmeyer flask icon at the top right next to the “settings” link) and make sure that only labs apps you yourself enabled are active.  Deactivate all others.

Sniffing on a shared system / Internet cafe

Password sniffing is quite difficult when, say, you’re connecting from home.  It is _very_ easy when you are at an Internet cafe.  Wireless connections can be encrypted, via WEP or, better, WPA or WPA2, both supported by almost all wireless cards in laptops.  If a wireless connection requires a password, it’s usually at least somewhat safe.  WEP is not so much safe, but it’s better than nothing.  If you are at an Internet cafe using a common PC, you risk that someone will have installed a piece of software that can “read” whatever password info you type (known as a “keylogger“).  There are ways to ensure that this doesn’t happen (e.g. the system is reinstalled from scratch after each reboot — not so complex) but that is tough.  Your best defense is to buy a small netbook or something and take it with you.

When using an Internet cafe, never click anything that offers to remember password.  When you log out, always clear any stored information, e.g. cache, passwords and cookies.   Here is a link that explains how on various browsers.

Furthermore, most modern browsers have a feature called “private browsing” or some variation thereof.   This means that nothing is stored while you’re online.  Use it.

Untrusted applications

See above with google apps.  Also, when you download software or docs, obviously never run/open anything you do not explicitly trust.  Have a good virus scanner, run it regularly.

Cross-site scripting (XSS) / cookie stealing

Cookies are bits of information that websites use to remember things about you — for example, when you log into amazon and return later, a cookie is what is placed on your PC to let you auto login again.

These can be “stolen” and used to impersonate you, i.e. when you use an Internet cafe system.  To help protect against this, whenever you are done browsing, manually log out of everything, and go to your browser’s “clear history” link (e.g. on Firefox, under tools-> clear recent history).

They can also be stolen while you are online, although that is a bit more complex.  XSS is “cross site scripting”, which basically means that if you have a browser open and visit a trusted site in one window and a malicious site in another window (again, the “malicious” site may just have been hacked and not be aware of it) the guy who has taken over the “bad” site can intercept and steal your session with the “good” site.  This is probably where most google account hacks come from.

To guard against that, when you log into gmail or another service, make sure it’s the only browser window you have open; don’t multitask with several tabs unless it is to visit sites you know are legitimate.

This can all happen even if you take all due precautions, but it is rare.

Also, regarding passwords, make sure you have a STRONG one.  I.e. at least 8 characters, alphanumeric, mixed case, some special symbols thrown in (!?*whatever) and nothing that could be tied to you (name, birthday, etc.)  Use a mnemonic (i.e ilikechinese -> 1l1k3ch!n353!)

A precaution:  back up your email account.  Here are 3 million search results for “gmail backup”.

From my latest victim friend:

Thanks for helping me John – it’s been a fucking nightmare as a freelance writer – I’ve lost so much material!

The same thing can happen with Hotmail, Yahoo!, LinkedIn, Facebook, Plaxo, anywhere you store large amounts of contact info.  Standard precautions apply.  And as always, nothing is foolproof.

Authentication Basics 101

First, some three-point lists to re-hash the elements of authentication, mainly for my own memory-jogging purposes.

An individual who wants to gain access to data or facilities goes through a three-stage process:

• Identification (”Hi I’m Bob!  Let me in!”)
• Authentication (”OK, I verify that you are indeed Bob.”)
• Authorization (”Bob, I verify that you are among those permitted to enter.”)

Authentication can be done using any combination of the following three ingredients:

• something you know (e.g. password, PIN code)
• something you have (e.g. key, smart card)
• something you are (e.g. fingerprint)

It’s been a given for a while that two-factor authentication is a good way of massively raising security of information or premises at a comparatively low cost, by reducing the impact from losing or disclosing any part of the authentication process.  If I drop my access badge on the train, big deal, because I also need a secret passcode to enter the office.

Some Problems (PKI / Certificate Example)

As a quick side-track, during every single PKI-related project involving token-based authentication (usually smart cards) that I’ve ever worked on, two major issues inevitably arose:

First, how do we adapt peoples’ credentials to changing circumstances.  For example, the subject marries and changes their name.  Signing keys used in authentication certificates can be expired or revoked, even though this requires maintenance of a functioning certificate revocation list, something a lot of enterprises don’t seem to be capable of, and which can be technically daunting in any case once you start dealing with multiple thousands of revoked certificates.  However, data signed and encrypted before the expiration or revocation date must be accessible or verifiable in perpetuity, no matter if Jane Smith is now called Jane Smith-Jones.

Continuing the certificate example, this is solved by using something like friendly names on certificates (where the user’s name is not part of the certificate’s LDAP distinguished name (DN), or unique numerical identifiers that are mapped to an actual name in a database accessible by other applications that use the certificate.  There are many ways to skin a cat, or a user who changes their name.  However, this falls squarely into the “bad planning” department that seems to be an attribute of many PKI deployments; architects often don’t make allowance for future requirements, such as extended key attributes (thanks for the tip, Arjo), thus raising the need for additional certificate rollouts and system redesigns.

Second, what happens when the user loses his chip card?  No problem, get him a new one.  Even better, prevent him from losing it in the first place, by combining his authentication token with something he is definitely not going to forget, like the bathroom access pass or his lunch card (but whatever you do, please PLEASE don’t put the company logo or address on his access badge.)

What to do, though, when he’s on a service visit to a missile silo at the North Pole, or with a client in Colombia, and can’t access his laptop?  What about one-man branch offices in Timbuktu?  This is where we start facing increasingly complicated problems with issuing emergency credentials via cell phones (a great medium for secondary authentication — they’re tied to a person, they’re at least somewhat secure against casual attackers via GSM encryption and PIN code access, and they’re one of the least likely items to be forgotten at home.)

Moving beyond the scope of digital certificates, biometric authentication offers a tempting solution for both of the above problems..  Passports can be forgotten, passwords extorted, and unless you’re using a system that doesn’t check for heat or blood flow (useful in the case of the Malaysian Mercedes owner several years ago whose fingers were severed by robbers to gain access to his fingerprint-protected car) or which can be fooled by fake biometric credentials, biometric authentication immediately and reasonably reliably identifies and authenticates a user in one go.  Unless he loses his hands or voice or has his eyes gouged out, but that eventuality doesn’t look so nice in the authentication product marketing brochure, so we’ll conveniently ignore it.

Passwords are Annoying

Passwords have their own problems; I agree that people should use pass phrases instead of passwords whenever possible [1],[2].  Furthermore, I believe that excessively strict password complexity and rotation rules lead people to do stupid things like (with all due respect to Bruce Schneier) writing down passwords in obvious places.  Very few individuals have the time, knowledge or intelligence to write down passwords in a way that keeps them safe (plus, the “YOUR PASSWORD WILL EXPIRE IN 5 DAYS” warnings on Windows workstations tend to catch people when they’re most stressed and hurried to log in and get to their meeting.  Furthermore, password vaults tend to be impractical if, like me, you access similar resources from different workstations, laptops, interfaces, etc.

Biometric authentication gets around all this; in the case of a lot of low-end applications, such as unlocking laptops, it is a thoroughly convenient mechanism that allows administrators to get around the expense and complexity of dealing with things like BIOS/startup authentication, or the aforementioned user failings in dealing with password security rules.

So Where’s the Problem?

There are a number of classic arguments against biometric technology — principal among them being that, in case of identity theft, it is not possible for a user to change his credentials, ever.  My major objection to most uses of biometric authentication, however, is the excessive trust placed in it, combined with the absence of non-repudiation.  While most technologies involved are technologically sound and deployed in a well-meaning manner, these related failings bear the probability of inevitable negative, unintended side effects.

By virtue of its perception as an advanced, “futuristic” technology, there is a tendency to ascribe some degree of infallibility to biometric authentication.  Errors are viewed as improbable; since there are no longer external factors (knowledge or objects) involved in authentication transactions, the person logging in with a thumbprint must perforce be the owner of the thumb who was registered as such.

As an analogy, DNA matching by police suffers from a similar weakness; first, we cannot discount concerns about false positives.  Even if there is a one-in-a-billion chance that a DNA sample from a crime scene matches an innocent person as well as the perpetrator, statistically this may be acceptable, but wouldn’t it suck if you were that innocent person?  Is this tolerable?  Furthermore, as the John Schneeberger case demonstrates, even if the technology were flawless, completely circumventing the context within which DNA matching functions, by means of such shenanigans as introducing fake DNA, the entire usefulness of an otherwise good system is thrown out the window.  This is similar to the famous analog hole argument about why media digital rights management is a fundamentally broken concept; even if the hardware and software works just fine, a method completely out of its scope will render its deployment irrelevant.

In the case of biometric authentication, there are a number of conceivable (and, in my case, for lack of greater expertise, purely theoretical) situations where its employment breaks down; this xkcd cartoon demonstrates one such eventuality in a fairly insightful manner.  Given that many people will be subconsciously awed and intimidated by the cool sci-fi retinal scanners at airports, or palm readers in front of offices, this translates into a disregard for the possibility that something will go wrong with the system — dangerous because, even if the security of the system itself were flawless (which no system is) it can probably be circumvented, somehow.  This brings us to the second, and greater danger, that of the lack of non-repudiation in biometric authentication.

By means of overview, digital identifiers are used in two related but different ways to determine the authenticity of data — signing tells the recipient of data, “the information you received is the same that was sent, and it is I who sent it.”  This comes in the form of MD5 checksums, PGP signatures, etc., or in archaic terms, the royal seal on an envelope — in x.509 terminology, signing keys with an authentication bit set in their certificate containers are normally used for certificate authentication (as the key is used to sign a set of credentials transmitted to an application and to guarantee their inviolability.)

Non-repudiation means that a recipient of information can be assured that the originator cannot deny that he provided certain information; the recipient can prove that something not only originated with a given person, but that person is not able to reneg on the information.  Signatures on credit card slips or notarized contracts are the most common real-world examples of this.  There is a subtle difference between the two — signing assures the recipient that information and sender data are correct, non-repudiation guarantees the recipient that the sender will abide by the terms of the information received.

Authentication by biometrics introduces the idea of non-repudiation into a transaction where it usually has no business.  A user is first identified, then authenticated.  Both of these components of the authentication transaction three-step process take place using the same single medium — part of the user’s body.  This is bad.  As the user is identified as who he is, the authentication process suddenly and automatically includes an audit trail — which cannot, by definition, be contested.

When John Smith, average employee, sits down to log into his company workstation, he enters his username and password.  Even though his username may be “smithj”, which is tied his employer’s Active Directory to his username and photo, the disconnect between the person and the authentication framework means that he is not treated as an individual, but rather as an anonymous construct that possesses, hopefully legitimately, John Smith’s authentication credentials.  Can I prove that someone did not steal John Smith’s username and password?  Not really.  Maybe he wrote it down — perhaps that’s a firing offense in itself, but there is at least the reasonable doubt that it was he who logged in.

Not so with biometric ID.  The moment he swipes his palm across the door entry plate, or looks into the airport retina scanner, even if there is some doubt that it is, indeed, John Smith requesting authorization, that doubt enters the realm of the statistically irrelevant.  Fine for criminal prosecution, but decidedly suboptimal if you are John Smith who spent his Sunday in bed with a book rather than breaking into his workplace with a fiendishly clever copy of his thumbprint, or by jury-rigging the actual scanner with a battery and a bunch of wires.  The fact that it was a physical part of John Smith that was used (in the mind of the authentication system) to open the door or unlock the workstation means that the audit trail automatically associates him with his action.

This extends to a person’s movements between countries, his use of a cell phone, his travel in a car, his purchasing habits — all of which can be plausibly denied and repudiated if physical or virtual items, such as passports and PIN codes, are used to authenticate the user.  Identity theft at this point may be unlikely, but fatal for the victim.

How to Fix This

Biometric authentication is not fundamentally bad.  It has its place, if properly planned and implemented, and if the consequences of its use are known.

For example, authentication can be insular and local.  That is, the process does not register a user’s physical characteristics anywhere centrally, but rather uses a locally cached checksum of, say, a thumbprint to unlock a laptop or smart card — similar to what many Windows-based thumbprint login mechanisms already use.  A kerberos exchange is made with a domain controller, as with a username/password or smart card login, but the actual physical characteristic is not associated in its “raw” form with any central user profile.

Second, biometric authentication must absolutely under no circumstances be tied to audit trails; the tracking of a user’s actions and movements is information desired by law enforcement, human resources, marketing wonks, scammers and any other number of other parties, but there is no reason to tie a user himself, through his physical qualities, to his actions.  I want to be able to deny that I used my credit card in Indonesia last Tuesday; the moment this ability falls due to the authority of a retinal verification for a card transaction that was somehow falsified, I have a huge problem.

Next, such authentication must not cause anyone to come to harm.  As with the Mercedes example above — people are (usually) more important than objects or data.  If you evaluate your security needs and believe it’s a good idea to force someone to go through a burly Secret Service guy to get to the nuclear launch codes, that makes sense.  However, endangering someone’s safety for a car or laptop when it’d get stolen anyway, no matter what they do, would be callous and pointless.

Lastly, authentication credentials must not be tied to any other stored instance of a person’s biometric information.  This sounds paranoid, but physical characteristics, since as we see above these are refutable only with difficulty, and credentials can’t be changed.  The instant someone is able to abuse biometric credentials, a user’s entire financial credibility, his workplace history, and any number of other valuable combinations of reputation and resources may suffer.

Entirely browser-based, and hacked together by a bunch of Portuguese guys in what seems like a few drunken afternoons, it’s a brilliant business model — basic access is free, and a monthly ~3 euro fee unlocks additional buildings, more bases, etc.

The setup is straight HTML; bases and ships maneuver in a coordinate grid (e.g. B23:45:72:13 is server beta, galaxy 23, region 45 on a 10×10 grid, system 72 on a 100×100 grid, planet/moon 3 in the first position from the star.)  Everything consists of straight hyperlinks; for example, I could paste B23:45 into the in-game message board, and it would show up as a link to that region.  Combat, movement and pretty much all other aspects of the game are paleolithically basic (for example, combat is based on a constantly shifting set of formulas involving various ship values, the timing of a player’s clicks on the “attack” link and, probably, sunspots and the like.)

Due to time constraints (you pretty much need to be an unemployed hyperactive, highly bored insomniac to have any hope of competing as I found out when my latest attempt at building a fleet was bushwhacked as I peacefully slept), I’ve since deleted my account and moved on, so the following screenshot is a stock image from their tutorial.  An example from Alpha galaxy, region A00:44:

Each of these systems is clickable.  Systems and the entire galaxy are similar.

However, despite its simplicity, it lends itself to all kinds of “politics” (13-year-olds posturing on the game forums) and abuse of technology, including the creation of off-server base coordinate databases, greasemonkey formatting and information management scripts, auto-scouting and -playing programs that emulate browsers, etc.

While my in-game guild, unlike some others, never used “robot players”, our auto-scouter, which wrapped around Internet Explorer libraries and involved a fairly sophisticated target selection and database upload mechanism, let users specify any combination of locations to check for enemy bases and fleet strengths; a web-based database search could generate graphs, travel times, even lists of enemy player/guild capabilities in Excel format.

We ceased using this when a number of our players started being banned for using scout bots, restricting ourselves to a greasemonkey script that uploaded any information a player manually clicked on.  Numerous theories were kicked around, including number of hits from a given client within a 24-hour period, failure to take into consideration a string component in the target URL for a certain planet, etc. — turns out the admins had resorted to the basic-but-annyoing trick of creating “fake” planets, invisible in maps like the above, but still present in the HTML source as links.  Any scout bot unaware of this would not be able to differentiate (for example, a workaround would involve checking for the presence of one of a number of stock images for planets before following a link); the ID of the player “clicking” on this coordinate would be flagged for review.

Needless to say, the potential for abuse is pretty big, with players sending each other these links via in-game messages masked with tinyURL in order to get someone to click and be flagged as a “cheater.”  This took the place of other, equally annoying tools, such as messages containing web bugs (all messages are also html formatted) in order to track players’ online times or source IPs.

The best exploit of all came in the form of a fully functional illicit auto-scouting and information formatting script widely used by AE players — most of the, I won’t say “cheaters”, but let’s call them “those willing to obtain advantage through technical means”, in the playerbase are fairly technically illiterate, prepared to install pretty much anything that will provide an advantage.

That advantage goes both ways:

On some level, you’ve gotta admit the elegant simplicity of it.

On 28 August 1999, Chile adopted privacy protective legislation. Law 19628 provides a set of detailed guidelines, principles and rules relating to the gathering, use, processing, storage and export of personal data. To be legal, all the above acts require the person’s written consent. The law does not create a data protection authority. Its application is monitored by ordinary courts. Personal data registrars are bound to respect professional secrecy rules. Data subjects are entitled to access and correct the data relating to them and to claim compensation where loss or damage is suffered as a result of the use or disclosure of such data. Infringement of the legislation entails administrative, civil and penal liability. Special provisions apply on financial, commercial, banking and medical data.

Gotta love the absence of a data protection officer. The law also does not specify penalties like the UK Data Protection Act or Swiss law. To be fair, I think the Argentines also only have something basic on the books.

Why is this fun? Well, like everyone here, we are in possession of a “cedula de etrangeros”, or a “papers pliss” kind of mandatory national ID card. The “RUT”, which I can only assume was originally some sort of pension information, serves as a universal identifying number. All government agencies are tied into the database containing these — companies also have these, as well as some contracts. It’s used it for taxes, pensions, passoprts, etc. etc. etc.

(Yes, that is a Cedula above; the smudged bit is my RUT, and I’m not going to put you through the agony of my ugly mug more than once on this page.) So, what’s the deal?

The RUT isn’t just used by the government, but by your bank, insurance and other organizations as an ID. Sounds good, except that it’s also your supermarket loyalty ID, your video club membership number, and your identifier for anything you can possibly imagine–it’s given openly over the phone, the Internet (often via unencrypted authentication elements even in SSL-protected pages), to the pizza delivery guy, you get the idea. As it turns out, everyone who asks for your RUT (i.e. everone) has full access to the RUT database (or whatever it’s called).

Bills of participating enterprises are payable online via two websites, one of which, when I logged in (using my RUT as user ID, with a 6-digit numeric password, no more are possible, and it only works under IE, let me check out my entire phone history for the month. What’s interesting is that at first I typed in the wrong phone number — and got someone else’s entire call history, along with their name, address and, you guessed it, RUT.

At risk of sounding like I’m scoffing — I’m not, just incredulous — this is in an environment where I’m asked to put two pen dashes across the face of a signed check “for security” because, as we all know, once you’ve written over a check, it can’t be forged. When confronted with the incongruity of this, at least two people I spoke with responded with some variation on “but this is South America / Chile.” It could never happen here.

In absence of enough time to put together a properly thought-through post, I’ll leave it to you, dear reader, to come up with your own conclusions as to the potential for identity theft once someone cottons onto the fact that English (and extremely poor Dutch and German) aren’t the only language in which a lot of gullible, not-terribly-technical people do business online.