Ahh, security. It’s it’s like flossing and using condoms. We all know we should do it but… well, it’s business time!
We’ve all got the same issues. “Use strong passwords!” which means “don’t use just words” is something we all try to take seriously, but it just ends up being something like “c00lp455″ with even the most basic cracker program would handle easily– replacing letters with numbers was maybe a good strategy in 1988, but you might as well just use “coolpass” today, because that’s not any easier than using numbers for any attack.
“Don’t use the same password often,” “Use passwords with enough entropy (randomness),” “Use passwords longer than 8 characters with upper and lower case letters, numbers AND PUNCTUATION!!”
Whatever.
It basically comes down to this: We all have one password we use for freakin’ everything, and that password is probably something like “mysillyp455.”
Sigh.
I’ve been wanting to get away from this lately, but have been generally disappointed at the options.
There are dozens of password managers out there, and hundreds or thousands of password generators. I have issues with all of them, and recently decided to address them in a bit of a crazy way: By completely re-thinking how I handle passwords.
You know it’s true. They come up with the most ridiculous passwords that you’ll ever see. Who the hell is gonna remember ’5+b(*|$1e8+8@’ is their password?
Oh, right you want pronounceable passwords, because ‘m4k1tw0rk’ is going to work better than ‘makeitwork.’ Right. See above.
I mean, they do their job, sure, but password generators generating random strings are not really very useful to me, because I’ll never be able to recreate the password, which means I have to write it down somewhere or store it in a password manager…
Yeah, I know, you’re a dedicated 1password user and you think I’m an idiot. It’s a decent solution1 but it, like any manager, still suffers from some serious flaws.
One is, of course, that if you’re somewhere or somehow don’t have that manager available, it’s absolutely impossible to get your password. This has recently happened to me while trying to use an app called LastPass, which generated really nice, ridiculously hard passwords for all kinds of stuff, that I could then never remember and I couldn’t get later when I screwed up my master password.
Reminder emails galore!
Here’s another problem: My passwords are stored on somebody else’s webapp database. Oh, sure, they’re stored ‘securely,’ but how the hell do I know that’s true (read the TOS people, they limit their liability for a reason).
If the pentagon can get hacked, some 24 year old start-up geek is certainly vulnerable.
The biggest things about all of these is the ‘single point of failure’ issue. Password managers store passwords in encrypted files, so that’s nice. But what if someone gets your all important 1password that secures all your other passwords? You are, in a word, fscked.
So, the basic problem with all of these is that they are not actually as secure as we think, and when they are, they’re not easy. So we either have secure and hard as hell, or we have easy and fundamentally flawed, right?
Maybe not.
Okay, no lie, this came to me while somewhat tipsy and pouring down beer at a local pub:
What if your password wasn’t stored anywhere, ever. What if you could simply have a way to securely recall those ridiculous passwords that generators come up with out of thin air?
Think about it. 5+b(*|$1e8+8@ is probably a pretty damn secure password– if you used that for anything, you’d be pretty safe, but you’d never remember it. But what if that was, in a way, mnemonically generated?
Passfish is a program (actually, it’s an idea)3 that generates passwords from the combination of words, a secret key file, and (optionally) name and passphrase parameters. Using this combination of items, Passfish will generate a high entropy password.
$ passfish 'name@email.com' 9!b%e+70
Now, that password is not stored anywhere, not in any encrypted file, nowhere.
Furthermore, if you use the Bash shell’s ability to ignore certain commands, that won’t even be in your Bash history. No-one can get it in a file, no-one can see what you’ve typed. It’s ephemeral. You call it up, and then it goes away.
But it’s still insecure as hell, right? I mean, anyone can figure out that name@email.com turns into SOMETHING.
Keyfiles solve this. When you have a private keyfile, the string name@email.com is combined with the contents of this file, a hash is generated from that combined string, and the hash is modified in a repeatable way. This means that you can have super simple “passwords” (e.g. name@email.com) and even write them down on your forehead, and no-one will be able to generate your actual password without having your same keyfile.
But wait, there’s more!
$ passfish 'email' --name 'work' (|@+#^7b $ passfish 'email' --name 'home' $1e8+8@
You can specify an additional parameter, a name. This allows you to increase the security because you could have the same “password” for multiple accounts. You can also have passphrases:
$ passfish 'email' --passphrase 'I hate Dirty Dancing!' $1e8+8@
This allows even more security!
There’s also a length parameter:
$ passfish 'email' --name 'work' --length 13 $1e8+8@$1e8+8
One of the things many people do when thinking of passwords, is create devices that they use in ALL of their passwords. For instance, start with an @ and end with a $, then capitalize the first letter, so a password could be something like ‘@Email$’.
What Passfish allows you to do is to create similar mnemonics, but use them wisely to create truely complex passwords. For instance, it’s a website that I use at work called “workstuff.com”
$ passfish "workstuff.com" -n "website" -p "at work" $1e8+8@
Thus, the password is not stored anywhere, but I have an easy way to remember it.
This way, even if someone steals my computer, they can’t get my passwords unless they have ALL of the following:
Rather than a single point of failure, there are multiple points for each password, because even if someone got your private key file figured out, they’d still have to spend considerable time getting each password– and access to one password makes it no easier to access another password! It’s not an all-or-nothing proposition.
So, what’s the status? Well, it’s currently an open source application on Github, and it’s little more than a proof of concept. All it does now is combine all the parameters together into a string, hash it, and modify the hash. Pretty stupid, I know. (The plan is to do things better, like use the passphrase parameter to strengthen or change the hashing, etc.)
And as for the “but that’s stupid and hard” people, the other plan is to create apps that tie in with this underlying generator for things like Android and LaunchBar. For instance, a LaunchBar plugin that lets you type the identifier, name and passphrase, and then automatically copies the generated password to the clipboard, so that you don’t have to even see it, much less go to a terminal window to use Passfish.
So, it’s new, it’s still pretty dumb, but as a proof of concept, I throw it out there as an idea, knowing that– because it’s open source– any serious vulerabilities or blindspots will be illuminated.
Check it out, fork, modify, correct. Throw me ideas and comments or ignore it altogether.
Awesome idea John, I’d love to try to make it a web service with an API. I’ll look into it
Daniel,
Possible of course, although that would significantly limit the security of the algorithm, at least in the way I'm originally envisioning it.
The point of it being a device app is that it's easy to use it and generate the passwords from your parameters in a "leave no trace" manner. You can tell the Bash shell to ignore that command in history, easily clear it from the terminal, create a shortcut (Quickbar, LaunchBar, similar for windows) that copies it to the clipboard and exits without showing it, etc. On a phone things are similiar. My thought was that without direct manipulation of the RAM, the password, and parameters that generate the password, would not be stored, and everything would be local and ephemeral.
Not so with a web app. An API requires calls, and calls are logged, thrown about on external servers, and mostly sent in plain text. You could make it an SSL or TLS connection, I guess, to encrypt the call, but that seems like a lot of trouble for something that would be easier to secure on the device and seems to gain small benefit from being available as a web app. You'll have to really explore the security aspects of it being a web app, and see if the API approach can be made secure enough.