Possibility to take only the domain and not the FQDN

[Kcchouette]

Now that RMLL is finish, Lesspass Move seems ok, and (I hope) version 1 is going to be removed soon, I reopen the issue #199.

The sum-up is: can you offer the capability of choosing for the website:

• only domain (e.g. google)
• domain and tld (e.g. google.com) <- the option that was introduced on Lesspass with Subdomain and protocol should be stripped #45 but removed with Passwords are generated differently after the Chrome extension was updated #148
• FQDN (e.g. accounts.google.com) <- the current only option for the extension

[SoftwUser]

I don't know why I would want a regression from the current FQDN-implementation.
But as long as FQDN is and remains default and the reductions (if implemented) become optional it would not bother me.

[SoftwUser]

@Kcchouette

Don't hesitate to ask/discuss about what confuses you about my statement,
Is it not pretty clear?

In #199 (comment) you voted for FQDN as default yourself! So at least regarding this aspect we do agree!

[Kcchouette]

I'm confused about the "regression from the current FQDN-implementation" statement.

This issue has the goal to add several more options to choose the website address.

[SoftwUser]

@Kcchouette
As far as I understand how LessPass works, the information entered in the site field (as well as others) is used as (additional) salt to compute the password.
So if the characters are reduced from accounts.google.com to only google.com or google this would mean less salt and less entropy.
So this is why I call it "regression from the current FQDN-implementation".

Also: You do have the options today: Simply delete the characters you don't want from the FQDN.
You are totally free to add/remove whatever characters you want in the site field.

[guillaumevincent]

@SoftwUser I'm not sure the length of salt is important. If a generated password is stolen (i.e. myspace), you already got the site (i.e. myspace.com).

We already discuss about this:

• only domain (e.g. google) <- hard to find without a big list on domain names
• domain and tld (e.g. google.com) <- the option that was introduced on Lesspass with Subdomain and protocol should be stripped #45 but removed with Passwords are generated differently after the Chrome extension was updated #148 <- hard to find without a tld list
• FQDN (e.g. accounts.google.com) <- the current only option for the extension

The only easy improvement we can do easily is to remove www. from site, if site starts with www.
I don't want to introduce this feature as default because it will require a v3. New version should be limited to security leak.

Maybe we can add this in a configuration option.
Related to #245

[SoftwUser]

@guillaumevincent

I'm not sure the length of salt is important. If a generated password is stolen (i.e. myspace), you already got the site (i.e. myspace.com).

I am not only concerned about the computed password but about the masterpassword, too.
It makes a difference, if accounts.google.com , google.com or google is used in the process, doesn't it?

Anyway, your solution to just add an option for reducing the FQDN appears to be reasonable. Thank you.

[panther2]

@guillaumevincent
Because of #272 I stumbled (again) over this issue.

I would be very unhappy, if the current approach would be reduced or "filtered" to anything shorter.
I am happy with as much information as possible to be included into the "site" - field and I don't understand why that should be reduced on default.

I have use cases as follows:

www.1.example.com
www.2.example.com
www.3.example.com

1,2,3 being different servers, but with identical Login-names.
I get three different passwords because of different FQDN - as required!
If these were reduced to example.com my use cases were immediately broken.

So please, on the default side, please leave it as it is today!

I am happy to read your above statement:

I don't want to introduce this feature as default because it will require a v3. New version should be limited to security leak.

But in case there will ever be a v3, please don't touch FQDN as default. Please offer options to reduce/filter and don't enforce it, not even remove www, please. I consider FQDN being a feature rather than a bug.

And as @SoftwUser said above, everyone who wants shorter site names can delete the unwanted characters manually even today. This is less error-prone than having to add characters manually.

[guillaumevincent]

@panther2 interesting
Maybe we can make this configurable.

So basically we keep default as today.
And we add an option to remove subdomain and www

[panther2]

Maybe we can make this configurable.

So basically we keep default as today.
And we add an option to remove subdomain and www

Brilliant, thanks!

[kidburglar]

As I said before when I opened #199 an option is perfect for me, and I would be happy to test it.

@guillaumevincent
You think only a classical option that we can tick or something more advanced like own regex etc ?

Thanks in advance for this option

[guillaumevincent]

@kidburglar what option do you want? Removing www. or only domain name?

[kidburglar]

@guillaumevincent I would prefer something to hold only the domain name example
doc.domain.com => it hold domain.com

But if you can add a regex possibility is more flexible for everyone I think

[roipoussiere]

An option to remove the subdomain would be great!

There are different use cases where I will find it very useful:

• websites may update their subdomain in a new version, ie: example.com/fr -> fr.example.com ;
• example.com and www.example.com generally point to the same site;
• many sites use subdomains but with the same authentication, ie: mail.google.com and drive.google.com, or tex.stackexange.com and math.stackexange.com;
• sometimes the subdomain depends on the context, ie: example.com and m.example.com.

I actually manually remove the subdomain to prevent mistakes, but yes keep the actual behavior by default to prevent authentication problem for many users. ;)

[guillaumevincent]

