(02-27-2009 06:31 AM)sci2tech Wrote: Google translator is not quite good, but I understand that you need to know how passwords are encrypted / decrypted.
$ispcp_db_pass_key and $ispcp_db_pass_iv are generated on install and saved on ispcp/gui/include/ispcp-db-keys.php.
Code:
function decrypt_db_password ($db_pass) {
global $ispcp_db_pass_key, $ispcp_db_pass_iv;
if ($db_pass == '')
return '';
if (extension_loaded('mcrypt') || @dl('mcrypt.' . PHP_SHLIB_SUFFIX)) {
$text = @base64_decode($db_pass . "\n");
// Open the cipher
$td = @mcrypt_module_open ('blowfish', '', 'cbc', '');
// Create key
$key = $ispcp_db_pass_key;
// Create the IV and determine the keysize length
$iv = $ispcp_db_pass_iv;
// Initialize encryption
@mcrypt_generic_init ($td, $key, $iv);
// Decrypt encrypted string
$decrypted = @mdecrypt_generic ($td, $text);
@mcrypt_module_close ($td);
// Show string
return trim($decrypted);
} else {
system_message("ERROR: The php-extension 'mcrypt' not loaded!");
die();
}
}
function encrypt_db_password($db_pass) {
global $ispcp_db_pass_key, $ispcp_db_pass_iv;
if (extension_loaded('mcrypt') || @dl('mcrypt.' . PHP_SHLIB_SUFFIX)) {
$td = @mcrypt_module_open (MCRYPT_BLOWFISH, '', 'cbc', '');
// Create key
$key = $ispcp_db_pass_key;
// Create the IV and determine the keysize length
$iv = $ispcp_db_pass_iv;
//compatibility with used perl pads
$block_size=@mcrypt_enc_get_block_size($td);
$strlen=strlen($db_pass);
$pads=$block_size-$strlen % $block_size;
$db_pass .= str_repeat(' ', $pads);
// Initialize encryption
@mcrypt_generic_init ($td, $key, $iv);
//Encrypt string
$encrypted = @mcrypt_generic ($td, $db_pass);
@mcrypt_generic_deinit($td);
@mcrypt_module_close($td);
$text = @base64_encode("$encrypted");
$text=trim($text);
return $text;
} else {
//system_message("ERROR: The php-extension 'mcrypt' not loaded!");
die("ERROR: The php-extension 'mcrypt' not loaded!");
}
}
Thanks. At the moment I think about on how to revert the changes to ispcp concerning cleartext switch to blowfish. As of many peoples view it really is bad to store passwords encrypted in databases. It does not bring security, it costs security. The administrotor of a server does not need to know passwords of resellers or guests, because he is the root of the server and he can see all data directly without the need of fetching the passwords from the db. If he/she wants to see private data, he always could change into the directory and see, what he/she wants to see.
The database server itself needs to run safely. You never would let run mysql on 3306 on 0.0.0.0 without packat filtering, etc. In our case, the mysql server does have its own virtual server.
Postfix and doveccot themselves could use challenge/response methos over unsecure connections. But with passwords encrypted in the database, only PLAIN and LOGIN are left over. So you have to force customers to use SSL, if you want to prevent them from using plaintext over unsecure connections! Does not really make sence.
Second, if providing ssl, and you do have about 1000 or more accounts on a server, you will recognize more cpu usage on the ssl encypted lines (although this should not really be a big factor). But normally you would not need to provide ssl (see Web.de, GMX.de).
So the decision to switch to blowfish-cbc was in fact a really bad decision. To summarize in short:
- Do not protect passwords against the admin (it does not make sence)
- Protect client/server connections with hashed/encrypted passwords.
So I hope, developers will realize that it cost security. Reading a pdf about hardened Linux must be challenged, before simply coding it 1:1. For more information on encrypted passwords you are welcome to subscribe any postfix mailing lists. You will meat people like Patrick Ben Koetter, Ralf Hildebrandt or Peer Heinlein and you shortly will understand, your decision was completley wrong.
Because English is not my mothers language, I please you not to understand it too hard. I hope, you could follow my opinion and maybe you will discuss this internally.
Kurze Anregung:
MySQL-Rechte für _alle_ Passwort-Felder der ispcp-DB setzen auf: UPDATE, DELETE und INSERT. Wenn Passwörter nicht sichtbar angezeigt werden, dann benötigt es auch kein SELECT. Damit kann dann auch ispcp potentiell Sicherheitslöcher haben, ohne dass man von außen auf die PWs zugreifen könnte. Für Courier und/oder/Dovecot bzw. Postfix empfehle ich dann einen extra User, der hier sogar _nur_ SELECT-Rechte hat. So haben wir das jetzt umgesetzt.
Beispiel:
GRANT SELECT ON ispcp.* to mailadmin@'somewhere' IDENTIFIED BY 'Bla';
Reicht hier aus.
Eine weitere Alternative wäre, dem Administrator in der Weboberfläche selbst die Entscheidung zu überlassen, ob er clear oder encrypted die Passwörter verwalten möchte.
Ich bin selbst Entwickler (Student in den allerletzten Zügen) und liebe es mich mit Security zu beschäftigen. Ich kann mir auch aus Erfahrung sehr gut vorstellen wie das ist, wenn man viel Zeit in Sourcecode hineingesteckt hat, um eine Funktionalität zu programmieren; plötzlich wird einem von außen gesagt, dass das nicht gut war; nun soll man diesen Code wieder verwerfen. Aber das ist eine Erfahrung, über der man glaube ich stehen muss :-) Manchmal programmiert man halt etwas für die Füße *g*
Aber weiter werde ich jetzt auch nicht meinen Senf dazu geben, dass müsst ihr jetzt selbst überlegen und entscheiden. Es ist letztlich nur Uwes und meine Meinung.
Search
Member List
Calendar
Help
/
Umsetzung Fremd auf ISPCP
RE: Umsetzung Fremd auf ISPCP 
