Barklund.org

The sixth idea for my 365 social ideas is more about social web principles than an actual idea. And then again, it is an idea to establish a new code of conduct and standards for a Password-friendly Website Certificate. “Certificate” should be taken lightly, as it is merely two very simple question for website owners to answer: Do you really need to ask users for a password? And if you do, do you then salt my password and then one-way encrypt it before storing it anywhere? The first is of course the better, but the latter is necessary if you do actually ask me for a password.

Okay, things are a bit technical, but there are 5 ways to store passwords. Let’s start with the least secure and move up from there (explanations given below for the curious):

1. Store a password in plain-text.
2. Store a password via regular (decryptable) encryption.
3. Store a password via one-way (non-decryptable) encryption with none or the same salt for all passwords.
4. Store a password via one-way encryption uniquely salted.
5. Don’t store passwords.

Salt?

Note: If you already know what encryption and salt is about, feel free to skip this section. Furthermore, if you don’t really care but just take my word for it, that the above 5 levels exist, feel free to skip further down as well.

How the password is stored in the database matters for two reasons. First of all, if you don’t trust the site owner completely, they should not have your password in a way, where they themselves can read it. Secondly, if their database is compromised and someone gets a hold of all the passwords (in whatever form they are stored) as well as corresponding usernames/emails, they could use this information to access a lot of other accounts in a lot of other websites used by the same users – because must users use the same passwords or the same few passwords for most services.

Whether the password is stored in plaintext or in a decryptable form (with the decryption keys most likely compromised along with the database) is actually the same, as the decryption (with keys available) is very straight-forward to do. The result is, that the attacker will easily obtain the plain-text passwords alongside the matching usernames/emails.

One-way encryption (commonly known as “hashing”) is a way to generate a value based on the original password, that does not directly reveal the original password. Imagine the original password as a set of numbers. If we add the numbers, we get the sum, and if we store this sum, then we could match against any password entered, and if the original password is entered, it would give the correct sum and thus allow access. But only knowing the sum does not reveal the actual password. Of course, simply adding the numbers is not good enough, as many easily testable sequences of numbers will give this sum but the idea is the same, just a lot more fine-grained and to date impossible to reverse for the best known such hashing-algorithms.

The only way to “reverse” a good hashing-algorithm is to brute-force it. E.g. if you know the sum of a set of numbers is supposed to be X, then try any combination of number to see if they give this sum. For hashing-algorithms it’s a bit more tricyk, but basically try all known words and see if the result of applying the hashing-algorithm is the expected sum. This does seem quite infeasible, but if you have maybe 200.000 users all with their passwords stored via the same direct hashing, you could start by trying the password “secret” and see how many of the 200.000 stored hashed values matches. I would guess at least 500 of them. And so on, you could try any dictionary word and each time learn more and more of the passwords.

But then we add salt. A salt is an extra known but unique string added to the password before hashing it. Imagine that we say, that for user U1, we add the salt S1 (a series of random letters) to the password and get the hash value X1, that we store along with the salt in the database. For user U2 we add the salt S2 (another series of random letters) to get X2 and store S2 and X2. Now, S1 and S2 are different, so even though user U1 and U2 might have the same password, X1 and X2 are different. Thus even though 500 users might use the password “secret”, we won’t know until we try each one with the unique salt. This makes brute-force attacks much less efficient, as we have to try every dictionary word once for every unique salt to know anything interesting – which would then take 200.000 times longer that if they all used no salt or the same salt.

Do you really need my password?

If I want to use some new service, that I don’t really know if I can trust, I know I shouldn’t trust them with a password, that I also use elsewhere in more important applications. But I can only remember so many passwords, so I will mostlike reuse some of my less secure passwords or built passwords according to some rule (like adding the website name to the password or something like that).

But this creates a new vulnerability for me, a new potential violation of my privacy. So I should really only give you my password or a slot in my limited password-memory, if you really, really need it. And today, any small online service could easily do without. Because any user who would user your service would most likely already have either a Twitter, Facebook or openID account. And it is technically quite easy to use any of these services to have you user securely log on to your service via any of these networks (without the user giving out his password to strangers) and this should provide any small service with more than enough user information. How to do this is quite simple and any worthwhile web developer can tell and show you in no time. Why to do this should be provided above – and summarized below.

Why?

Only give to people you trust completely your most private and most secure passwords. And for the lesser trusted people, give less secure passwords. And don’t ask for passwords, you don’t really need. Just because it seems like the user is more “your own” when he has his own password for your service, it is actually a bad thing. And if you really, really need my password, please promise me that you treat it with the utmost respect.

Oh, want some examples? Okay, here’s an easy one: TweetDeck. I have granted your application the privilege to post updates to both my Facebook and Twitter account, and yet that is not enough for you – you actually want me to invent a new password just for you to be able to synchronize my TweetDeck installations? How stupid are you? And that’s just to name the most obvious one, that I’ve come across…

What’s next?

Do with this idea whatever you like – expand, implement, trash or forget. Just remember, that if you use it in anyway make sure to attribute me according to the Creative Commons Attribution 3.0 License, that all these 365 Social Ideas are published under.

Related posts:

1. Coordinate-Proxy – January 2010 Ideas
2. Turn (Closed) Content Into an API – January 2010 Ideas
3. Social Subway – January 2010 Ideas