@kidburglar and @roipoussiere there is no easy solution to get only FQDN domain.
To do so we need a list of TLD.

I don't like the idea of a TLD list because:

• will force to update list after every new TLD
• add a lot of KB only for one feature

[Kcchouette]

The list is already done by https://data.iana.org/TLD/tlds-alpha-by-domain.txt (10,2kB), https://publicsuffix.org/list/public_suffix_list.dat (196 kB) or libraries, by example https://github.com/oncletom/tld.js .

[kidburglar]

@guillaumevincent

The FQDN is actually what lesspass do now.
https://chrome.google.com/webstore/search/lesspass => chrome.google.com in lesspass

To get the domain you only need to hold the last 2 elements separate by "."
I don't know how to do that in lesspass but maybe an exemple in bash will be more clear.
I use rev to revert the string so I don't need to check how many occurence I have but there are surely something better.

# site.tld => site.tld
echo 'site.tld' | rev | cut -d '.' -f1,2 | rev
# my.super.site.tld => site.tld
echo 'my.super.site.tld' | rev | cut -d '.' -f1,2 | rev

[guillaumevincent]

To get the domain you only need to hold the last 2 elements separate by "."

@kidburglar this is not true. Try to understand that there is some popular TLD that contains more than one dot. .co.uk for example.

echo 'https://www.bbc.co.uk/' | rev | cut -d '.' -f1,2 | rev

@Kcchouette LessPass already used tld.js from Oncle Tom. The amount of extra data for only one feature was the reason why we abandoned it. tlds-alpha-by-domain.txt miss some popular TLD. And public_suffix_list.dat is too big.
We can probably create our list of TLD in the top 1M most visited site from alexa.

[kidburglar]

@guillaumevincent
I think that the most of extension use this idea (I not test other but my previous application passwordmaker used it).
=> http://passwordmaker.org/passwordmaker.html

What do you think about the regex options ?

[guillaumevincent]

I think that the most of extension use this idea

@kidburglar I'm not sure of this assertion.

What do you think about the regex options?

To complex, the target will be only power users.

The solution for now:

• create a small list of popular TLD based on Alexa ranked sites.
• add an option get the domain name only without the subdomain.

[kidburglar]

@guillaumevincent
What will happen if the site don't have one of the small list ?
A fallback like what I said before ?

[guillaumevincent]

@kidburglar yes probably

[SoftwUser]

Please hold on a second...

So what's the point here?

Every user would be enforced to download, install and load a list of some thousands domains with LessPass, of which the unique user only uses a small fraction?
And the one and only benefit would be not to have to hit del a couple of times in the single "Site" field to remove a couple of unwanted characters in those particular use cases?

Do I interpret this correctly?

[kidburglar]

@SoftwUser
I understand it like a list that will be in the web extensions.
In my case it's not only about "couple of times hitting del" but about remember which website I must be carefull for that or not, from which entry point did I the subscribe...
And if it's an option I'm not sure it will change something for other people that not use this function.

[guillaumevincent]

@SoftwUser not a list of popular domain names, only a list of most popular TLD

['com', 'org', 'co.uk', ...]

[serianox]

@SoftwUser I had a use case recently for impots.gouv.fr, the French ministry of finance, where the FQDN of the page to set a new password is different from the one used elsewhere, cfspart.impots.gouv.fr. Basically, another subdomain. Since .gouv.fr is a public suffix, both sites should share the same password under impots || .gouv.fr.

The issue is not about not having to hit del a couple of times. It's about not having to explain the concepts behind domain names to users, and why and how they should edit part of the subdomain before generating a password.

@guillaumevincent The public_suffix_list.dat can already be made lighter by removing all ICANN domains, since they are obviously all a valid suffix. This should at least limit the increase due to the opening of registration of new top-level domains. This is what was done in tld-list.js.

[SoftwUser]

@serianox Yes those cases do exist. But this does not justify a regression for those users already managing hundreds of passwords created including the FQDN. Don't just think about the new user who stumbles over a special scenario. Please do think about those existing users, too.
There is no reason to explain any concepts of domains/subdomains to the users.
I say let the user decide how to compose his passwords! And don't cut it by default!

Anyway I am glad to notice @guillaumevincent 's above statement, that the regression would be optional (#258 (comment)). So everyone can be happy.

[serianox]

@SoftwUser Agreed, this should not change existing behavior, e.g. optional for V2, possibly default behavior for V3.

[panther2]

... possibly default behavior for V3.

Ouch, @serianox , please don't ignore #258 (comment)

We had that discussion, and it has been resolved here #258 (comment)

[edouard-lopez]

Remember that lesspass use privacy-by-default and we want it to work off-line and standalone. So adding 3rd-parties is a no-go for me. Thus, an alternative would be to include whatever TLD list in the build, maintained it up-to-date and ensure we are not breaking any users' passwords…

@guillaumevincent Do you think this is testable?

@serianox for your problem, currently you have two way to manage this scenarios:

• remember the site yourself and manually fill it back ;
• use the connected mode to reduce friction.

[guillaumevincent]

I close this one thanks to the suggestion box in the last version.