Many users and forum programs in attempt to make automatic e-mail address harversting harder conseal them via obfuscation - @ is replaced with “at” and . is replaces with “dot”, so

bill.gates@microsoft.com

now becomes

bil dot gates at microsoft dot com

I’m not an expert in regular expressions and I’m really curious - does such obfuscation really make automatic harvesting harder? Is it really much harder to automatically identify such obfuscated addresses?

For example, if every email address on a large community site is reversed in the markup and rendered properly with CSS, or token-replaced (@ becomes ‘at’), or any other predictable method, the harvesters will just write a thin adapter for your site.

Think of it this way: if it only takes you one line of code to “scramble” them sitewide, it will only take the harvester one line of code to “unscramble” them for your site. Roughly speaking.

What concept is the right? Do more complex obfuscation or consider about new ways?

Obfuscation techniques fall in the same category than captchas. They are not reliable and tend to hurt regular users more than bots.

Javascript obfuscation seems to be praised, but is no silver bullet: it is not that hard today to automate a browser for email sniffing. If it can be displayed in a browser, it can be harvested. You could even imagine a bot that’s taking screenshots of a browser window and using OCR to extract addresses to beat your million-dollar-obfuscation-technique.

Depending on where and why you want to obfuscate emails, those techniques could be useful:

• Restrict email visibility: you may hide emails on your website/forum to anonymous users, to new users (with little to no activity or posts to date) or even hide them completely and replace email contact between members with a built-in private messaging feature.
• Use a dedicated spam-filtered email: you will get spammed, but it will be limited to this particular address. This is a good trade-off when you need to expose the email address to any user.
• Use a contact form: while bots are pretty good at filling forms, it turns out that they are too good at filling forms. Hidden field techniques can filter most of the spam coming through your contact form.

One common way of hiding email from bots and spammers is to create an image containing the email address. Facebook does this, for instance. Now, using images for email is inherently bad for accessibility, because text readers will not be able to read it. But even otherwise, there are several free character recognition programs that do a pretty good of decoding such email-images.

At least you have always to keep in brain that if it’s difficult for the spammers it’s as well your users to identify the email address. A nice article from wikipedia on Email obfuscation or address munging you’d pay regard to.

The real question is whether the extra effort will be put in by harvesters and if the (major? minor?) barrier to the harvesters is worth the possible problems for your users.

—

Finally this article is as so many about fighting spam - In my opinion, spam has become such a problem and so many databases have been turned over that we’re beyond hiding our addresses. Instead, consider of more efficient ways of classifying and blocking spam.

So, for the reason that quite a while ago my external HD crashed; I do not think that that might be of value or interest to people reading my blog; I have to tell you something. While it turns out I didn’t lose any data, thanks to my backup stategy I improve from time to time.

I bet anyway some of you probably don’t have a backup solution for your machine. Don’t tell me I didn’t warn you when your HD crashes. And it will crash, it’s just a matter of time!

Some years ago, after a very time-consuming loss of data, I wanted to solve this new problem of backing up data in the best possible way, so I started researching all this stuff that I never really paid attention to before. I started looking into external HDs, NAS boxes (because it would be cool to stream data to my home network in addition to providing storage for my PC), RAID, and everything in-between. But it probably took a weekend of research into these things before I realized the the simple yet so very important distinction between data redundancy and data backup.

As you probably know there are different RAID-Levels most of them provide besides an improvment of read/write speed a data security.

Redundancy is something you get e.g. by having two or more HDs in a RAID1 or RAID5 configuration. If one HD fails, you can recover your data from the other HDs, either due to mirroring or due to having a parity disk that will allow your data to be recreated. However, this is not a backup!

If your whole PC is fried, or whatever it might be, your data is irreparably lost. Backup is something that should protect you from data loss even in the case of a severe hardware failure.

My solution is very simple provided by rsync that copies data from one pc to another (via ssh). Very simple - but just as effective & safe.

When thinking about backup solutions I got this obviously overstated idea: If my backup files are in, let’s say Hong Kong while I’m in Nuremberg I’ll be able to recover my files even if Nuremberg falls into the ocean from a earthquake (assuming I survive the ordeal).
Okay, you’re right - I’m loosing track of reality, of course that’s not necesarry at all. Just a few years ago this would have been inconceivable for private purpose but nowadays it’s not such a bad idea…

Nevertheless I continue in copying data to a machine that’s just a few arm length from my workstation.

Your password is like a key to your account, you need to safeguard it. Anyone who has your password can get into your account, and your files. Anyone who can guess your password has it. Anyone who has your password can pose as you.

There are a few basic parameters about strong password you’d take notice of.

Don’s use passwords that match any of the following:

• Words in any dictionary.
• Your user name.
• Your real name.
• Your spouse’s name.
• Anyone’s name (crackers don’t necessarily know that your aunt’s middle name is Agnes, but it’s easy enough to get a list of 100,000 names and try each one).
• Any word in any “cracking dictionary.” There are lists of words that crackers use to try to crack passwords: passwords that a lot of people use. Some of these lists include:
  

  Abbreviations, Asteroids, Biology, Cartoons, Character Patterns, Machine names, famous names, female names, Bible, male names, Movies, Myths-legends, Number Patterns, Short Phrases, Places, Science Fiction, Shakespeare, Songs, Sports, Surnames

