Removing the database does not imply that the functionality must be removed #747
Comments
|
@ogarcia I don't have a solution for this (yet). The purpose of this change is to no longer have to maintain code for the connected version. I don't want users to set up a LessPass server. They are more in danger than setting up a Birwarden server or using KeepassX or pass. Maybe I can create a separate repo for the legacy web extension. And let people install this one. |
|
I'm also ok to display the other servers implementations in the wiki or the |
|
The truth is that I don't see the difference between having your own personal API server where you store the password definitions (which are worth little or nothing without the master password) and making an export of the settings and copying that export to, for example, dropbox. Both are dangerous in their own way. In fact I personally find the latter more dangerous than the former. And the second is what is likely to happen from the moment that the possibility of having your own server is eliminated. For me the difference between one and the other lies in the fact that if the API support is removed it is much more cumbersome to keep your information synchronized between different devices. Remember that whether or not to use your personal API server is an option. If the user wants and assumes the risks of using that option, perfect, if not, then he will use the export or not use anything at all. Personally I find the functionality very interesting and I do not see that it is a risk to have this functionality, at least not a risk greater than the fact of being able to export the configuration to a file. As I said before, for me the risk is the centralization, that is to say, that all the clients use the same API server. As for having to continue to maintain the API server implementation. That can be delegated to third parties. Simply set the standard (which is already described here), move the current server implementation to a new repository and indicate that it is an example and let everyone use it at their own risk. You simply maintain the functionality as an API client, which is far less effort than having to support the entire stack. In short. I would keep the client functionality and leave it up to the community to install, configure or develop their own server implementation. |
Unfortunately that's not true. Most of my dev time on LessPass is for the connected version on the clients.
I think I was misunderstood. In terms of security, I encourage people to self-host a Bitwarden server rather than a LessPass server. The data is encrypted, there are security audits and it is actively developed. LessPass is a static password manager, and it was a mistake to make it look like a normal password manager. |
|
Could you please explain what is the suggested way of using LessPass going forward? Are you suggesting to keep password profile in a separate application? Are there any plans to load password profile from a file (or separate application) or is user supposed to manually set options each time he/she wants to login to a website from now on? |
I recommend using LessPass as a simple deterministic password generator. No password profiles. The plan is to remove user password profiles. |
|
User profiles are essentials and they make this approach practical. |
This is because you are using LessPass like a normal password manager. Bitwarden is just an example. LessPass should replace user password profiles with community password profiles. |
The problem with that is that when you have about 500 different logins it is a bit complicated to remember which configuration you have set for each login. On this site had I used symbols? How many times had I rotated the password on this other site? Leaving lesspass only as a deterministic password generator without anything else would directly kill the project. In fact a deterministic password generator is something as simple as this (with a couple more lines you could include the options of only letters, numbers, symbols, etc.): read -p "Login? " login
read -p "Username? " user
read -p "Master password? " pass
read -p "Counter? " counter
read -p "Password size? " size
string="${login}+${user}+${pass}+${counter}"
sum="$(echo $string | b2sum | cut -d' ' -f1)"
echo ${sum::$size}
These are just the rules that a password must comply with to be accepted by a site. It has nothing to do with the settings you make to generate the password. |
|
Moreover, what you propose is already implemented in multiple solutions (with the LessPass algorithm):
And this is just a sample, there are a few more. |
You should not remember those configurations. Most of them should be the default one.
You completely neglect the user experience.
The future will tell. The safety of LessPass's users is more important than the success of this project. The other problem is that maintaining a connected version take me a lot of time. I want to simplify by putting this part aside. I know there will be people who disagree with this decision. As I wrote, it's not an easy decision. But it's mine. |
The biggest problem is not the options, it's the counter. Personally I usually rotate passwords (just like everyone else I think I should). Remembering which counter I go to for each site is simply impossible.
And seek help in the community? I am not a frontend developer and in that part I could not help. But in the backend part (as you can see from my initial comment) if I can make developments to have those parts covered. Like me there are probably many people interested in giving you a hand if you ask for it. |
LessPass provides the conservative minimum of profile management to completely obviate the need for “password managers.” I used LastPass for years, and ditched them over two years ago upon discovering this project and haven’t looked back. I have to be honest with you, from years of using this with all sorts of quirky websites with Byzantine security policies, including schools, banks, local functions, and government websites, I know for a fact that LessPass is a useless project that is not worth using at all without the configurability. It will simply break upon encountering these sites, and it is a non-starter to simply suggest to users that they take it up with site owners. That’s like stiffing your waiter because you don’t believe in tips – it’s not the users’ fault some websites they use have bad password requirement policies. LessPass should be helping them maximise the amount of password entropy despite that, not casting them aside.
The future is now, and I can tell you that if you kill the configurability storage feature outright, it will spell the end of your project. This is a purely technical problem, and while I understand that you have limited time because this was always a volunteer project, it still does not change that fact. LessPass will no longer be if you remove the key feature of coping with the diversity of password policies on the Web.
In open source, you can never really kill a project. You only let it live on as far as it’s useful by other names and other maintainers who are more capable than you. If this change goes ahead as planned, I will have no choice but to freeze updates on the LessPass clients I have and begin working on my own server solution. There’s no practical alternative for me because I need the metadata used to generate my passwords, not the passwords themselves – kind of the whole benefit of using this program! As an aside, it’s kind of terrible that LessPass only offers to export the passwords directly instead of giving me the site metadata so I can import it into an application that can use it. I switched away from LastPass over two years ago as an enthusiastic early adopter of this app, and I am severely disappointed to find out that it’s liable to come to such an abrupt end like this. It’s all the worse that users are apparently faced with the prospect of data loss with no export option for metadata. All of the talk about user safety just smacks of paranoia – I avoided multiple real data breaches from switching away from stateful password solutions to this. I really had hoped for better. |
|
@nicholatian you can export all your data using the lesspass CLI with the |
|
I would like the discussion to remain calm. @nicholatian Everything is open source and I spoke about creating another web extension for the connected version. This is not what I called an abrupt end.
How many of them could be shared among LessPass users? |
|
@nicholatian, I understand your disappointment, and we do our best to support our community. Thanks to previous work by @guillaumevincent, you can export your profiles using the python CLI: InstallationUsageFiles will be located in Cleanup |
|
Thank you @guillaumevincent for all your work on LessPass, it's a great project!
Why do you compare the profile storage with other solutions that store the password itself? I can see the problem with the data being saved without any encryption, but it's still only the profile information. Master password only exists in our heads. |
|
@edouard-lopez There are many options for exporting profiles, you can use my own client implementation in Rust:
|
|
I am happy to tell you that my implementation of the lesspass command line in Rust, lesspass-client is complete. This means that it supports all options. You can list, create, delete, export, import, etc. Exporting and importing is especially useful for the current problem since you will be able to export your data from the official LessPass server and then import it wherever you want. This can be done as follows: lesspass-client -u [email protected] -p apipass password export - | \
lesspass-client -s https://my.server.com -u [email protected] -p apipass password import -Or using a file (take note that files are unencrypted): If you do it this way you can make a backup of the exported file. In addition, lesspass-client has many options, but it is perfectly documented in the help included in the command. If you find any issue or something that can be improved, open a ticket with no problem. |
|
So will Local DB remain functional? |
They are different concepts. On the one hand Bitwarden stores arbitrary information in an encrypted form with a master password and on the other hand LessPass generates an output from a set of input parameters. As @cristianemenna commented above, the former has nothing to do with the latter. If someone steals the Bitwarden store sooner or later they could get all your passwords out through a brute force attack (since your passwords are stored in that store). However, with LessPass parameters it will be a bit more complicated. Because, even using brute force the attack, vector is different since the tests would have to be launched directly against a specific site, and not against the storage itself, and it is normal that the specific site blocks the user after a number of attempts. Personally I am not going to encourage people to migrate from LessPass to Bitwarden for the reasons stated above. In fact before Bitwarden to store encrypted data I would recommend KeePassXC (or any other KeePass implementation) and that the password file never leaves your local machine.
For now the future of LessPass is under discussion. Possibly as @guillaumevincent has commented it will be split into two parts. On the one hand a simple password generator from input parameters and on the other hand the API client. But well, this is his decision and let him be the one to decide what is best for the project. As for Spectre, it is actually similar to LessPass with a different algorithm. For now Spectre's functionalities are basic, it is simply a deterministic password generator without any parameter storage function or server API. But this does not mean that Spectre is dead, just that the developer is slowly implementing the features, in fact he recently answered a similar question. |
In my opinion, Bitwarden for storing profiles instead of passwords would be even more secure than hosting your local db, even hosting your profiles db is better than keeping your password in Bitwarden. BTW as suggestion for LessPass, It would be better if we had a a secret field for each website so even if MasterPassword is leaked, that would prevent from leaking all passwords, As referenced here.. |
IMHO, it's all about finding a balance between security and usability. Storing profiles in a local DB with your own personal API server is better than storing them in Bitwarden (in either case). Now, storing the profiles in a personal Bitwarden instance is more secure (and therefore better) than using the local DB with your own API server, but it makes it less usable since you have to manually enter the settings. But in the end it is as I said before. If you are going to store the profiles in Bitwarden you can do it perfectly well in KeePass and you save the process of setting up a Bitwarden infrastructure. Another option would be to implement data encryption at the client level, so that your API access password (without encrypting it) would be used to encrypt the data. Let me explain. Right now the API access password is encrypted with LessPass itself and with some fixed parameters so that for the user The problem with all this is that it would complicate the implementation of the client and you would not have a substantial benefit (always taking into account that the database is local), so we return to the initial problem of cost-benefit.
You can do that right now by adding the salt to the master password. For example, if your master password is |
|
@cristianemenna if you self host LessPass Database and get hacked, you loose all your password profiles. Somebody can craft a service to get a generated password in order to brute force your master password. If a hacker stole your keepass vault, then a hacker need to bruteforce it in order to find all your passwords. It's (much) easier to brute force a LessPass generated password than a Keepass vault. And I know, they need an extra generated password. But other information, like the list of services you use, can be also dangerous. So hosting a LessPass Database server, without any audit, without cryptographic experts work, put you in danger. More than using Keepass |
@guillaumevincent I'm sorry, but I disagree with that statement. The difficulty (talking about finding the master password) when doing a brute force attack on LessPass, KeePass or even a Bitwarden vault is exactly the same. Now, in both KeePass and Bitwarden when you have found the master password you know it because you are able to read the contents of the vault (and therefore it does not involve anything other than your local machine doing the attack). This does not happen with LessPass, because to know if you have indeed found the correct password you have to try one of the sites you are generating the password for. Here is an example. On one side I have a KeePass file (the same happens with Bitwarden) where I have stored the access credentials to GitHub and GitLab with the master password |
|
I would like to second, that leaving the API feature to store ancillary data in a user specified API Server (not centralized) is a major benefit and a feature that I would be upset to lose. In fact, I host my own instance of the rockpass server created be @ogarcia and connect all of my browsers to it. If you cannot be swayed, please at least create a legacy fork, tag, or branch that we can fork to continue using this feature even after you remove it from your continued development of LessPass. |
|
@ogarcia no I compared brute forcing master password to generate one password a hacker stole. Look at the white paper on how KeePass tempered the brute force of the file. |
|
@tazdij yes this is the plan I also thinking about letting LessPass like it is today, and doing full static version with another name. |
|
@guillaumevincent I just realized that with the latest update of the plugin it is not possible to create new accounts, I understand that it is because you do not want new accounts to be created on your server, but by limiting this option you prevent that accounts can be created on other servers. I don't know if it is possible to change the logic in such a way that if you have configured something other than Many thanks in advance |
|
are there any browser alternatives we can use instead that keep this functionality? it seems we only have about a week left until this app is dead, and I would like to be able to carry on at least on my browsers if not mobile apps too. |
|
@ogarcia yes I could bring back the page and make it more user friendly to connect to another server. @nicholatian what do you mean? The server will be shut down but the clients will remain intact. |
@nicholatian I agree that the lesspass "system" will essentially be dead after the servers are shutdown. However it seems @guillaumevincent will be either leaving a legacy branch or adding the API Server URL back into the settings to allow anyone to host their own API Server and connect the App and Extensions to it. I am running a docker of rockpass server written by @ogarcia. This is working very well so far. If you do host your own, do take the time to configure all traffic to be HTTPS and you can always utilize LetsEncrypt to get a free SSL Cert. |
@guillaumevincent I think you might be underestimating how useless many of us think LessPass will become without some sort of hosted database (The API Server) to store and retrieve the password properties from. I for example, use a random Basically LessPass with its server has been hugely helpful and significantly simplified my password situation, all without ever storing an encrypted form of my passwords. I am very happy you seem willing to retain the server features in the extension (and mobile app?) I honestly like the idea of a self hosted API Server more than the central one. As long as the extensions retain this feature, I believe this is an improvement. |
|
Yeah, this whole change removing the API does a lot more harm than good. I don’t think anyone would have had an issue if you just had to close the official LessPass API server. I have operated a dedicated server for years because it saves me so much money compared to SaaS solutions, and would have gladly fired one up, but now it’s being killed and I have to seek alternative solutions. |
|
@nicholatian please read my post again. I will leave LessPass intact. On the clients (mobile, web extensions) I will add an additional field to connect to a self-hosted server (today this field is in the settings page). I will put back the account creation page. If I'm doing a pure static version, I'd use another name. I'm just going to shut the server hosting the free server down. |
Glad to hear you’re walking it back. I look forward to using LessPass for many years to come. |
|
@guillaumevincent How do you feel is someone in the community were to fork LessPass (Legacy) with the central server or self hosted server capability and continue developing it as a forked project with a new name? You would then be able to continue with LessPass returning it to your original vision, without many of us being left behind. I would think this should satisfy everyone's considerations. Those who want a Stateless Password Manager with a central Options/Profile storage and those who want more a Stateless Password Generator. Would you be offended if this were to happen, or would you be supportive of this? |
|
@tazdij IMHO, since Guillaume has expressed that he wants to keep this version of LessPass operational (the only thing he is going to do is to remove the central server) I think it would be much better to support the development here than to make a fork of the project. I imagine that if someone is willing to contribute I don't think they would have a problem with their merge requests being merged. |
|
Thank you @ogarcia for initiating this important discussion, and thank you @guillaumevincent for understanding our needs. I am delighted to know that the LessPass extension and mobile app still support the current ability to store and load password profiles. I recognize the importance of having a secure storage system for password profiles, especially given the frequency of data breaches. Enabling users to store their password profiles themselves can significantly minimize the impact of such breaches. @ogarcia, I want to express my gratitude for providing the RockPass option. I find it very helpful, and having it readily available as a Docker image saves a lot of hassle. Personally, I prefer cloud-native serverless applications because they tend to have integrated solutions for common problems such as SSL offloading, certificate rotation, scaling, deployment, backups, and logs. Therefore, I created an alternative called ServerlessPass for people like me who prefer cloud-native applications. The repository contains a CloudFormation template, making the deployment process very simple. I hope you don't mind me posting the link here. I've been using LessPass for ages now, and it's a tool that I can't imagine my life without. It's so simple yet so powerful, and it allows me to sleep well at night knowing that my passwords are secure and that I can easily access the password for each website I use. Thank you again @guillaumevincent for developing and maintaining this project. |
@guillaumevincent I have just created a new page on the wiki listing the third party implementations that I have tested and know to work. I have also put a link to this new page from the wiki home page. Of course, feel free to modify whatever you consider necessary. It occurs to me as an improvement that you could put a link to this page from the README in the information section so that people know that although the server is going to be shut down there are other options they can use. |
|
@ogarcia yes this is a good idea. Can you send a PR to edit the readme? |
|
Done in #763 |
The truth is that I didn't quite understand if the announced change is also intended to remove the functionality of being able to connect to a Lesspass API server.
In my opinion, removing that functionality would be a mistake. I think it's right not to provide a centralized service for this, but people in general should not be prevented from setting up their own private server and keeping their settings there as they want.
For example in my personal case I am using my own implementation of the LessPass server which is perfectly valid for personal use and that anyone could set up at home.
I would propose to keep the functionality indicating that if you want you can set up your own local server (commenting the possible risks involved) and even have a list of server implementations so that users can choose how they want to use the system. A Wiki entry could be dedicated to this topic.
The text was updated successfully, but these errors were encountered: