Pull to refresh

Comments 24

MD5 можно заменить на что угодно, да и, как мне кажется, для хранения паролей в БД для FTP-сервера — более чем достаточно.

можно заменить на что угодно, но смеются над конкретным выбором.

У Вас есть что предложить на замену моему варианту? С радостью это реализую.
UFO just landed and posted this here
В результате я получил FTP сервер с хранением паролей пользователей БД в шифрованном виде

В шифрованном виде — это не совсем так, так как функция md5 не шифрует, а делает хеш.
У меня не просто md5 hash, см. в скриптах как генерируется пароль:

my $encrypted = unix_md5_crypt($ftppass, $salt);

sub gensalt {
my $count = shift;
my salt = ( '.', '/', 0… 9, 'A'… 'Z', 'a'… 'z' );
my $salt;
for (1..$count) {
$salt .= (salt)[rand salt];
}
return $salt;
}
Смысл в том что шифрование означает что данные можно позже расшифровать, а вот хеш-функция необратима.
Скажу честно — я этого и добивался. Возможно, где-то есть неточности в формулировках.
Немного не в тему:
Может ли proftpd работать за NAT (пассивный FTP-режим) одновременно обслуживая внешних клиентов и внутренних? Т.е. если клиент коннектится извне, ему предоставляется белый IP, внутреннему же — адрес из локальной сети.
Да, вполне. У меня именно так он и работает. Мало того, снаружи он виден через 2 NAT-а, один — провайдерский BINAT (как он устроен я не знаю), второй — проброс портов с Cisco внутрь сети.
За это отвечает параметр MasqueradeAddress — настраиваете виртуал-хосты и смотрите куда угодно как угодно.
В pgsql необязательно перечислять все поля при инсерте, если для каждого поля вы передаете значения. Также, вместо nextval('users_id_seq'::regclass) можно использовать default. В результате, запрос из скрипта будет таким:
INSERT INTO users  VALUES (default, '$ftpuser', '$encrypted', '$salt', '$Config{ftp_groupname}', '$Config{ftp_uid}', '$Config{ftp_gid}','$Config{ftp_dir}/$ftpuser', '$Config{ftp_shell}', NULL, 0, NULL, 0)


Спасибо, буду знать.
Рекомендую посмотреть в сторону SCRAM (RFC 5802) или Argon2 и не заниматься изобретением детских велосипедов. Обе схемы легко модифицируются под конкретные нужды системы, например, добавлением каких-либо специфических данных при проверке пароля. Так же легко можно сделать миграцию текущих открытых паролей пользователей в SCRAM, чтобы пользователям не пришлось перерегистрироваться или менять пароли.
Теоретически — можно, но мне на данный момент этой схемы более чем достаточно для моих нужд.
Будет необходимость — обязательно воспользуюсь Вашим советом.
Суть современных методов парольной аутентификации в том, чтобы проверка правильности пароля проходила долго (SCRAM), а лучше долго и дорого (Argon2). Использование одной итерации хэша MD5 практически ничем не отличается от хранения пароля в открытом виде. Если кто-то угонит базу паролей (а он обязательно её угонит, если она будет стоить того), то он сможет за небольшое время вскрыть её всю. Плюс необходима защита от прямого перебора паролей снаружи: при отрицательной проверке пароля делать случайную задержку ответа на несколько секунд (5-15).

salt нужна для того, чтобы одинаковые пароли пользователей выглядели в базе по-разному. В идеале — это набор байт, полученный криптостойким генератором случайных чисел. Не стоит заморачиваться на какие-то околослучайные алгоритмы, можно просто прочитать в массив из /dev/random и обернуть его base64 (или чем-то другим по вкусу). Главное, чтобы этот набор байт был достаточно длинным, чтобы при подборе паролей нельзя было сгенерировать в памяти сразу все возможные варианты salt и быстро прогнать с ними хэш-функцию.

Если не секрет, у вас в proftpd настроено TLS шифрование?

Нет, не настроено. Настроить не составляет труда, но для моих пользователей слишком сложно объяснить, как подключиться через TLS, а не по стандартному 21 порту.

Я наверное не открою Америку, если скажу, что пароли в FTP передаются простым текстом.
Но все же порекомендую посмотреть в сторону scp/sftp.
В GUI клиенте сейчас оно настраивается не сложнее, чем ftp (нужно просто указать, что это sftp).
Шифрование из коробки, плюс сразу отпадает морока с портами и режимом передачи ascii.

SFTP прекрасен, еще и авторизации по ключу и никаких проблем :)
Действительно не открыли Америку, scp/sftp (первое предпочтительно) активно использую в личных целях, но когда вопрос идет про юзеров, которым и про существование FTP приходится объяснять что это такое — лучше FTP я пока не видел. По нему хотя бы мануалов более чем достаточно в сети.
Мы у себя используем proftpd. У нас, я сделал связку с LDAP и управление идет через группы в AD. По моему в корпоративной среде проще интегрировать с ADчем на каждый сервис держать пароль.хотя тут встает вопрос безопасности, но это отдельная тема. Автору спасибо.
У меня немного другая постановка задачи — юзера «левые» в большинстве своем и к AD никакого отношения не имеют.
Sign up to leave a comment.

Articles