• Any of the above, with a single character before or after it (”8dinner”, “happy1”).
• Any of the above, capitalized (”cat” –> “Cat”)
• Any of the above, reversed (”cat” –> “tac”), doubled (”cat” –> “catcat”) or mirrored (”cat” –> “cattac”).
• We used to tell people that taking a word and substituting some characters (a 0 (zero) for an o, or a 1 for an l) made a good password. This is no longer the case. New crackers have the capability to crack things like this, in certain situations.
• Words like “foobar”, “xyzzy” and “qwerty” are still just plain words. They are also popular passwords, and the crack programs look for them. Avoid them.

—

Basically it’s recommented to have a password that

• …is at least six characters long. This should be long enough to discourage a brute-force attack.
• …is a mix of lower- and upper-case characters, numbers, and punctuation marks.

—

A good trick for remember a strong password is the use of an uncommon phrase, and take the first, second or last letter of each word. “You can’t always get what you want” would yield “ycagwyw”.

The best passwords are those which are totally random to anyone else except you. It is difficult to tell you how to come up with these, but you’d be able to do it.

—

Generate a random password:

Automatic password generation tools available in debian are for example:

• APG (Automated Password Generator)
• pwgen generates random, meaningless but pronounceable passwords.
• Trigraph Password Generator generates pronounceable passwords.

My favorite tool is pwgen. It generates random, meaningless passwords but uses letter and number combinations that can be pronounced and memorized. Simply typing “pwgen” and hitting Enter will shoot back a screen full of passwords to choose from, helping to prevent shoulder-surfing sneaks, but you can easily hone down and customize the results with a few command-line switches.

—

A strong password is sufficiently long, random, or otherwise producible only by the user who chose it, such that successfully guessing it will require more time than the password cracker is willing to use guessing it. The length of time deemed to be too long will vary with the attacker, the attacker’s resources, the ease with which a password can be tried, and the value of the password to the attacker.

—

You can test your new password with Password Checker. Password Checker is a non-recording feature on this website that helps determine your password’s strength as you type.

—

What to do agains the attacker trying to crack your password using rainbow tables?

A rainbow table is a pre-computed table that greatly speeds up a search for a password with a given hash value. It is specific to one hash function, and usually restricted to passwords of a certain length and sometimes character set, e.g. alphanumeric passwords of up to 8 characters hashed by MD5.

The salt is important because you often hear about community boards that have been cracked and all user passwords stored in the database are stolen.

For an example how to use md5 checksums with salt you’d consider this (in php):

<?php
 
function encryptPassword($password) {
   $salt = 's+(_a*';
   return md5($password.$salt);
}
?>

—

Do not type passwords on computers that you do not control if you aren’t pretty sure about the provided security. Computers such as those in Internet cafés, computer labs, shared systems, kiosk systems, conferences, and airport lounges.

Don’t take one and the same passwords for different matters. A big fault can be to register in a community with an email address and set the same password for the community login as for the email account. Obviously preventing this should be self-evident nevertheless I’m sure many people don’t even think about.

At least, the first and most important, always to keep in mind, rule is NEVER to give your password to anyone. You can have the strongest password ever which is useless if known by anyone.

—

What to do if your password is stolen?

Imagine the not desirable case that someone has stolen your password. After changing it you be sure to monitor all the information you protect with your passwords, such as your monthly financial statements, credit reports, online shopping accounts, and so on.

Everybody knows well about the issue of SQL injections.
True, but why is SQL injection still occurring? Isn’t everyone validating all user input these days?

For example say you have a logon form that accepts a user name and password. Once authenticated against the database, the application then sets a session value, or some other token for allowing the user to access the protected data.

Take a logon form for example, here you have two basic form elements, a textbox for accepting a user name, and a password box for the password.

<form action="admin.aspx"> 
<input name="username" type="textbox" /> 
<input name="password" type="password" />
<input type="submit" />

The code behind might be something like

String sQuery = "SELECT COUNT(*) FROM Users WHERE UserName = '"+username.Text+"' AND Password = '"+password.Text+"'";

SQLCommand cmd = new SQLCommand(sQuery, Connection);

int n = cmd.ExecuteScalar();

When entering “‘ or 0=0 –” into the username field the query looks like that:

SELECT COUNT(*) FROM Users WHERE UserName = '""' OR 0=0 --

which always would return the number of users.

As you can it’s just minor effort to see data of a database you are not supposed to see.

But also more bad things can happen to your database for example the following can kill lots of data.

'; drop table users --

Also the report of errorcodes can be very helpful for attackers. There’s a whole bunch of lists on the net what error code is related to which area in the server/database structure.

sQuery = "SELECT COUNT(*) FROM Users WHERE UserName = '@username' AND Password = '@password'";

SQLCommand cmd = new SqlCommand(sQuery, Connection);

cmd .Parameters.Add ("@username", SqlDbType.VarChar).Value = username.Text;

cmd .Parameters.Add ("@password", SqlDbType.VarChar).Value = password.Text;

cmd .Parameters.Add ("@return", SqlDbType.Int).Direction = ParameterDirection.ReturnValue;

int n = cmd.ExecuteScalar();

This is only one way the secure your web apps - by passing parameters you avoid many types of SQL injection attacks.
Finally, ensure you provide very little information to a potential attacker when an error occurs.