Nikita

софт для инвайтинга

это софт для спама, не нужно таким заниматься

Б- бубен словарь ожегова стучать вокруг ноутбука.

По существу: Ловит сигнал - это к уровню сигнала, не ко скорости (хотя и связано иногда)
WiFi 2,4 или 5 Ггц - или вы предлагаете нам по моделям искать характеристики ?
И гадать что за точка доступа ?

Может иметь доступ к трафику.
Если логин и пароль передаются в незашифрованном виде, то их может украсть далеко не только поставщик VPN.

Или, допустим, безопасно ли будет заходить в приложение Сбера по такому ВПН?

Если ты не устанавливал никаких посторонних сертификатов, то безопасно, тк сбер, очевидно, использует https

Ну раз с фронта пересели, то аналогию понять должны: В чëм отличие Google Chrome от JavaScript?

Ну для начала что значит "атака"? Какую угрозу ты ожидаешь? Потому что ответы будут ОЧЕНЬ разные в зависимости от этого.

IP бота можно будет попробовать узнать, если ты знаешь, что бот проходит по ссылкам, которые ты можешь ему отправить. Тогда, скинув боту ссылку на свой сайт, можно будет посмотреть, какие адреса заходили в этот момент.
Если бот такого не делает, то скорее всего никак.

Зафлудить бота запросами? С одного аккаунта не получится, а с многих - недёшево. Кому ты нужен за такие деньги?

Потыкать команды бота на пример SQL-инъекции? Если бот вообще использует БД, достаточно использовать стандартные средства подстановки параметров в запросы, а не колхозить SQL чере зформатирование строк.

Угнать бота? Не пости его токен никуда. Если хранишь исходный код в какой-то системе хранения версий - храни токен в отдельном файле и добавь его в исключения. Если есть подозрение, что токен уже уплыл - меняй его у BotFather. А угон акка разработчика - это другая песня уже.

Короче, ответь хотя бы для себя на вопросы:
1. чего конкретно боишься?
2. кому конкретно ты нужен?

Если у вас такой коммунизм и используется общий комп и даже один профиль пользователя, то что мешает использовать общую учетку на гитхабе? Если репозитории лежат в разных аккаунтах гитхаба, то просто дайте права на запись этому общему пользователю.

Предполагаю, что коммиты вы хотите подписывать реальными именами авторов, поэтому храните настройки подписи не в глобальном конфиге, а в локальном конфиге конкретного локального репозитория. Надеюсь хоть репозитории то у вас разные?

git config --local user.name ...
git config --local user.email ...

Если хочется непременно разные аккаунты на гитхабе, то

Как разлогиниться в гитхабе?

Если отправляете по HTTPS, то придется каждый раз сбрасывать авторизацию после предыдущего пользователя

echo "url=https://github.com" | git credential reject

В случае с протоколом SSH немного сложнее, там не авторизация, а файлы ключей, привязанные к хостам. Нельзя использовать разные ключи при обращении к одному и тому же хосту. Но вы можно в конфиге SSH прописать виртуальные хосты и привязать разные ключи к ним.

Для этого мы создаём в файле конфигурации ~/.ssh/config несколько виртуальных хостов

Host github-alice
        Hostname github.com
        IdentityFile=/home/user/.ssh/alice_key

Host github-bob
        Hostname github.com
        IdentityFile=/home/user/.ssh/bob_key

И поправьте ссылки на origin в своих репозиториях используя псевдоним виртуального хоста

git remote set-url origin git@github-alice:OWNER/alice-repo.git

Есть официальная инструкция

How do I use multiple accounts with the same hosting provider using SSH?

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

Не согласен с Griboks. Программы и игры поддерживают 2к давно. Если говорить сугубо о винде и софте - стоит однозначно, оптимально на 27". Если сидишь далеко от моника, можно 32". Если носом у моника то можно и 25". Дело не только в качестве, которое в плотности пикселей, плотность у 2к на 27" будет близка к 23" 1080. Дело в количестве информации, которая помещается благодаря разрешению. Скажу так - если юзеру сильно важно ФПС (например для соревновательных шутеров), то 3060 будет мало для 2к (ну конечно смотря для какой игры) - я для 2к выбрал 4080, что бы точно хватало (моник 165гц у меня) - играю в основном в последнюю колду и варзон. Если же юзеру в сюжетных играх с длсс хватает 60 кадров, то 2к не помеха для 3060. И про герцы не согласен с Griboks - я отсидев три года на 144 и 165 мониках, теперь сажусь за 60гц - ощущение что комп прям тормозит. Плавность 144/165гц очень много даёт в комфорт использования монитора. Не давно в офисе сев после своего 2к 165гц 27" на 24" 1080/60гц просто офигел, насколько не удобно - комп как будто тормозит, а инфы так мало помещаеться, даже аутлуком не комфортно пользоваться.

