Subdomain and protocol should be stripped about lesspass

[edouard-lopez]

@nicokratky Thanks for the feedback, we had the discussion too, we are considering to:

• remove www ;
• remove the protocol https ;
• probably keep the subdomain as illustrated by @ffflorian's use case.

We are working on an app to gamify password update

[ffflorian]

I'd rather strip only the http:// part, because sometimes you need different passwords for subdomains (e.g. webmail.example.com and administration.example.com).

[guillaumevincent]

@edouard-lopez www is the only rule not implemented actually. It will break some generated passwords. So we need before to inform our users about a future change.

[SimplGy]

I mentioned this on hacker news too, but it's a key concern of mine: https://news.ycombinator.com/item?id=12980112

My concern is that domains change often enough that they might affect my ability to log in. If a domain changes I'm unlikely to remember what the old domain was.

Without actually auditing my access, I don't have strong examples, but I can think of things like:

• www.foo.com gets changed to foo.com
• a company refactors their codebase and now everything happens in login.mybank.com
• A company decides they want to keep everything on the api server to avoid CORS issues and now it's api.mymail.com instead of mymail.com
• A company rolls out https

EDIT: I looked up some real examples because the size of the issue is proportional to it's real world impact, so I thought it'd be worth doing.

• Charles Schwab is client.schwab.com. That's silly and they'll probably change it later, but will I remember what it was? Nope.
• Target RedCard is rcam.target.com. Holy crap.
• Chase credit card is secure05b.chase.com. You have got to be kidding me...
• ... And more and more. Modern tech companies like Spotify and Netflix have their domains figured out, but banking and governments are probably all going to be a mess.

I understand the argument for keeping this--webmail.foo.com and admin.foo.com could be totally different applications. The downside of using foo.com for both is only that you'd generate an identical password. That would be fine in my view but maybe not to others and that's valid.

Options to Consider:

• Just use apex foo.com and accept that it'll generate identical passwords in some cases (alternatively, you can use a different master passphrase for different scenarios)
• Store the original domain in a text file on dropbox so you know it'll never get lost
• Software solution: LessPass shows the expected domain, but provides a dropdown with every other value that's ever been seen for the apex foo.com. eg:

Select a Domain:
 ----------------------------------
[ https://foo.com               v  ]
 ----------------------------------
| https://mail.foo.com             |
| http://mail.foo.com              |
| https://www.foo.com              |
| http://admin.foo.com             |
 ----------------------------------

This way, I have a prayer of recovering the original password if the domain changes and I don't know what it used to be.

The large downside to this is it requires some server-side storage of all subdomains and protocols ever associated with an apex.

[SimplGy]

Another idea: Instead of domain name, create a heuristic for attempting to determine a canonical "Service name".

Maybe the domain is one input into this. Other inputs could be:

• The title of the page
• Contents of headings on the screen
• What other users edit the "Service Name" to be (eg: if many users converge on "Target RedCard", and there are matching signals in the page, that's probably it)

[ewjmulder]

+1 for dropping the subdomain (and definitely the protocol)
I agree with the reasoning that subdomains are susceptible for change (much more than top level domains and a top level domain change you would probably remember)
Furthermore, I noticed that on one site the site where you change your password: account.example.com is different from the site where you login: login.example.com. I guess this is the case for many other sites as well. This makes it tricky to update your current password, cause you need to take into account when generating a new password on the 'account' subdomain, that you should use the 'login' subdomain as name. For this reason I suggest just using the top level domain as default and not any other 'trickery' to find a good name. Same passwords for different subdomains is no problem for me. If people do think so, they can easily manually set a different name for those logins.

[SimplGy]

Good point. I'd forgotten about this--sometimes the same site will let you log in on their home page foo.com with a popover, or at the "main login screen" which can be login.foo.com.

[Quenz]

I would really appreciate an option to remove subdomains. I have encountered a fair few sites that are quite problematic to use with lesspass, because I often login from different subdomains, my tedious workaround is manually removing the subdomain every time.

For me at least, I don't recall encountering sites that have several logins for different subdomains, so his functionality only works against me.

Either an option to always remove the subdomain, or perhaps a little button next to the address field to remove it, then maybe clicking it again puts it back.

[guillaumevincent]

I will push an update that will change this allowing the user to choose site with autocompletion