Там будет сильно больше инфы, узнаешь про костыли в именовании кукисов, что какая-то настройка не работает в первые 2 минуты, если явно это не отключить, что тот же CSP репортит только, если настроен через заголовок, а не мета-тег и много такого разного
В случае отсутствия биометрии, вам нужно будет воспользоваться паролем (но локальным); И проблема выбора пароля всё равно присутствует, хотя уже не так остро
В некоторых кейсах биометрия будет лишь доп опцией (в маках, телефонах, менеджерах паролей в том числе), которая анлочится на некоторое время после ввода того самого пароля
Но да, суть посыла понятна – утечки паролей на сторонних ресурсах будут и они опаснее утечки публичных куличей ?
Тогда ещё нужно в середине пароля добавлять точку с запятой, кавычки, табуляцию, пробел и �, чтобы csv подпортить ?
злоумышленнику невыгодно брать на себя такую нагрузку для 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 разработчиками как-либо шифруется?
Имхо в топку, что пароли, что OTP , ибо оба они страдают при утечках или фишинге
Необходима реализация WebAuthN, а не вот это вот всё
Всё же 24-й год уже
Ну в такую подборку можно и хипстерский age добавить https://github.com/FiloSottile/age
Если кто вдруг набрёл на эту статейку, то лучше глянь сюда https://portswigger.net/web-security/all-topics#client-side-topics
Там будет сильно больше инфы, узнаешь про костыли в именовании кукисов, что какая-то настройка не работает в первые 2 минуты, если явно это не отключить, что тот же CSP репортит только, если настроен через заголовок, а не мета-тег и много такого разного
И главное - всё распробуешь там же на месте
В случае отсутствия биометрии, вам нужно будет воспользоваться паролем (но локальным); И проблема выбора пароля всё равно присутствует, хотя уже не так остро
В некоторых кейсах биометрия будет лишь доп опцией (в маках, телефонах, менеджерах паролей в том числе), которая анлочится на некоторое время после ввода того самого пароля
Но да, суть посыла понятна – утечки паролей на сторонних ресурсах будут и они опаснее утечки публичных куличей ?
Тогда ещё нужно в середине пароля добавлять точку с запятой, кавычки, табуляцию, пробел и �, чтобы csv подпортить ?
Есть что добавить спустя год?
Я про ситуацию, когда капча не 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скрин, чтоб не кликать