Neitr, потому что выжирается канал в самом узком месте, если у вас до роутера 500 Mpbs а по тарифу провайдер режет 100 Mbps, то канал до роутера вы никогда не выжрете. Даже если у вас по тарифу больше чем до роутера, вы все равно будете упираться в узкие места по определенным направлениям раньше, чем в производительность канала до роутера.
Храните рефреш токен в куке выделенного поддомена с o2 провайдером на стороне клиента, на стороне сервера храните в базе хешем.
Аксесс токен нормально делать JWS и можно хранить и не в куке, но всю статику в любом случае лучше унести на отдельный домен. Анонимные концы тоже можно унести на отдельный домен с CORS'ом.
> Не совсем. Токен подписывается на сервере и "левый" или измененный токен не пройдет проверку.
Вы путаете две разных технологии. JWS (подписаный JWT) позволяет не хранить токены в базе. Альтернатива это не использовать подпись и вместо этого хранить токены в базе (предпочтительней в виде хешей) и сверять их по значению в базе, а не по подписи. Подпись в таком случае не требуется. Так вот для refresh-токенов обычно используется именно второй подход по причинам описаным выше.
VolgaVolga, при хранении хеша нет рисков "украсть", о которых вы пишете.
Самая частая причина хранения рефреша в том, что для рефрешей обычно не используется JWS, а используется случайная строка, соответственно переданный токен сравнивается с хранимым в базе. JWS выгодно использовать только для access токенов, потому что их требуется проверять гораздо чаще и JWS позволяет делать это децентрализовано без запроса к базе + нет необходимости их отзывать, с чем у JWS проблемы. Рефреш токен всегда проверяется централизовано, поэтому каких-либо преимуществ у JWS нет а проблемы с отзывом есть
Простой пример такой. Например вы хотите не хешировать пароли, а шифровать (например на стороне клиента) и у вас хранится 100000 шифрованных паролей. Без IV одинаковые пароли будут иметь одинаковое значение в шифрованном виде, и по повторениям одного и того же шифротекста можно будет не только увидеть для каких учеток заданы слабые часто используемые пароли, но и довольно легко угадать их, зная примерное распределение словарных паролей по частоте использования. Примерно то же для файлов, например есть у вас 100 конфигурационных файлов с единственной строкой enabled=0 или enabled=1, без IV или со статическим IV можно будет сказать какая у вас конфигурация, если угадать значение хотя бы одном файле (что обычно не проблема). Со случайным IV одинаковые файлы или пароли будут иметь разное значение шифра.
В режимах OFB и CTR IV еще более критичен, зная содержимое одного файла можно расшифровать как минимум часть содержимого любого другого зашифрованного с тем же IV. Но при этом сам по себе IV все равно не секретен, и его так же можно хранить вместе с шифрованными данными.
Соль хранится вместе с хешем, например в
$5$MnfsQ4iN$ZMTppKN16y/tIsUYs/obHlhdP.Os80yXhTurpBMUbA5
MnfsQ4iN это соль, и при бруте она известна.
От радужных таблиц она защищает именно потому что с разной солью получаются разные хеши одного и того же пароля, нельзя их заранее просчитать и нельзя брутить всю базу паролей одновременно, каждый пароль надо брутить поотдельности.
У IV ровно такое же назначение, получать разные шифротексты при отдинаковых входных данных. IV не должен быть секретным, он должен быть уникальным.
accountnujen, IV как раз и нужен для того чтобы каждый раз получался разный результат и нельзя было между собой сравнить два шифрованных блока, аналогично соли в хеше. Поэтому сам по себе IV не секретен и хранят его так же как и соль, с результатом.
accountnujen, зачем его делать одинаковым? IV делают рандомным, просто хранят его вместе с результатом шифрования. Даже если вы дважды шифруете одни и те же данные - получите два разных результата с разными IV.
Пример не валиден, т.к. порядок команд имеет значение, proxy должна идти в конце, после задания ACL и редиректа.
Помимо этого, так стоит делать только в том случае, если порт 20001 будет прописан как HTTP прокси в клиенте. Если надо просто отобразить порт на порт, то достаточно команды
sendmail в данном случае просто название бинарника, чтобы из командной строки почту отправлять, а в качестве MTA стоит exim. Соответственно настраивать надо exim, а не sendmail.
Ставить sendmail не надо, это пережиток прошлого, сейчас обычно используются exim или postfix.
Многие получатели пессимизируют письма с доменов без MX-записей или полностью их блокируют, например в postfix есть такое правило, поэтому MX лучше делать всегда, даже если он совпадает с A-записью.
bit8, при такой конфигурации сертификат и STARTTLS будут, просто в случае если не получилось проверить сертификат или установить STARTTLS все будет работать даже с невалидным сертификатом или без STARTTLS.
>Отключение TLS это все письма будут без шифрование, а этого я не могу сделать, что бы у людей письма были открытые.
TLS с использованием публичных CA между серверами это криптографический цирк, потому что процесс получения сертификата для сервера сам по себе уязвим к MitM. Если я MitMлю трафик к вашему серверу, я получу для него сертикат Let's encrypt примерно за пол-секунды, после чего буду успешно MitMить TLS трафик. А поскольку вы не следите за CT-логами, вы этого даже и не заметите. Эту проблему решает DANE, но проникновение DANE на текущий момент нулевое, потому что для него нужен DNSSEC. А DNSSEC пока не хочет никто, кто хочет много девяток в SLA. У MTA-STS проникновение чуть больше, потому что не требуется DNSSEC, но конкретно от этой проблемы он в целом не спасает.
Добро пожаловать в реальный мир, где "быстро установить свой почтовый сервер одной кнопкой" не работает.
mailcow использует postfix, управлять конфигурацией postfix в mailcow можно через https://docs.mailcow.email/manual-guides/Postfix/u...
В postfix нужные вам параметры это
smtp_enforce_tls no
smtp_tls_security_level (may или dane в зависимости от поддержки dane)
по остальным smtp_tls_* можете пройтись
