Hacker News Reader

One domain flaw: dropbox.com used to be getdropbox.com and probably others. Unless you remember and/or changed your password when that happened, it might now be unrecoverable.

One password flaw: some sites have weird restrictions (probably your bank, for instance). A hashing solution is unlikely to meet those requirements, meaning you have to store the value securely somewhere, so why not store them all? On the other hand, if the output can meet the requirements, it's probably partly based on the requirements. If the requirements ever change, your password now doesn't match.

I know I've thought of others previously, but the short version of it all is that at some point you'll probably have to have secure storage for something that doesn't work with the hashing system you have. Once you have that secure storage, why not just use it instead, since it can resolve nearly all of the problems?

Anecdotally, the "one domain flaw" has only ever happened for me for two websites over long time I've been using this system: getdropbox.com and amazon.com (using international amazon sites). Worst case scenario, you can request a password reset if the domain changes, because it's not the sort of thing that happens often.

The "one password flaw" has never been an issue, but my bank uses proper two-factor authentication with a physical card-reading device, so maybe that's why... I've never actually encountered a website that places problematic restrictions on passwords except (weirdly) Microsoft.

But they're just personal anecdotes that those flaws haven't been an issue for me, but I agree they exist and could be show-stoppers for others. I certainly wouldn't recommend it to anyone non-tech-literate. If I did need secure storage outside of that system (which, you're right, does happen–mostly for wifi passwords and the like) then I just use the system keychain as intended.

But I do still have concerns about the overall security of the system simply because I don't understand it well enough...

> Once you have that secure storage, why not just use it instead, since it can resolve nearly all of the problems?

Because I don't want to pay for 1Password licenses, or be caught out if I'm using someone else's computer, or if all my backups catastrophically fail :)

Use any Google properties? Google.com and youtube.com (can) use the same password across two domains. I think there are others within google too. Or do they redirect to google.com for all logins? Meh. Like you said, it's a rare problem.

Thought of another problem: when you're forced to change your password. How do you encode that? Just add a version-N marker to the site name (which you have to remember)?

I'm not trying to sell you on 1Password, just point out problems with hash-only approaches :) And the storage-less nature is certainly a (big) plus when it works out, you're right.

--

And one possibly-significant danger you should be aware of: assuming you do something simple (which has the advantage of being buildable from scratch on any system, and easy to remember how), if your password is not globally unique then your security partly relies on the security of whoever else uses your password. If they lose it, anyone who knows that and guesses your username anywhere gets proof that you use the same password, so they can go test a bajillion sites immediately and with perfect success rates.

The standard technique for mitigating this is to salt the hash... but this is just another secret you have to store somewhere or memorize, so we're back where we started.

As long as by one-way-hash you actually mean "key derivation function" and not actually hash, otherwise one leaked password means I get your master password, and hence all of your passwords, as long as your master password has an impossibly huge amount of entropy. (It probably doesn't.)

Seriously, use cryptographically random passwords.

SuperGenPass uses MD5 or SHA512 (so they do use hashes). Personally, I use bcrypt with a cryptographically random and long master password, which is something at least.

I appreciate the input and advice anyway. Security being a system of compromises, my current stance is that the security offered by a system like this, despite its flaws, is greater than a password database system (with truly random passwords) because then both I need to keep the database physically secure and trust that e.g. 1Password have designed it properly (or that my cloud provider is capable of keeping it secure). Since 1Password has apparently had potential issues in the past I don't have too much faith, but perhaps I'm being overly cynical.

Comments like yours and Groxx's help me re-evalute what I'm doing though, so maybe I will switch to proper random passwords in future. So thanks again for the input!

I didn't say anything about any particular system. Using MD5 or SHA-512 doesn't have to be bad per se -- using them once is bad.

Also, you mention having to keep it physically secure. I don't think that's true; you can use anything you want to encrypt it, from passwords to smart cards to whatever.

You mention you have a long and cryptographically random password. I'm guessing (hoping?) that it consists of a bunch of words that are easier to remember, since humans are pretty bad at remembering things with sufficient entropy to count, particularly if they come in the form of unintelligible junk :)

Do be very careful designing your own system. Our own security expert has written a blog post talking about the pitfalls:

http://blog.agilebits.com/2012/11/08/dont-trust-a-password-m...

I suspect you'll find that at least somewhat useful :)

Kyle

AgileBits Support

It's very kind of you to respond! I would certainly never trust it to share with someone else :) but I'm perfectly happy to accept the risk myself.

But it's not just me using a system like this. Everyone using SuperGenPass is using something similar too. That's why I think it's important to talk about it more.

My pleasure :)

I find it all very interesting so I try to learn where I can, but I leave the security stuff to our resident Chief Defender Against the Dark Arts (Jeff in the blog post). He's the guy who understands all of the security implications. He talks and I listen and try to absorb everything I can.

I figured that article was at least worth mentioning here.

Kyle

AgileBits Support

I'd be interested in peeping your script just as a blueprint of how to set something like this up for myself. I'll likely end up ponying up for 1Password v4 anyway, but I fantasize about going lower-fi/simpler all the time, and this seems like a nice step in that direction. Are you doing this on OS X?

Yep. Doing this on OS X and launching it via Alfred. I'd rather not share the script solely because I don't want to be responsible for some bug or bad idea that could cause you or anybody else problems.

However, I can share some inspiration to get started:

SuperGenPass (the original place I saw the idea): http://supergenpass.com

A fork of SuperGenPass using bcrypt/base85: https://github.com/cmcnulty/SuperGenPass

I wouldn't use either of the above because they're JavaScript-based, but someone has implemented it in Python: https://github.com/gfxmonk/supergenpass

I took that script as inspiration, modified it to use bcrypt, and then used the Python "keyring" module for access to the OS X keychain, and calling "osascript" to use an AppleScript one-liner to get Safari's front-most URL as an input.

It does potentially have the side-benefit of protecting against phishing attacks too, since if the domain is different, the password is different, so you can't be fooled into giving your password to the wrong website.