Salt’n Pepper on passwords; spicy enough ?

You heard a lot about it and, let’s face it, from time to time, you talked about it yourself with a cute touch of self-confidence that usually makes you sound like you know what you’re talking about. But salt & pepper ? On passwords ?

Is it safe ? Is it safe ?

All right, if you’re under 30 you didn’t get the joke, but i don’t really mind. Let’s first talk a bit about passwords because, let’s face it, you know for sure the weak link won’t be your code, but the fact that people tend to use their birthdate or kids name for passwords. So how can you make sure it is safe ?

There’s no such thing as safe

This is your first mantra : THERE’S NO SUCH THING AS SAFE PASSWORD; cracking a password is always a possibility, and only a matter of time and will (of course, i’m talking about regular security; don’t post a message telling that a self-destructing database after one password error is safe…and it’s really not, btw).

Whether you know exactly how or not, password encryption is actually become quite good; with a sh*tload of mathematics, prime number compositions, and so on…What you need to know about it is that they’ve managed to create an encryption system that is not a bijection (meaning there’s no algorithm — at least it hasn’t been found — that can take you from the encrypted password to the original password). What it means to you is that your passwords should be protected against brute force attacks.

Brute Force attacks

A brute force attack is encrypting every possible string until the encryption you get matches the encrypted password; it’s called brute force because it’s as brainless as it is ruthless, enough time given. Theoretically, it can’t miss…but it can take days or weeks. And because it’s long, crackers (i.e. people hacking passwords) have developed strategies to get faster where they want to go.

Dictionaries

Simple, neat, elegant. They try real words; they can even choose a most-likely-to-be-used language; so if your usual password is « password », « secret », « admin », « poodle » or « steam-pipe »,  you may want to reconsider (you also may want to reconsider being a software developer anyway). There’re also first name dictionaries out there so, unless you named your kid « @3#dZgv4éS4″ (poor child), you want to avoid first names.

Character tables

Most crackers are not trying to get your password; trey try to get any password; whether it’s yours or not is completely irrelevant. So, since they try to get as far as they can, they brute-force-attack the weakest passwords, in terms of brute-force-attack strength. That means that they try to crack the passwords with the weakest combinatory, ergo the less amount of different characters.

For example, if you can only use the letters A and B to create a four-letter password, possible passwords are very limited :

AAAA, AAAB, AABA, AABB, ABAA, ABAB, ABBA (waterloo), ABBB, BAAA, BAAB, BABA, BABB, BBAA, BBAB, BBBA, BBBB = 16 cases

If you only add the letter C, you get 81 cases. Add D and you get 256 cases. Now make the password five-lettered and you get 1024 cases.

What they do is, they try all possible passwords, from 1 to 14 characters, using all the letters of the latin alphabet, both uppercase and lowercase ( so A to Z and a to z ) as well as digits ( 0 to 9 ). If your password is less than 8 characters and only using those characters, it’s a matter of seconds. That’s exactly why you’re usually told to use other characters, such as ponctuation marks ( ! , ? # – _  @ $ an so on).

Databases

Because crackers are usually anything but morons, they chose to do it another way; they’ve created a database, where they store all possible encryption; they have tables with — to make it simple — two columns : the first one is the original password, the second one is the encrypted password (they usually have one column per encryption mode; so there’s one MD5 column, one SHA1…). But since it’s impossible to store all the possible strings (because they’re limitless, duh !), they had to narrow it as well. So it may seem that the problems are still the same, but they’re not.

First of all, the attack is completely local, a simple query on a database, not the kind of things that make the feds loof after you); second, it’s incremental, they constantly add new passwords. But it also gets larger and larger (meaning they need huge hard drives — which is not a problem anymore, thank you cloud computing — but also the queries get longer time to get executed — you can’t imagine the size of the indexes).

So…is it safe ?

To sum it up, it’s not less safe than before, given the fact that you protect yourself properly. If you use long passwords, with all different kind of characters and symbols, you should be fine. But your users, they hate it ! And remember this : they consider that security is your problem as they’re being the weakest link in your security chain (those bast*rds !!!).

Salt & Pepper

Actually it’s pepper and salt, but we’ll get to it. So the question is : how can you enforce users to use strong passwords ? Many different strategies here : you make them change every month (lame), you show them a green light when their password is strong enough…There are many ways, we’ll only talk about our favorite : the DIY password strengthener…

Wouldn’t it be great if you could change passwords to stronger passwords ? That’s exactly what we’ll do. It’s not a new idea (if you ever heard of public/private key exchange, it’s not the same at all, but it will help you to understand the deal), but it’s smart enough and, if you do it right, it’s a hit.

Your user is asked to provide a password; since he’s completely clueless on digital security, he provides one of the best passwords ever : « password » (it’s a .02 sec on a brute-force).

Before you encrypt it, you add a prefix (with a P, as in Pepper) and a suffix (with an S, as in Salt) to the password, to make it strong enough :   @&é89_)#password___-°§éé&ù

That’s a good one. Now, whenever the user is asked for his password, add the Salt’n Pepper before encryption to match the password. And obviously (needless to say, but i’ll say it anyway), encryptions such as MD5 or SHA1 do not show salt or pepper; you can’t deduce them from an encrypted password.

Is it safe ?

Wanna make it safer ? Change the salt’n pepper from time to time; make it automatic and programmatic; for example, when a user logs in (let’s say once a month), you change the salt’n pepper to new values (again, once a month); you just need to set a flag on the user in order to know if the change has been made or not. This way, you can have them change passwords as often as you want without even being aware of it.

IMHO, that’s as safe as it gets.

Les commentaires sont fermés.