Дебиан является таковым?

Является. Базовый дистриб, на основе которого делают многие другие. Мощное коммунити, много документации. Неплохой выбор. На базе дебиана сделана Astra linux, например.
Поначалу рекомендую не лезть bare-metal, а ставить на виртуалку - первые пять раз точно придется сносить :)

Кстати, советчиков-комитетчиков, которые предлагают бубунту - слушать не стоит. Иначе есть риск "изучить линукс" на уровне знания блондинкой автомобиля - она знает, как в него сесть, какк завести и поехать, но малейшая неисправность поставит ее в ... позу :) Бубунта - это такой "линух для блондинок", бубунтовод выявляется сразу, как только просишь сделать что-то через консоль :)

Ищите сборку MSDN. Автор Microsoft.
Наименьшее число багов хотя и встречаются

Структура проекта какая-то странная, в нем, судя по всему, контроллером называется роутер, но на этом я останавливаться не буду, обработка исключений от этого не зависит.

Основных правил при обработке исключений три:
1. Не использовать исключения там, где они не нужны. Например, при проверке пользовательских данных.
Собственно, эмпирическое правило звучит так: функция должна бросать исключение, если она не может выполнить ту работу, для которой она предназначена.

Отсюда сразу становится понятно, что для функции, которая должна проверять введенные данные, наличие ошибок в них не является исключительной ситуацией. А совершенно штатной. И обеспечивается штатными же средствами. По результатам проверки пользователю просто отправляется ответ, что данные неверны, безо всяких исключений. В нормальной структуре проекта этим занимается контроллер.

Ситуации, когда введено меньше букв, или пользователь не найден, или пароль не подходит - не являются исключительными.

2. Системные ошибки обрабатывает глобальный обработчик исключений, логируя саму ошибку, а на клиент отправляя статус 500 и какое-нибудь абстрактное сообщение о проблеме на сервере. Это самое важное в системных исключениях - текст ошибки никогда, не при каких обстоятельствах не уходит наружу.

Пример такого исключения - когда запрос в БД порождает ошибку.

3. Пользовательские исключения, там где они нужны, обычно обрабатываются по месту, но есть нюансы.
Собственно, под обработкой исключений часто понимают два разных действия:
- собственно обработку, когда программа совершает какие-то действия, чтобы нивелировать негативный эффект. Например, если не удалось подключение к какому-то сервису, то либо попробовать подключиться к другому, либо просто подождать и попробовать снова.
- простое информирование пользователя

Для информирования можно действительно ловить исключение через try..catch и писать какое-то свое сообщение.
Но можно и автоматизировать этот процесс, вот две статьи, которые показывают примеры, как это можно сделать:
https://angelovdejan.me/2022/11/24/centralized-exc...
https://habr.com/ru/articles/688202/

Иногда смотришь на вопрос и не понимаешь, о чем он.
Судя по вопросу и цифрам в нем, автор и так уже осведомлен о правильных способах хэширования и должен уже знать ответ на свой вопрос.

Ну если до сих пор не ясно, то цифры здесь приведены для цпу общего назначения, а не для железа, предназначеного для вычисления хэшей. На котором ситуация для мд5 будет совсем плачевная.

Возможно, непонимание происходит оттого, что существует не один, а несколько векторов атаки на пароль.

1. Поиск хэша по "радужным таблицам" (rainbow tables): огромным базам данных, где собираются заранее посчитанные хэши для любых возможных строк.
   
2. Метод грубой силы (bruteforce): перебирать все комбинации символов и применять к ним хэширующую функцию до тех пор, пока она не вернёт искомый хэш.
   
3. Поиск по словарю. Похож на брутфорс, но перебор не всех возможных значений, а всего нескольких тысяч самых популярных паролей, типа "123", "password" и пр.
   

phpfaq.ru/tech/hashing

И только одного элемента недостаточно, а нужны все в комплексе:
- Хэширующая функция должна иметь большую вычислительную сложность, чтобы усложнить подбор перебором. по этой причине md5() не подходит
- Хэш должен быть посолен уникальной солью, чтобы нельзя было, затратив 1 раз кучу вычислительных усилий, заранее построить хэши для любых комбинаций символов. По этой причине фарш без соли - деньги на ветер.
- Пароль не должен быть слишком простым, иначе даже медленный перебор его раскроет. Этот момент тоже надо учитывать