-
-
Here the answer from sci2tech in the internal forum on the same question:
Quote
RE: Mailpassword in Database not crypted???
Is any reason to be crypted? Was a mistake I did with ispcp and I corrected now. If someone get access to imscp database that will be last thing to worry . Crypted or not, that person will have access to all your data in computer (mail, passwords - yes he will be able to decrypt them - and with minimum effort, root access) . Thats security through obscurity and is not even a bit an improvement =)).
Do not belive me? just send me access to a system with ispcp / imscp and db access to it, and I`ll forward to you all data you want -
-
Here the answer from sci2tech in the internal forum on the same question:
Having the passwords encrypted on a reversible format maybe is not that good idea, cause there will be always some way to have them reverted to cleartext.
Anothere approach would be to use directly a good cyphered format to store the passwords, for example using MD5-CRYPT is widely supported, and gives you the same level of security than the shadow file of linux, if someone loses his password you can simply reset to a new one.
For example in dovecot there are lots of supported schemes: http://wiki.dovecot.org/Authentication/PasswordSchemesAre there any practical reasons to have the passwords in cleartext?
-
Well, there are in fact some points when the original password is needed:
- direct link to phpMyAdmin (incl. login with a certain user).
- changing e.g. the pop3/imap server (courier -> dovecot) etc.Maybe a big part could be managed by storing some different hash values of the password in the db (pw_md5, pw_rsa1, etc...) - maybe with some code changes on pma... - and for the really big things (server migration changing of daemons etc) - I think of private/public-keys: storing the password encrypted with a publickey - and when the admin neeed the original he has to enter the private key.... (of course only with https
Maybe this can be a way....
/J
-
-
Well, there are in fact some points when the original password is needed:
- direct link to phpMyAdmin (incl. login with a certain user).
In this case it's true, it would be unconfortable for the users having to enter the password every time so I wouldn't change it at this moment.
- changing e.g. the pop3/imap server (courier -> dovecot) etc.
Looking at the format that courier is using, I see that passwords a in the form :
systempw=$1$XjwfWiax$E.on9bnXxlhiMddGsieCA1
That means that courier is using passwords generated like userdbpw -md5 with the md5 hash.
If the passwords were stored just like that, dovecot could read them without any problem (in fact I am using them like this in every installation no i-imscp)
So there are two solutions:
.- changing in the dovecot-sql.conf -> default_pass_scheme = CRYPT
or adding the
.- $1$ in front of the passwords, dovecot will read the $1$ and know that its a hashed password in the format crypt-md5What's your opininion?
[hr]
An interesting link about this topic: http://www.leidinger.net/blog/…-imap-to-dovecot-is-easy/ -
I think storing one hash only is to few.. the hash algorithms also getting better and better - in a few years maybe md5 is not secure - so changing the hash is needed -> for this occasion the private key can be entered by the admin -> the passwords are hashed again into a new field... (sha1 or whatever).
For the pma problem I think there might also be a solution (only give the hash and pma compares them...)...
For the moment sasl is also a problem - look into /etc/sasldb2 - you can read all the mail passwords...
/J
-
-
I think storing one hash only is to few.. the hash algorithms also getting better and better - in a few years maybe md5 is not secure - so changing the hash is needed -> for this occasion the private key can be entered by the admin -> the passwords are hashed again into a new field... (sha1 or whatever).
For the pma problem I think there might also be a solution (only give the hash and pma compares them...)...
crypt-md5 in not only storing the calculated hash, it's what is currently done in the /etc/shadow files (see here), it's quie difficult to crack, because it's adding salt and 1000 rounds of md5.
In any case, when something better is in place, we could do like they did in wordpress when they upgraded their password cypher, one script that updates the hash whenever the user is successfully logged using the old schema.
For the moment sasl is also a problem - look into /etc/sasldb2 - you can read all the mail passwords...
For sasldb2, it could be provably avoid, someone accomplished it while on ispcp (here) -
Storing password sin cleartext is sufficient. We will not change that again.
-