search

chriszarate / supergenpass

A free bookmarklet password generator.
https://chriszarate.github.io/supergenpass/
GNU General Public License v2.0
418 stars 160 forks source link

Do not cut @ in domain field #78

Closed mastercyb closed 8 years ago

mastercyb commented 8 years ago

Sometimes I want to generate passwords based on full email. Android app allow me to do this, though web app cut everything before @ and the symbol itself

PacoBell commented 8 years ago

Have you tried clicking on that little "TLD" button?

mastercyb commented 8 years ago

Yes, but it do the same

On 12 Jan 2016, at 00:52, PacoBell notifications@github.com wrote:

Have you tried clicking on that little "TLD" button?

— Reply to this email directly or view it on GitHub https://github.com/chriszarate/supergenpass/issues/78#issuecomment-170745772.

chriszarate commented 8 years ago

This is intentional, since @ has meaning in URIs. See these test cases in the supergenpass-lib repo:

https://github.com/chriszarate/supergenpass-lib/blob/master/tests/hostnames.js#L31-L45

brianclements commented 5 years ago

Hi @chriszarate, sorry to resurrect this. But I too have interest in using '@' in the address field so that I can move my user differentiation from the secret field (which SHOULD be used for a giant salt that I don't have to ever worry about outside of seasonal rotation) to the domain space where it belongs in visible and typo-free form so that I can make unique per-user passwords across the same domain space.

I looked at your test cases and am not quite sure of the rationale still behind enforcement of '@' removal? All that shows me is that you do it, and that you test for it. I know the '@' symbol has strict guidelines in URL use, but this isn't a browser address bar? It's just supposed to be some kind of unique identifier. I can understand the strictness when TLD enforcement is on (consistent, automatic, default behavior). But when the user turns it off and wants to enter things IN ADDITION to whatever the domain/sub domains are, why not? It doesn't affect the security of the resulting hash, so why not let the user do it?

I'd argue a bit of an unintended side-effect thing here. Let's take an example: multiple gmail accounts. The best combination of maintainability and security would be to have an easy to remember but strong master password, and very strong and written down salt in the secret, then things in the domain field that are meant to differentiate the users ("user1@gmail.com" from "user2@gmail.com") but not add significantly to the security.

I'd argue that pushing people to shift the differentiating input from the domain field to the salt probably encourages them to

1) Not want to deal with the secret/salt because they can't see it while typing and thus 2) being afraid of typos, might use weak secret/salt, if any at all or 3) worst yet, not differentiating passwords at all, and thus committing worst sin of all of encouraging password re-use by not differentiating across multiple user accounts.

Thank you for this project, by the way, it's a very useful tool and I'm very grateful for it!

CheneyLin commented 5 years ago

You can try this Chrome Extension https://github.com/CheneyLin/codeSuperGenPass_ChromeExtension