Интересно, почему не какой-нибудь gist github, вместо форумов или типа того, что ближе к компании? Трафик будет выглядеть очень даже легальным, даже при размещении голых скриптов 🤪
Можно даже публичную репу с легальным форком чего-то здорового разместить и прятать нужное в тридесятом бранче
Или расчёт именно на кейс "хватит смотреть порнуху"?
Если content security policy закрыл возможность внедрения скриптов (по хешам, нонсам или доменам), то.. Как говорится – с паршивой овцы хоть шерсти клок!
Всякие стили на целые совершения *ab не так интересны, кмк тут проще на каждый допустимый символ сделать стиль и дальше про таймлайну вызова судить о порядке ввода; бажить, конечно, будет, но это сильно лучше 🤪
Если говорить в терминах MSSQL (исхожу из данных по ссылке), то мой комментарий про режим Always Encrypted:
Always Encrypted-enabled driver installed on the client computer achieves this by automatically encrypting and decrypting sensitive data in the client application.
The driver encrypts the data in sensitive columns before passing the data to the Database Engine, and automatically rewrites queries so that the semantics to the application are preserved.
У разных бд свои решения, может некоторые и не поддерживают такое из коробки (redis/memcache?), может какие-то хорошо работают on premise или on cloud
Или поддерживают, но за счёт явного вызова функций [де]шифрования в самих запросах, с засвечиванием ключей (pgcrypto?) в различных логах
Также, когда по одному пользователю из миллионов все гигабайты данных необходимо мгновенно "превратить в мусор", потому что "удалите мои данные по GDPR" – проще удалить персональный ключ дешифровки данных этого пользователя, что уничтожит данные даже в годовых бэкапах без затрагивания этих самых бэкапов, которые таже могут оказаться в утечках
Статическое маскирование данных – это подход, который позволяет при создании копии базы данных
...
Это означает, что вы можете передать такую копию базы данных даже разработчикам на аутсорсинге, не опасаясь утечек ценных данных.
Имхо копировать прод бд для тестового контура, тем более, чтобы передать аутсорс разработке это не гуд, принципиально неверный подход
Среди тысяч бд и таблиц всегда найдется то, что не замаскируется
А если данные полей в бд не были шифрованы на уровне приложения (с хранением ключей отдельно) до передачи в базу – вы всё равно подвержены риску утечки данных (sql-inj, rce, непропатченные сервера, etc...)
А ещё гугл, который более того – именно навязывает использование без паролей
Глянуть поддерживающих можно тут https://passkeys.directory/ и в каком режиме
Но хочу заметить, что WebAuthN (FIDO2/Passkey) это же не только про юбикей, хранилищем приватного ключа может быть телефон, ваш ноутбук, менеджер паролей или ваш облачный профиль, а юбикей в обычном режиме – это лишь второй фактор, его для авторизации можно использовать только, если ресурс явно требует доп. авторизации на устройстве (в данном кейсе – пинкод или отпечаток)
Больше деталей, например тут https://webauthn.io/?regUserVerification=required&attestation=none&attachment=all&algES256=true&algRS256=true&discoverableCredential=preferred®Hints=
Там будет сильно больше инфы, узнаешь про костыли в именовании кукисов, что какая-то настройка не работает в первые 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 фишинговых ресурсов таким образом у себя обнаружил и почти все своевременно заабьюзил
Так что наличие нескольких хонейспотов внутри предприятия тоже хорошее дело – он отработает и атакующий потратит своё время, которого может оказаться достаточно, для автоматического или ручного реагирования
Интересно, почему не какой-нибудь gist github, вместо форумов или типа того, что ближе к компании? Трафик будет выглядеть очень даже легальным, даже при размещении голых скриптов 🤪
Можно даже публичную репу с легальным форком чего-то здорового разместить и прятать нужное в тридесятом бранче
Или расчёт именно на кейс "хватит смотреть порнуху"?
Если content security policy закрыл возможность внедрения скриптов (по хешам, нонсам или доменам), то.. Как говорится – с паршивой овцы хоть шерсти клок!
Всякие стили на целые совершения
*abне так интересны, кмк тут проще на каждый допустимый символ сделать стиль и дальше про таймлайну вызова судить о порядке ввода; бажить, конечно, будет, но это сильно лучше 🤪Можно было и это почитать
Если говорить в терминах MSSQL (исхожу из данных по ссылке), то мой комментарий про режим Always Encrypted:
У разных бд свои решения, может некоторые и не поддерживают такое из коробки (redis/memcache?), может какие-то хорошо работают on premise или on cloud
Или поддерживают, но за счёт явного вызова функций [де]шифрования в самих запросах, с засвечиванием ключей (pgcrypto?) в различных логах
Также, когда по одному пользователю из миллионов все гигабайты данных необходимо мгновенно "превратить в мусор", потому что "удалите мои данные по GDPR" – проще удалить персональный ключ дешифровки данных этого пользователя, что уничтожит данные даже в годовых бэкапах без затрагивания этих самых бэкапов, которые таже могут оказаться в утечках
Имхо копировать прод бд для тестового контура, тем более, чтобы передать аутсорс разработке это не гуд, принципиально неверный подход
Среди тысяч бд и таблиц всегда найдется то, что не замаскируется
А если данные полей в бд не были шифрованы на уровне приложения (с хранением ключей отдельно) до передачи в базу – вы всё равно подвержены риску утечки данных (sql-inj, rce, непропатченные сервера, etc...)
А ещё гугл, который более того – именно навязывает использование без паролей
Глянуть поддерживающих можно тут https://passkeys.directory/ и в каком режиме
Но хочу заметить, что WebAuthN (FIDO2/Passkey) это же не только про юбикей, хранилищем приватного ключа может быть телефон, ваш ноутбук, менеджер паролей или ваш облачный профиль, а юбикей в обычном режиме – это лишь второй фактор, его для авторизации можно использовать только, если ресурс явно требует доп. авторизации на устройстве (в данном кейсе – пинкод или отпечаток)
Больше деталей, например тут https://webauthn.io/?regUserVerification=required&attestation=none&attachment=all&algES256=true&algRS256=true&discoverableCredential=preferred®Hints=
В последние годы часто наблюдаем кучу утечек, включающих пароли
Какова вероятность, что секрет для 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 фишинговых ресурсов таким образом у себя обнаружил и почти все своевременно заабьюзил
Так что наличие нескольких хонейспотов внутри предприятия тоже хорошее дело – он отработает и атакующий потратит своё время, которого может оказаться достаточно, для автоматического или ручного реагирования