Язык - это в первую очередь инструмент решения конкретной задачи, а потом уже все остальное
Ну не нужен вам Go, если вы занимаетесь мат. вычислениями - возьмите Python 3 или R, на худой конец C++. Горутины, как и любые fiber'ы, особого прироста на тяжелых вычислениях дать не могут по определению
А когда речь пойдёт про нагрузку на асинхронный io (т.е. буквально весь веб и сетевые службы вокруг него), то Go подойдёт как нельзя лучше
К сожалению, почтовые протоколы имеют свои проблемы, в том числе и с безопасностью
Например, многие приложения грешат тем, что при малейших проблемах при аутентификации просят пользователя заново ввести логин и пароль. Поэтому защиты от перебора там плохо применимы
При условии, что пароль приложения увидеть можно только при создании, удовольствия в этом мало. Вот и приходится искать компромис: нужно выдать пароль, который в ближайшие пару лет не сбрутят при условии, что из защиты там в лучшем случае TLS шифрование, если клиент более менее свежий. Если старый, то все может и в открытом виде летать
В целом, вся идея пароля приложения в том, что доступ, который он предоставляет, ограничен конкретным протоколом
Что страшнее: потерять пароль с доступом на чтение писем или почтовый ящик привязанный к госуслугам, например? При этом, пароли приложений обычно еще и отзываются одним кликом
В результате, перебор паролей на почтовых протоколах стал практически никому не интересен, потому что: пароль не факт, что существует, а если существует, то брутить его долго, а если даже и сбрутил, то ничего особо там не сделаешь
Язык - это в первую очередь инструмент решения конкретной задачи, а потом уже все остальное
Ну не нужен вам Go, если вы занимаетесь мат. вычислениями - возьмите Python 3 или R, на худой конец C++. Горутины, как и любые fiber'ы, особого прироста на тяжелых вычислениях дать не могут по определению
А когда речь пойдёт про нагрузку на асинхронный io (т.е. буквально весь веб и сетевые службы вокруг него), то Go подойдёт как нельзя лучше
Про привязку телефона в этом контексте не в курсе, к сожалению - возможно и есть какой-то смысл
Про время перебора я видел разве что вот этот перевод неплохой статьи - https://habr.com/ru/articles/812237/.
Тут нужна оговорка, что это оценка худшего сценария, когда злоумышленник сумели выгрузить себе базу с хешами и перебирает все локально, на своей ЭВМ
Ну и вторая оговорка, что это абстрактная оценка в среднем на пароль с одним rtx 4090 - на 5090 время будет ниже, а ещё можно поставить их параллельно
К сожалению, почтовые протоколы имеют свои проблемы, в том числе и с безопасностью
Например, многие приложения грешат тем, что при малейших проблемах при аутентификации просят пользователя заново ввести логин и пароль. Поэтому защиты от перебора там плохо применимы
При условии, что пароль приложения увидеть можно только при создании, удовольствия в этом мало. Вот и приходится искать компромис: нужно выдать пароль, который в ближайшие пару лет не сбрутят при условии, что из защиты там в лучшем случае TLS шифрование, если клиент более менее свежий. Если старый, то все может и в открытом виде летать
В целом, вся идея пароля приложения в том, что доступ, который он предоставляет, ограничен конкретным протоколом
Что страшнее: потерять пароль с доступом на чтение писем или почтовый ящик привязанный к госуслугам, например? При этом, пароли приложений обычно еще и отзываются одним кликом
В результате, перебор паролей на почтовых протоколах стал практически никому не интересен, потому что: пароль не факт, что существует, а если существует, то брутить его долго, а если даже и сбрутил, то ничего особо там не сделаешь
Так эти пароли и не создавались для web интерфейсов, они ж не просто так называются "пароли приложений"