Про недоумение: видимо кто-то не пробовал пасскеи, ни в виде телефона, ни в виде usb токена+pin, ни то, что предоставляется виндой, макосью или менеджерами паролей
Хотя удивительно — уже на каждом шагу они навязываются (гитхаб/гитлаб/эпол/гугл/мс и много где ещё)
Сегодня у подавляющего большинства есть сканер биометрии, есть даже менеджер паролей, который стремится избавить всех пользователей от паролей добавив биометрию, см. демо https://youtu.be/RQHmljGydr0?si=NyDfMnRCtiXnjpfy
Если вы за облака и не хотите вводить пароль, но за привязку к железу, то вам нужен ноут с TPM и там хоть по отпечатку пальца разблокируйте ключ доступа к мастер паролю для расшифровки (простите за грубые неточности)
Важный поинт – современные "облачные" менеджеры паролей уже это делают (1пасс, битварден), при том в случае утери – вы же знаете свой мастер пароль? Который всё же сложный, но для вас лично легко запоминаемый
защитить секретные данные — логин и пароль аккаунта в соцсети.
Лучше лечить причину – дайте ему в качестве второго фактора юбикей и толку от слива почти нет (или оставьте второй фактор у себя)
Разве что чел пошерил полностью профиль браузера со всеми куками, это же по NDA не запрещено у вас?
А если соцсеть не использует кукисы, а local storage или типа того? (Например github)
Почтой аккаунта тоже только он владеет или это мейлгруппа, или алиас от имей-рилея? На случай странных изменений в аккаунте и удаления с почтового сервера записей об этом – чтобы был бэкап
Менеджеры паролей используете? Бывает пароли очень простые люди ставят (простое слово, первая буква большая, в конце единичка и восклицательный знак). Менеджеры паролей вам по 100 символов могут генерировать, да так, что в утечках лишь часть засветится
Если не в менеджере паролей, то где храните? Текстовый файл или браузер? И как в таком случае доказать, что не инфостилер их спёр? Надеюсь хотяб антивирусом пользуетесь и только официальным ПО (не крякнутым, кряки с торрентов = вы уже часть ботнета)
А будет ли нарушением NDA, если сотрудник стал жертвой фишинговой атаки? Вы ведь проводите такие учения и обучения? Также имеете MDR/EDR решения, чтобы доказать невиновность сотрудника?
P.S.: сегодня в современном мире мы не знаем не то, что пароли, но и логины, и вторые факторы ;)
Интересно, почему не какой-нибудь 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 подпортить ?
В заголовке From можно писать что угодно при отправке письма, хоть admin@binance.go
Как на бумажном конверте — в разделе от кого вам ничто не мешает написать Марс
Потому есть SPF, DMARK, DKIM, но их проверки и реакции на фейлы полностью на стороне клиента, в данном кейсе – Gmail
Предположу, что в некоторых не веб клиентах, типа fairemail, такие фейлы в глаза бросаются сразу
Про недоумение: видимо кто-то не пробовал пасскеи, ни в виде телефона, ни в виде usb токена+pin, ни то, что предоставляется виндой, макосью или менеджерами паролей
Хотя удивительно — уже на каждом шагу они навязываются (гитхаб/гитлаб/эпол/гугл/мс и много где ещё)
Тогда второй фактор ещё нужно по любому сильно отделять от места хранения паролей, например юзать альтернативу – https://2fas.com/
А для параноиков – https://support.yubico.com/hc/en-us/articles/360013789259-Using-Your-YubiKey-with-Authenticator-Codes , пробовал – неудобно очень 🤪
Хранить пароли можно и так https://www.qwertycards.com/ , только всплывает проблема смены пароля 🙃
Сегодня у подавляющего большинства есть сканер биометрии, есть даже менеджер паролей, который стремится избавить всех пользователей от паролей добавив биометрию, см. демо https://youtu.be/RQHmljGydr0?si=NyDfMnRCtiXnjpfy
Поддерживаю предыдущего оратора
После того, как я попался менеджерам паролей и email relay (+pgp) – я честно даже логины не знаю, их более трёхста уже
Предпочту помнить что-то более важное, чем кучку кредов
Если вы за облака и не хотите вводить пароль, но за привязку к железу, то вам нужен ноут с TPM и там хоть по отпечатку пальца разблокируйте ключ доступа к мастер паролю для расшифровки (простите за грубые неточности)
Важный поинт – современные "облачные" менеджеры паролей уже это делают (1пасс, битварден), при том в случае утери – вы же знаете свой мастер пароль? Который всё же сложный, но для вас лично легко запоминаемый
Хоть тут и про приложения, но суть та же – почитайте намедни https://passwordpolicies.cs.princeton.edu/
Регулярная смена паролей для пользователей тот ещё адок, приводящий к бумажкам или шаблонному упрощению:
Требуется большая буква? Будет первая
Спецсимвол? Конечно восклицательный знак
Цифра? Только единичка в конце
Лучше глянуть что рекомендуют NIST, что есть MFA (не 2фа) & Strong Customer Authentication
И уже стоит смотреть в сторону ауса без паролей, всё же они прошлый век 😜
Ах да – пинкод в систему = чей-то др?
Это я к чему:
Культура и защита это не то, что можно описать на бумаге и оно заработает, — их нужно выстраивать (как процесс)
Лучше лечить причину – дайте ему в качестве второго фактора юбикей и толку от слива почти нет (или оставьте второй фактор у себя)
Разве что чел пошерил полностью профиль браузера со всеми куками, это же по NDA не запрещено у вас?
А если соцсеть не использует кукисы, а local storage или типа того? (Например github)
Почтой аккаунта тоже только он владеет или это мейлгруппа, или алиас от имей-рилея? На случай странных изменений в аккаунте и удаления с почтового сервера записей об этом – чтобы был бэкап
Менеджеры паролей используете? Бывает пароли очень простые люди ставят (простое слово, первая буква большая, в конце единичка и восклицательный знак). Менеджеры паролей вам по 100 символов могут генерировать, да так, что в утечках лишь часть засветится
Если не в менеджере паролей, то где храните? Текстовый файл или браузер? И как в таком случае доказать, что не инфостилер их спёр? Надеюсь хотяб антивирусом пользуетесь и только официальным ПО (не крякнутым, кряки с торрентов = вы уже часть ботнета)
А будет ли нарушением NDA, если сотрудник стал жертвой фишинговой атаки? Вы ведь проводите такие учения и обучения? Также имеете MDR/EDR решения, чтобы доказать невиновность сотрудника?
P.S.: сегодня в современном мире мы не знаем не то, что пароли, но и логины, и вторые факторы ;)
Видимо уже нет https://www.opennet.ru/opennews/art.shtml?num=61292
Интересно, почему не какой-нибудь 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 подпортить ?
Есть что добавить спустя год?