Mysql hashed passwords for FTP user

[bbspike]

Passwords are hashed and stored in MYSQL

[MBlagui]

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]

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]

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]

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]

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]

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

[5050]

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]

@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]

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]

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