злоумышленнику невыгодно брать на себя такую нагрузку для DDoS-атаки.
для DDoS этого и не требуется
Капча защищает эндпоинты от различных атак методом перебора, а не от кучки машин, цель которых довести сервис до отказа в обслуживании А это можно сделать и без прохождения капч, разве что ваш WAF не отвечает за её решение
Так что даже простецкий скрипт гугл рекапчи в3, который ничего пользователю последние лет 5 не показывает, ощутимо сократит количество потенциальных желающих побрутфорсить ваши апишки
Ещё немного про DDoS: а как ваш сервис себя поведёт, если на него упадёт 100_000 неверно решённых капч ща минуту?
В тех же битварден и 1пасс тоже не восстановить (в персональной редакции), ибо пасс юзается как часть ключа для шифрования, так что его тоже не следует терять (и секрет с сервера тоже, который придумываете не вы)
Некоторые сегодня вообще делают сие как замену паролю и второму фактуру, а если хотите по SCA по категориям оценить, то пасскей девайс = фактор владения, а пароль к нему = знание (или face id/touch id = биометрия)
А код из СМС это не фактор знания, только владение, ибо подтверждает лишь наличие у вас девайса, который СМС принимает. Знание оно чуть более константное (как пароль)
Так что эти СМС коды должны кануть в Лету, как страшный сон, а компании, которые через год или два СМС всё ещё будут навязывать – динозавры, клиентами коих быть нельзя
Емнип в GC Server по куче на каждое ядро (что является ныне дефолтом) и "освобождение" кучи (или переезд) не есть освобождение памяти выделенной ОС процессу. Быстро проверить – включить в конфиге GC Workstation
VMMap для быстро проверить, что же там с памятью https://learn.microsoft.com/en-us/sysinternals/downloads/vmmap
Testlimit – создать дефицит памяти в ОС и глянуть, как себя поведет процесс (возвращает память = у вас нет проблемы) https://learn.microsoft.com/en-us/sysinternals/downloads/testlimit
+Просто вызвать gc.collect недостаточно, там 4 аргумента, + в гц сеттингс отдельно для loh и коллекта был параметр + эвейтифинализаторов и повторный вызов //сорян, без кода, я с телефона
Про тему с mitm не понял, это же нужно в реальном времени отлавливать тогда, но и тут можно подсмотреть реализацию у других, например протон https://account.proton.me/login
Давайте подумаем, чем эта утечка опасна, вероятно:
Даже если нет, то можно положиться на этот ресёрч https://passwordpolicies.cs.princeton.edu/ и добавить единичку в конце, восклицательный знак или первую букву пароля сделать большой для стандартного словаря
Ещё проще - проверить, в каких утечках почта/телефон уже засветились https://haveibeenpwned.com/, поможет понять алгоритм хеширования (или подобрать соль, или вовсе заюзать пасс as is)
Вероятности не самые большие, но количество строк нормальное такое )
Забавно, что год уже 2023, а люди хранят почты/телефоны в БД без шифрования на стороне приложения! Передайте парням из Альфа-страхования, что как бы сегодня это уже моветон
6 символов это неплохо, всего лям вариантов у многих будет)
Да и ограничивать пароль длиной в 21 символ - это почему? У вас функция хеширования больше не переваривает или её результат зависит от длины пасса?
Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length.
Надежды мало, но может пунктик у них хоть как-то реализован "Best practices from prior research: Do check users' passwords against lists of leaked and easily-guessed passwords" И при следующем входе будет запрошен усиленный сброс пароля
Регу опробовал, забавно - нет рейт-лимитов на вводе смс-кода при подтверждении, а при самой реге хотяб рекапча на месте
Например даже при клонировании сайта (с целью поднятия своего фишингового) не особо заморачиваются и лишь заменяют https://domain.com на что-то своё
А нормальные обфускаченные канарейки остаются на месте + обращения за некоторой статикой на оригинальный сайт тоже (которые вылавливаются по referer хедерам из логов веб сервера)
Говорю по опыту, в этому году 49 фишинговых ресурсов таким образом у себя обнаружил и почти все своевременно заабьюзил
Так что наличие нескольких хонейспотов внутри предприятия тоже хорошее дело – он отработает и атакующий потратит своё время, которого может оказаться достаточно, для автоматического или ручного реагирования
Если поставить пинкод на сим-карту, то, вероятно, это хоть как-то защитит от чтения СМС в случае кражи/утери телефона (при условии, что симку пришлось вынимать, а заблокированный телефон не показывает содержимое уведомлений)
Вижу три категории идентификации:
Знание – пароли, пины, секретные вопросы и т.п. заметим, что логин не является секретным знанием, т.к. он ± известен всем (телефон/почта)
Владение – телефон в руках, на который приходят СМС, пуши, юбикей, OTP, или иное взаимодействие (спейренное ранее приложение, при первом входе, с приятным ключом ecdsa, например)
Биометрия – отпечаток пальца, тот же фейс ид..., но для авторизации действий нужно дополнительно использовать что-то из предыдущих категорий
Суть – одной категорией для аутентификации/авторизации действий пользователя лучше никогда не обходиться. Это понятно, но банкам просто нереально навязать своим пользователям пинкоды на симки, блокировку экрана и скрытие контента уведомлений на экране. А если это как-то навязчиво требовать, то, скорее, будет отток клиентов, имхо.
Про пинкоды на симки – это вообще не панацея. Когда-то давно я баловался с этим и залочил симку. Для восстановления необходимо ввести PUK код, его я в нуль не знаю. Двинул на сайт оператора, там спросили ФИО и номер паспорта, а в ответ дали PUK-код. Судя по количеству утечек, в сети – пароль к банку из головы будет получше, чем пинкод к симке, которую можно потерять
Однажды менял оператора и когда окончательно переехал, то мне банк сам проактивно позвонил и попросил перезвонить, для восстановления доступа
Ещё знаю, как в одном банке сделана проверка подмены сим-карты: перед отправкой СМС у шлюза рассылки запрашивается текущий IMSI по номеру, и если он отличается от шаблонного в БД, то никакая СМС не отправляется (и производятся дополнительные тревоги)
Боюсь банков, что ведут себя иначе
Жаль не встречал у нас банков с поддержкой юбикеев, но это и понятно – большинству клиентов оно нафиг не нужно. Многие даже не будут OTP генераторы использовать (и бекапить)
Просто для инфы: не так давно вышел YubiKey Bio Series с поддержкой распознавания отпечатков пальцев, см. https://www.yubico.com/cy/store/#yubikey-bio-series-fido-edition
Я про ситуацию, когда капча не end-to-end, а с независимой третьей стороной (так типа правильно)
Возьмём для примера самые популярные:
гугл https://developers.google.com/recaptcha/docs/verify
cloudflare https://developers.cloudflare.com/turnstile/get-started/server-side-validation/
для DDoS этого и не требуется
Капча защищает эндпоинты от различных атак методом перебора, а не от кучки машин, цель которых довести сервис до отказа в обслуживании
А это можно сделать и без прохождения капч, разве что ваш WAF не отвечает за её решение
Так что даже простецкий скрипт гугл рекапчи в3, который ничего пользователю последние лет 5 не показывает, ощутимо сократит количество потенциальных желающих побрутфорсить ваши апишки
Ещё немного про DDoS: а как ваш сервис себя поведёт, если на него упадёт 100_000 неверно решённых капч ща минуту?
В тех же битварден и 1пасс тоже не восстановить (в персональной редакции), ибо пасс юзается как часть ключа для шифрования, так что его тоже не следует терять (и секрет с сервера тоже, который придумываете не вы)
поправьте, если ошибаюсь:
в битвардене с виду также https://bitwarden.com/help/forgot-master-password/
было бы странно иначе
потому что у платных решений – хорошая платная маркетинговая кампания, их имена на слуху/в топе поисковой выдачи
Вероятно авторы статей плотненько с подобным и не поработали
Ага, конечно...
Минусы СМС:
Должна быть сеть оператора (привет роуминг)
Захват симки или перехват СМС
Фишинговые сайты отлично нарисуют форму для ввода кода из СМС
Поди ещё дождись эту СМС
Что нужно:
Что-то, что работает в оффлайне
Основано на криптографии с открытым/закрытым ключом
И работает со множества устройств (т.е. факт потери одной симки не должен равняться потере доступа)
Не поддаётся фишинговой атаке
И работает так быстро, как быстро я могу приложить палец к телефону или компьютеру
Вот для этого и сделали FIDO2 WebAuthN, читайте тут https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
Демо и код ищите тут https://webauthn.io/ или https://fido2-net-lib.passwordless.dev/passwordless#heroFoot
Некоторые сегодня вообще делают сие как замену паролю и второму фактуру, а если хотите по SCA по категориям оценить, то пасскей девайс = фактор владения, а пароль к нему = знание (или face id/touch id = биометрия)
А код из СМС это не фактор знания, только владение, ибо подтверждает лишь наличие у вас девайса, который СМС принимает. Знание оно чуть более константное (как пароль)
Так что эти СМС коды должны кануть в Лету, как страшный сон, а компании, которые через год или два СМС всё ещё будут навязывать – динозавры, клиентами коих быть нельзя
В dotnet есть два вида garbage collector
Может и больше, ибо ранее заявляли, что будет и пользовательская поддержка
Про ядра – буквально по куче на ядро, не больше, не меньше, но для гц сервер
Емнип в GC Server по куче на каждое ядро (что является ныне дефолтом) и "освобождение" кучи (или переезд) не есть освобождение памяти выделенной ОС процессу. Быстро проверить – включить в конфиге GC Workstation
VMMap для быстро проверить, что же там с памятью https://learn.microsoft.com/en-us/sysinternals/downloads/vmmap
Testlimit – создать дефицит памяти в ОС и глянуть, как себя поведет процесс (возвращает память = у вас нет проблемы) https://learn.microsoft.com/en-us/sysinternals/downloads/testlimit
+Просто вызвать gc.collect недостаточно, там 4 аргумента, + в гц сеттингс отдельно для loh и коллекта был параметр + эвейтифинализаторов и повторный вызов //сорян, без кода, я с телефона
простите, но я вас немного не понял
Тоже почитал тредик выше, и малость вау! ))
Для тех, кто хочет почитать про нормальные хеширования - https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
Про подбор паролей для хеша https://hashcat.net/hashcat/
Про тему с mitm не понял, это же нужно в реальном времени отлавливать тогда, но и тут можно подсмотреть реализацию у других, например протон https://account.proton.me/login
Давайте подумаем, чем эта утечка опасна, вероятно:
Есть те, у которых пароли находятся в публичных словарях и самой почты/телефона достаточно, чтобы попасть в их лк https://github.com/danielmiessler/SecLists/tree/master/Passwords
Есть те, которые используют один пароль дважды (и более раз) - https://owasp.org/www-community/attacks/Credential_stuffing, соответственно через эту утечку можно подобрать пароль к другим ресурсам
Даже если нет, то можно положиться на этот ресёрч https://passwordpolicies.cs.princeton.edu/ и добавить единичку в конце, восклицательный знак или первую букву пароля сделать большой для стандартного словаря
Ещё проще - проверить, в каких утечках почта/телефон уже засветились https://haveibeenpwned.com/, поможет понять алгоритм хеширования (или подобрать соль, или вовсе заюзать пасс as is)
Вероятности не самые большие, но количество строк нормальное такое )
Забавно, что год уже 2023, а люди хранят почты/телефоны в БД без шифрования на стороне приложения!
Передайте парням из Альфа-страхования, что как бы сегодня это уже моветон
Да и ограничивать пароль длиной в 21 символ - это почему?
У вас функция хеширования больше не переваривает или её результат зависит от длины пасса?
Давайте глянем, что рекомендует NIST https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers:
Надежды мало, но может пунктик у них хоть как-то реализован "Best practices from prior research: Do check users' passwords against lists of leaked and easily-guessed passwords"
И при следующем входе будет запрошен усиленный сброс пароля
Регу опробовал, забавно - нет рейт-лимитов на вводе смс-кода при подтверждении, а при самой реге хотяб рекапча на месте
Как минимум менять пароль )
Хороший да, но как правило народ ленив
Например даже при клонировании сайта (с целью поднятия своего фишингового) не особо заморачиваются и лишь заменяют https://domain.com на что-то своё
А нормальные обфускаченные канарейки остаются на месте
+ обращения за некоторой статикой на оригинальный сайт тоже (которые вылавливаются по referer хедерам из логов веб сервера)
Говорю по опыту, в этому году 49 фишинговых ресурсов таким образом у себя обнаружил и почти все своевременно заабьюзил
Так что наличие нескольких хонейспотов внутри предприятия тоже хорошее дело – он отработает и атакующий потратит своё время, которого может оказаться достаточно, для автоматического или ручного реагирования
аналогично, просто прислали скидочный купон на почту
купить можно до 10 ключей и только yubikey 5* nfc
т.е. например YubiKey Bio Series (те, что с отпечатком пальца) или YubiKey For individuals идут без скидки
Есть что добавить спустя год?
Может он считает, что программировал на языках, где год за три идёт
Просто на заметку оставлю тут инфу о переменных среды
DOTNET_GCHeapHardLimit&COMPlus_GCHeapHardLimithttps://docs.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector#heap-limitскрин, чтоб не кликать
Почти уверен, что сканер есть в +- любой дефолтной камере
Но это неочевидно для рядового пользователя (который не юзает FF тем более)
А почему именно sed?
Варианты: kubectl kustomize или envsubst
Если поставить пинкод на сим-карту, то, вероятно, это хоть как-то защитит от чтения СМС в случае кражи/утери телефона (при условии, что симку пришлось вынимать, а заблокированный телефон не показывает содержимое уведомлений)
Вижу три категории идентификации:
Знание – пароли, пины, секретные вопросы и т.п. заметим, что логин не является секретным знанием, т.к. он ± известен всем (телефон/почта)
Владение – телефон в руках, на который приходят СМС, пуши, юбикей, OTP, или иное взаимодействие (спейренное ранее приложение, при первом входе, с приятным ключом ecdsa, например)
Биометрия – отпечаток пальца, тот же фейс ид..., но для авторизации действий нужно дополнительно использовать что-то из предыдущих категорий
Суть – одной категорией для аутентификации/авторизации действий пользователя лучше никогда не обходиться. Это понятно, но банкам просто нереально навязать своим пользователям пинкоды на симки, блокировку экрана и скрытие контента уведомлений на экране. А если это как-то навязчиво требовать, то, скорее, будет отток клиентов, имхо.
Про пинкоды на симки – это вообще не панацея. Когда-то давно я баловался с этим и залочил симку. Для восстановления необходимо ввести PUK код, его я в нуль не знаю. Двинул на сайт оператора, там спросили ФИО и номер паспорта, а в ответ дали PUK-код. Судя по количеству утечек, в сети – пароль к банку из головы будет получше, чем пинкод к симке, которую можно потерять
PS: простите, просто мимо проходил)
Однажды менял оператора и когда окончательно переехал, то мне банк сам проактивно позвонил и попросил перезвонить, для восстановления доступа
Ещё знаю, как в одном банке сделана проверка подмены сим-карты: перед отправкой СМС у шлюза рассылки запрашивается текущий IMSI по номеру, и если он отличается от шаблонного в БД, то никакая СМС не отправляется (и производятся дополнительные тревоги)
Боюсь банков, что ведут себя иначе
Жаль не встречал у нас банков с поддержкой юбикеев, но это и понятно – большинству клиентов оно нафиг не нужно. Многие даже не будут OTP генераторы использовать (и бекапить)
Просто для инфы: не так давно вышел YubiKey Bio Series с поддержкой распознавания отпечатков пальцев, см. https://www.yubico.com/cy/store/#yubikey-bio-series-fido-edition