When forced to change your password...

[NigelThorne]

...what's the recommended workflow when forced to change my password, when I was already using SGP, and a site asks me to generate a new one. I don't want to end up having to remember a different master password for each site as this would invalidate the advantage of SGP.

Thanks
Nigel Thorne
(ps.. I love SGP)

[scottchiefbaker]

Good question... I just ran in to this EXACT thing with Ebay. I was planning on just using a new master password for Ebay. But maybe there is a better way?

[chriszarate]

I think I addressed this in the FAQ, but there's no best way. What I do is add a counter to my master password. So if my master password is "cornflakes" and I have to reset my password, I use a master password of "cornflakes1". If I have to change it again then I use "cornflakes2", etc.

On Jun 10, 2014, at 6:31 PM, Scott Baker [email protected] wrote:

Good question... I just ran in to this EXACT thing with Ebay. I was planning on just using a new master password for Ebay. But maybe there is a better way?

—
Reply to this email directly or view it on GitHub.

[NigelThorne]

We could make supergenpass generate 10 passwords (say).. and it tries the first as it does now... but clicking the second would populate the password fields with the second... etc. then without remembering, you can easily try them in order.

A more complex approach would be to be able to 'retire' a password.. which would log the obsolete password with a central server. Then the bookmarklet could generate a password, and where the generated one is in the list, it generates a second automatically. Sharing these expired passwords wouldn't be a security hole as you could do it anonymously. It may break the portability of SGP a bit though or cause cross-domain javascript issues.

[gotofritz]

@NigelThorne eventually you will run out of passwords. But maybe the trick would be to combine your idea with @chriszarate's, by adding a "try next variation" button which would automatically add a "1", to "cornflakes" (and then a "2", etc)

@scottchiefbaker I use different master passwords on each site. Otherwise all it takes for you to compromise the master password once to compromise them all. They can all be variations on a theme, with some extra info that comes from the domain. Plus I use the versioning trick chris uses.

[cmcnulty]

In my fork, I've solved this with two additions, one of which might need some more thought. First, I added a counter field which gets appended to the secret key at time of password generation. This is fine, but how to remember which sites are at which count? To solve that problem rather than storing just the last-used settings to the browser's localStorage, I index the settings by site at which a password is generated. The thing that makes me uncomfortable is that if an attacker is able to get at the browser's localStorage, the data stored there is much more valuable, e.g. a list of financial institutions where SGP is used. The only way to secure that data would be to use the master password to perform a one-way hash of the url. But that creates a totally different workflow than current SGP users would be used to. On the other hand, if you're willing to "trust" the localStorage, then the solution works fine.

[scottchiefbaker]

Couldn't you salt the the domain the password was generated for, and use that in localstorage?

[cmcnulty]

Yes, but of course in order to compare the hash without user intervention, the salt would have to be stored in the app. So, we will have obfuscated the url, but I think that would provide more of an illusion of protection rather than actual protection. I mean, anyone going in to examine the localStorage for SGP settings is already beyond normal browser-history snooping.

[denis-sokolov]

@cmcnulty, what's wrong with hasing the domain with the master password, as you yourself suggested?

Also, if an attacker has access to the localStorage of any domain, they generally already have full control of the computer and all is lost.

[cmcnulty]

The problem with hashing the master password with the domain (besides working out the work-flow issues), is that then your master-password can be brute-forced with the hashed domain values.

But, like you said, if an attacker has cross-domain access to localStorage, it can probably be assumed that it's game-over for securing anything on that browser. With that in mind, I didn't bother to hash/encrypt the domain values stored in localStorage at all. I added a new field (counter) which gets appended to the master password at time of generation, and then that counters value is saved with the domain to the localStorage for future retrieval from the same browser.

[brianclements]

I don't think I saw anyone mention the "secret password" field in this thread. It just adds more seed to the original hash string (masterpassword + mastersecret + ':' + domain) and is very well suited for this purpose. Might I suggest a workflow like this:

Master Password
A nice, long, word or sentence even that you will remember no matter what and will only have to change in very rare circumstances.

Secret Password
This is the variable field depending on website/account/username usage. Have multiple gmail accounts? Type in something derived from that email address here so that you can use the same master password, the same domain/URL (obviously "gmail.com") but not have the same password. It is not uncommon to have multiple accounts for the same domain/URL, so using this method to create unique passwords per account per domain/URL is very handy.

This field is also, I would suggest, where one would add "counters". The way that data breaches and hacks go, it's very piecemeal. Certain segments of websites get hacked but not others, so perhaps only one of your accounts needs changing etc. So this way, you can keep your master password intact for a very long time and just add the counter to the secret password field so that you don't have to try to remember multiple master passwords, which to me, defeats the entire purpose of using such a tool.

Keeping the master password secure however requires that there always be something in the secret password field; so whatever passwords get generated out there in the wild always have 2 variable inputs. I have a holding password that I use in this field for situations where I don't have account/user specific information.

when sh hits the fan**

1. add counter to my secret password for the sites affected
2. ...keep adding counters to secret password, leave master password intact
3. ...maybe when I'm bored one day, and have lots of counters on all my accounts, I can change my master password and go back to square one with all my secret passwords and no counters.

[kousu]

I highly recommend that counter method. It's KISS. I write my passwords down in a plaintext file with their counters and any other tweaks like this:

h("facebook.com"+"2")
"^"+h("www.hsbc.com")+"3" #hsbc has dumb password rules
h("gmail.com")

Of course, I don't write down how h() is defined: that's includes which password hasher I'm using plus my master password and is only in my head. I think this is the optimal balance between difficulty (so it's secure) and usability (so I actually want to use the security).

[denis-sokolov]

I personally use the general supergenpass, if that does not work, I either open up a KeePassX, or use recover-password-over-email functionality. With "remember me" working everywhere I don't need to do that often.

Between all mentioned approaches in this topic, I think we can close the issue.
Feel free to add your own interesting approaches in this issue further, though!