
The URLs thing was a deal breaker as well. and in cases like this, it is almost easier to just chuck the existing stuff and start a new company from scratch. pretty much all the mechanisms that development uses.


#IS BITWARDEN BETTER THAN LASTPASS CODE#
This is something that cannot be patched in a point release, but it requires a redo, not just on the tier of a complete code refactor, but a complete redo of all processes, procedures, flows, CI/CD stuff. The fact that access was being done over what was reported as a Plex server means that there are severe holes in developing this app on a secure basis.

Hopefully all of the others will see this and point and laugh because their current internal policies and procedures would never allow for what happened to that senior developer at LastPass to happen or it will give them the kick in the ass to review their own internal policies and procedures to determine if similar holes might exist and get them fixed.
#IS BITWARDEN BETTER THAN LASTPASS PASSWORD#
Such a lack luster security posture from a password manager company is frankly unacceptable.Īt this point the thing that makes other password managers better in my mind is that the others have not demonstrated poor security awareness and poor security practice.yet. The fact that something like this was able to succeed speaks to poor security awareness on the part of the developer and, in my opinion, a piss poor security posture by LastPass's internal infrastructure and policy. The worse issue in my mind is that the environment existed that allowed the master password AND MFA of a senior developer be stolen by a keylogger that was put in place by leveraging a vulnerability in a media streaming server. Now that a bunch of vaults are out there, attackers can use that data to target people with stuff they want to steal. For example, the website URLs in the vault entries were not encrypted. They were not encrypting the entire contents of the vault. There are 2 big things that has me off the LastPass train now. I want to use a different port for vaultwarden so I can use the default port for other things, maybe a landing page or something (only for my personal use)Īnyway, thank you for asking the right questions and pointing me in the right direction! Afterwards I just changed the Port for Caddy in the docker-compose-file and the port-forwarding accordingly and it also worked with a different ports (before, I also changed the ports in the caddyfile and for vaultwarden as well, not realizing that those are just container-internal and not needed for external access at all) In my mind the ports were already in use by the router, but I just checked and this isn't the case.Īnd now that I've realized this, I tried it again with default ports in docker-compose and Caddyfile and it worked instantly. Even the dumbest routers should be able to do this. Set up a VM with Docker, Docker-Compose and Portainer to run all Containers from.Ĭould you please elaborate on why you can't port forward ports 80 and 443 on your router? That's not something I've ever heard of before. Work on getting all your stuff running from a single VM, with Caddy as your reverse proxy, also running in the compose environment.
