Lesspass: Add aliases to the password profile

It sound like a nice idea for me.

But how will be the aliases stored, I'm not sure that the webextensions remember this kind informations when we close the browser ?

@roipoussiere
If you go on example.org or accounts.example.org or www.example.org with a profile:

{
    "login": "[email protected]",
    "site": "example.org"
}

It will set login field with [email protected]

So I don't understand the idea

But how will be the aliases stored, I'm not sure that the webextensions remember this kind informations when we close the browser ?

LessPass can currently store some informations about websites into a server. The idea here is to add the aliases parameter for each item in the json file.

@guillaumevincent Yes, but if I go on accounts.example.org, the site name field will be filled with accounts.example.org, so if I let it as is, the generated password will be not the same that the one generated from example.org.

So this is a bug :)
It should replace site with the site saved in the profile

@roipoussiere
Ah ok, so it will be more a solution for people that use Lesspass Database and not only the Webextensions.

So this is a bug :)
It should replace site with the site saved in the profile

The behavior I'm explaining is that It should add url to the list of aliases in the site saved in the profile. Not replace, add. :)

@roipoussiere the behaviour should be this one: https://github.com/lesspass/lesspass/issues/278#issuecomment-330225529

If this behaviour works as expected, you don't need a list of aliases

Ok, lets do this:

I totally admit that for both example.com and accounts.example.com, the username field is filled.

But it's not the purpose of this ticket. As you can see, even if I set the same master password, the generated passwords are different, because the Site fields are not the same.

My suggestion is to fill the Site field with example.com in both cases, in order to generate the same password. To do this, I really think that we need a list of aliases.

@roipoussiere

Interesting idea as a workaround ...

But how would you solve some of my use cases then:

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 site-names - as required!

I do need different passwords in scenarios like these.

Wow, It's not a typical use-case... Are you personally concerned by this or is it an hypothetical scenario who possibly appends to one user in few years? :D

~A solution is to lightly modify the master password. It's a little bit dirty but I don't think this use-case is representative enough to get worried about it.~ Ok, stupid idea I admit ;)

@roipoussiere

I really wonder where you take the certainty about "typical usecases" from.
I consider my usecases as being typical, knowing not only me can use LessPass the way I do.

For sure I am personally concerned, as are lots of other people, too, though not much of them might use LessPass or other Password-managers... because they simply don't know about it, or are not concerned about password security the way I am or we are.

I think use cases are as different as people are, and as various as the web and applications outside the web are.

And LessPass maybe has been created for special use cases once ( I don't know but @guillaumevincent will know). But the way it is designed today offers a broad variety of use cases, some people don't even think of.

So sometimes ideas - meant good for sure - are a regression to those using the full potential LessPass offers.

Modifying the master-password is clearly against the intention of LessPass - how many Masterpasswords do you want me to remember?

I see no reason to reduce use cases (regardless of what you consider being typical or not) or to reduce the usability of a well designed software!

@panther2
From what I understand, @roipoussiere wants to add the possibility to have alias for some website.

Example:
www.1.example.com
www.2.example.com
www.3.example.com
Have the same password as example.com
For me it will look like activate the option to have only the domain for these 3 websites.

So I think that the alias field will be optional.
It's so that I understand it, maybe @roipoussiere can be confirm my tought.

@kidburglar

Yes, that is what I thought, and actually I was really interested in this idea. As this would be a good offer for those users looking for a FQDN-alternative.

I was simply looking for an answer how to integrate my special use-cases above, needing different passwords and hoping for a practical solution. I did not expect a judgement about my use cases.

@panther2 Ok, ok I tough it was very very uncommon :)

But my proposition is totally retro-compatible and optional: In your use-case, you only need to don't set aliases. :)

@panther2

Have the same password as example.com

Yes. And also the same site field.

For me it will look like activate the option to have only the domain for these 3 websites.

Actually I'm not thinking about a on/off button or similar. To add an alias, you just need to go to accounts.example.com and set the site field to example.com. Eventually a confirmation message may appear like "Hey would you like to link accounts.example.com to example.com?".

@roipoussiere

In your use-case, you only need to don't set aliases. :)

Meaning for example www.1.example.com www.2.example.com www.3.example.com could coexist together with example.com (if ever needed) in the database wihout being connected as alias?

That would sound much better than

A solution is to lightly modify the master password. It's a little bit dirty but I don't think this use-case is representative enough to get worried about it.

:wink: !

don't spend to much time on this, this is a bug.

if in database you have:

{site: 'a.com', login: 'test'}

if you visit www.a.com it should replace the site with a.com. If not the password is different.

if in database you have

{site: 'a.com', login: 'test'},
{site: 'www.a.com', login: 'test2'}

it should use the second password profile (with test2), because the url match.
The tests are green for this use-case, I think the problem is a race condition when we get the url.

To be clear, I don't want to add aliases. The use case describes will be solved when I will fix the bug.

my mantra:

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

Antoine de Saint Exupéry

if in database you have {site: 'a.com', login: 'test'} and you visit www.a.com it should replace the site with a.com.

Good to hear that! But I don't understand... If this is just a bug, what is the purpose and the problem with this issue?

The use case describes will be solved when I will fix the bug.

Remember that one of the use case I describe is also: I go to https://superuser.com and I would like that LessPass fills stackexange.com (which uses same logins) in order to generate the right password.

Subscribing as my university has different portals for different scopes but all of them require the same login information :smile: but the _state of the art_ of LessPass is that each of them gets a unique generated password because the site field is different each time.

This should be implemented as easily as saving generation parameters.

As I said... use cases vary with the users :smile:

I am new to lesspass but I can confirm it would be usefull to me to associate multiple domains to the same account, and keep the functionnality to have subdomains with a different account.
My company has a portal "mycompany.com" with the same account as the webmail on "anotherdomain.com" and a specific application with its own account on "sub.mycompany.com".
Alias as a different field from the url seems a good way to do it. The alias being used for generating the password, and the url being used to find the alias from the current page.
I'd have

{ "alias":"mycompany", "site":"mycompany.com", "login":"login1"}
{ "alias":"mycompany", "site":"anotherdomain.com", "login":"login1"}
{ "alias":"mycompanyapp", "site":"sub.mycompany.com", "login":"login2"}

+1 cross-domain aliases would be super useful

Thanks @roipoussiere for taking the time to look for similar issues.

@guillaumevincent I believe @Maxiride scenario illustrate pretty well the feature request or as roipoussiere said:

For instance, stackoverflow.com and superuser.com.

Same id, different domain. That's a use case I have and here is how I manage them:

• one where I use only 2 different entries/domains so decided to memorize that the .com is the canonical one
• the other as multiple entries but decided to use only one.

Remember that we designed lesspass to provide _privacy by default_ and we aim to store as little information as required.

This feature request add more business value to the backend, as it will store and provide data, thus pushing us to rely even more on a database. I believe it's something that goes in the wrong direction as the more information we store the more valuable the database is to attacker.

I see this is still open, and see the comment from https://github.com/lesspass/lesspass/issues/400#issuecomment-629067859
I understand the point that this will not entirely follow the stateless intention, but it does add a pretty decent amount of usability.
And since there has not been any update on this, I just wanted to do a little push to get this considered again

Hello @GaboFDC
my main concern is more in term of user experience and user interface.
Except that I'm good with the idea of aliases for a password profile.

My company is using softwares which provide web interfaces and use our MS AD (or LDAP) for authentication phase (and some other softwares have their own DB). My issue comes from the "site" field which is filled with FQDN of the web site: I need to overwrite it to get the correct password. Therefore, having an Alias field (I would fill on my own with what I want) would be an improvement to me, that field being used in the password calculation instead of the "site" field currently used.
In order to not break current password calculation for profiles stored in the DB, you could check if the "Alias" field is empty. If yes, then use the "site" field for password calculation, else use "Alias" field for password calculation.
Obviously, adding an alias on any already existing entry stored in the DB would change the current password calculation result. Perhaps it would worth a warning (and that should be enough) to users when adding an "alias" to an already existing entry in the DB ?
What would you think about it ?

I think this is a completely valid use case.
We need to add the alias in the backend profile, then update the UI to allow this.