Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mysql hashed passwords for FTP user #248

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bbspike
Copy link
Contributor

@bbspike bbspike commented Feb 24, 2016

Passwords are hashed and stored in MYSQL

Passwords are hashed and stored in MYSQL
@MBlagui MBlagui self-assigned this Feb 24, 2016
@MBlagui MBlagui added this to the 1.0.5 milestone Feb 24, 2016
@MBlagui
Copy link
Contributor

MBlagui commented Feb 24, 2016

I will delay it until I figure out how to upgrade?
I means we change FTP module too and users will no more see the passwords.

Thanks it really helps.

@eByte23
Copy link
Contributor

eByte23 commented Feb 24, 2016

If your worried about functionality for users I'd suggest using mcrypt_encrypt() that way your only encrypting the password, and the user would still be able to it see all passwords as previous but just stored encrypted in the database. But for me if you were wanting to be more secure don't store that password because once you hash the password there is no point keeping it as you can't do anything with it.
Elijah

@bbspike
Copy link
Contributor Author

bbspike commented Feb 24, 2016

Yes hashing is more secure. Should be the way. For functionality we can always make a feature in the module that sends the password by mail to the creator once when a ftp user is created.

@MBlagui
Copy link
Contributor

MBlagui commented Feb 24, 2016

Users can always reset the password at any time. I survived with a panel that never showed the password once you set it. For email or ftp. No recovery but we were able to reset it. Even if the password was not hashed (but panel vendor didn't show it).

@eByte23
Copy link
Contributor

eByte23 commented Feb 24, 2016

Yes, I believe that's how it should be.
@bbspike if your hashing the password the is no reason to put into the database, for that matter there is no reason to hash the password you only use the password to create the mysql/ftp user then dispose it. Because you cannot reverse a hash there is no reason to store unused data.

@MBlagui
Copy link
Contributor

MBlagui commented Feb 24, 2016

@eByte23 this is FTP password and we need to store it for ProFTPD authenticate against the hash.

@5050
Copy link
Contributor

5050 commented Feb 25, 2016

Hi,
I agree that hashing the password is better for security in case of the server is hacked.

On other side, for personal server (1 admin, no reseller, no client), it is easier to be able to see the pass rather than changing each time lost password and then reconfigure each computer, phone, etc of stunned friends who where given an access to exchange files.

What would you think to add a checkbox for each account labelled like "Do not encrypt password (WARNING : unsafe)" ? It wound be unckecked by default and checkable only on first password creation (as soon as unckecked, it can not be checked again).

More, if the change is commited as-it-is, it MUST be remainded that applying it on a server will screw all old accounts with password not encrypted -> a tool must be provided to update all uncrypted password.
Adding the checkbox (set checked for all old account) would give full compatibility.

At least, if password is encrypted, it must be not viewable (or replaced by "crypted" ?) in the interface because it have no sense. => the change must include a touch of the UI.

@MBlagui
Copy link
Contributor

MBlagui commented Feb 25, 2016

@5050 we can think about trying to support bot solution. But witching will require rebuilding the passwords and it can be done only from clear to encrypted.

We can also at least encrypt the password in standard ( could be reversed ) and use hashes in secure mode.

We should push security over connivence some time.

@bbspike
Copy link
Contributor Author

bbspike commented Feb 25, 2016

I bit disagree. Secure should here be the priority. Everything else (exept mysql) is hash and not retrievable.

Although i understand you @5050 but lets face it, Sentora wants to profile as a proffesional hostingpanel right? Not as a personal panel for soem "friends", there are simpler and other solutions enough for that purpose.

Proffesional and secure.

@TGates71
Copy link
Member

@MBlagui to upgrade, wouldn't a simple password reset fix it? If so, I think we should merge this in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants