Use public suffix to normalize domain name.

[danmarg]

Does what it says on the tin.

[dchest]

Thank you, however this changes everything :-) I'd rather keep CryptoPass as is, because people already created passwords with it and changing the algorithm will break their passwords.

I actually started writing a more sophisticated scrypt-based implementation with a different name, but had no time to finish it yet. If you're interested, here's a technical description: https://gist.github.com/dchest/6098083. Basically, it uses a secret random seed and a changeable password to generate passwords.

Anyway, maybe you can release the version in this pull request in Chrome Web Store (under some different name) yourself?

[danmarg]

I figured this change was mostly compatible, since it only changes the input domain in some cases (which are likely to be problem cases anyway, but you're nonetheless correct that this could cause real breakage!). As you maybe can see, I made a number of changes after sending you this request that switches to scrypt with relatively high-cost parameters, etc. I was going to go fork that dude's Android app (https://bitbucket.org/zeac/cryptopass) to be compatible.

Your proposed v2 looks interesting. I guess I have to drink some coffee and actually read this to understand what you're proposing, though.

It seems to me that the main point here is to enable changing the master password. I don't think (personally) this is a feature that matters that much--ideally, the master password is unique, so the main mode of compromise is compromise of a machine where the password is entered; conversely, in that scenario, changing the master password does no good since the old password + old seed are sufficient to compromise all the derived keys. No?

The main pain point, to me, of hash-based password derivation is that some websites have bizarre password requirements or require regular password changes; I considered using Chrome's synchronized storage to allow me to store something like "charset for this website" and "number of iterations" (so you might do 2000 scrypt rounds and then 2001 for the next password, or whatever) per website, but I think the UI complexity there makes this somewhat of a costly thing to implement. (The main advantage of password-derivation schemes like this one over encrypted storage of passwords is that you can write down the secret salt and master password once, offline, and you don't have to worry about updating your backup copy whenever you add a new derived password, and the associated security risks of online backups, etc. Storing variable rounds and charsets kind of ruins that, so why not just use 1password or LastPass?)

Anyway, feel free to take whatever you want from my repository. I borrowed some guy's JavaScript scrypt implementation--it looks right, but honestly I probably have more faith in the sjcl PBKDF2 implementation.

It's probably obvious that I don't know JavaScript, though, so take my changelists with a grain of salt.

Dan