Friday, July 29, 2016

Open Kimono Security

You've probably heard of "security by obscurity", the (old) idea that one should try to prevent the technical details of IT and security solutions from escaping into the wild, to avoid giving the bad guys ammunition. But it's usually much better to assume that all the technical details will leak out and to make sure that your solutions will be secure nonetheless.

Still, when a password file gets stolen and published, it's a big deal, and various parties go to work trying to crack passwords out of it. (Password files don't store passwords in plaintext: they are salted and hashed, so it takes effort to extract them.) Because most people don't choose long, random (and therefore complex), and unique passwords, a large percentage of passwords can be brute-forced.

Is there a better way?

Here is my idea: what if all Internet-connected services went a step further and published everything about their services? Except for their keys, of course.

I haven't thought this through in detail, but the obvious place to start is password files. Every website would make its password file freely available for download.

This probably sounds crazy. Ok, it definitely sounds crazy. But what would happen if we tried it?

It would certainly be a crazy thing to do with the current state of passwords. A password like "Julie94#" would likely take less time to crack than it would take to download the password file. So the amazingly insecure password practices of today would have to go out the window, and fast.

It would force services to (a) force users to choose much more secure passwords and (b) salt and hash those passwords much more securely.

There would be advantages. For instance, when a user of Service A tries to create an account with password X, or to change their password to X, Service A could check the password files of other services B, C, D, etc., (Google, Microsoft, Apple, etc.) to ensure the user isn't presenting a password they currently have on any of those other services.

Since users would be forced to use long, random, and unique passwords for all (or most) of their services, they would need to use a password manager -- which is something they should be doing today anyway.

There is (at least) one disadvantage: because password files need to store plaintext user ids (so that the salt value can be looked up), and because user ids are often email addresses, users whose services started publishing their password files would be immediately hit with spam. But since this would force email providers to improve spam filtering, maybe this is really an advantage in disguise.

Clearly some careful analysis is needed, but I wonder whether my idea would be basically viable if all passwords had to be long (say, at least 64 characters), and complex, and if salts and hashes were long (say, 512 bits long)?

. o O o .

If this post made you curious to know more about password files and how they are protected, check out this great page: Salted Password Hashing - Doing it Right

No comments:

Post a Comment