5
Reset password function for Shell Users
planned
A
Arni from Webdock
Allow a reset of a shell user password from the Webdock dashboard prompt for your Webdock password / 2-factor if enabled before allowing you to proceed.
Log In
Activity Feed
Sort by
A
Arni from Webdock
planned
A
Arni from Webdock
Epsilon PS _ Paul Schiffer Now that this has merged and become the proposed solution we are considering - what do you think about a small feature update where, when you create your shell user, you are prompted to save the account information to your password manager with a warning that passwords are unrecoverable, but can be reset, using this new function. These are just some additional UI improvements I thought of to further help users and make this more idiot-proof
E
Epsilon PS _ Paul Schiffer
Arni from Webdock: Yes, a very good QoL improvement. Also, with that, we could have the same info when a user first arrives at their LAMP/LEMP stack dashboard where the temp PWs are shown. And this info should prominently stay there as long as the temp PWs haven't been deleted.
A
Arni from Webdock
Epsilon PS _ Paul Schiffer: Agreed - we'll make this happen sometime soon :)
A
Arni from Webdock
under review
This is how we would implement a solution here, if at all.
A
Arni from Webdock
E
Epsilon PS _ Paul Schiffer
When you deploy a server, the dashboard of the server has every detail, like DB, WP and shell users credentials. After documenting them in your PW manager or deleting and creating your own, you should delete that widget from the server dashboard so Webdock can act as a zero-knowledge provider.
Also, having a view password toggle would be a major security vulnerability since any hacker that has access to central Webdock systems would be able to view any shell users password, and since I assume (very) many users which use Webdock run SSH on port 22 out in the open, that's a found meal for malicious actors (Idea for Arni from Webdock, implement a warning if the SSH server is accessible worldwide and running on a standard port; if that is relevant, I will create a FR for that).
If you forget the password, you should be able to reset the shell password for your user, ideally governed by again checking with a second factor like a TOTP token, to prevent any useful cookie login token theft (Another new feature request, or is that available today already?).
Also, Arni from Webdock, I noticed after writing out my thoughts, is it possible for the WebSSH client to "privately" access the server, even if no SSH port is open via the standard network interface? I mean like a console session to the VM, in case someone locks themselves out. In that case, the feature request looking to be able to access a non-port-22 SSH wouldn't be needed anymore.
And does Canny have a downvote button too for requests? How should I voice my disagreement as a user about a feature request? Can I only type out a comment? Or may "only" Webdock decide the value of a feature request?
A
Arni from Webdock
Epsilon PS _ Paul Schiffer: A lot of things to answer here :)
Ok so first off, we imagine that if we start saving shell user passwords you should be able to delete them from Webdock again, of course (just like you can with the default users on our LAMP/LEMP stacks)
Passwords are kept encrypted. But as to your next concern: If a hacker has breached us so violently that they are able to read out the encrypted SSH passwords and decrypt them as they have had access to our secret key, then we are boned regardless. They'd in that case be able to access any user account and thus any server. So in that case, it wouldn't matter if we have the passwords laying around anyway.
I don't think we need a forgot password function here. If you forget it, simply create a new sudo user, log in to your server and switch to root at which point you can set a new password for the user. Or just delete the user you forgot, provided there is no data you want to keep in the users home directory.
WebSSH cannot connect through any private pathway. WebSSH connects to sshd on your server just like any other SSH client would.
And lastly, no Canny does not seem to have a downvote button - maybe suggest it over at the Canny feature request board :D
E
Epsilon PS _ Paul Schiffer
Arni from Webdock: My stance on the matter of "the hoster saving/retaining any password to a customers server" is that it is always better to avoid having/knowing any passwords in the first place, aside from initial temporary ones, because they are needed.
What would the view password toggle achieve here? The user could get complacent while thinking "I can view the password anytime, I don't need to know or save it" (or even better, they don't even have a PW manager to save to, the worst thing to do in this modern world). Also, how would you catch a password change started from within the OS? The view password toggle would only be viable if all PW changes happen within the Webdock dashboard (which can't happen at the moment since the dashboard doesn't allow a PW reset), and as we established, as soon as you change the PW on the CLI, the dashboard PW is useless.
And on the topic of a hacker breach, I didn't mean that the malicious actor would breach the DB to read out the encrypted PW and the secret key and salt, they would attack the management system. So if I assume the Webdock staff also uses the Webdock dashboard in some capacity, then I would only need to phish an admin account for that system, select a server and click on the view password toggle. The same goes for a customers dashboard access, I would phish that, even easier if not protected by 2FA, and just look at the shell PWs.
So, to summarize at the end here, encrypting and storing passwords is always a risk for any system/infrastructure it is implemented on, and no use case for easier handling should outweigh these security concerns in its favor.
E
Epsilon PS _ Paul Schiffer
Arni from Webdock: Also, focusing on the PW reset function for a moment, having this would massively lower the amount of steps needed if someone forgets their password.
So instead of having the Webdock dashboard act as a makeshift PW manager, which it should never be, make the process to reset a forgotten PW easy and secure, so a view password toggle is never needed in the first place.
The steps you mentioned which work today of course exist, but even the risk of loosing data in case the shell user gets deleted stops non-pro users from doing them and because of that fear, this FR was born.
A
Arni from Webdock
Epsilon PS _ Paul Schiffer: I tend to agree with you here :) You have convinced me that the correct solution is a "forgot password" function which resets the password through our hypervisor, after an account (password and two-factor if enabled) confirmation. I'll create a new FR and merge this in there.