Самый смешно запоротый A/B в моей практике Как-то раз в A/B тесте нашей модельки с альтернативным решением, заказчику (онлайн-магазину) понадобилось рассказать, зачем нужно брать хэши от айдишников пользователей перед делением на группы, потому что заказчик хотел просто брать четные айдишники в одну группу, а нечетные в другую. Рассказали, что не все вещи, кажущиеся равномерным распределением, правда им являются. Рассказали про то как многие смело разбивают клиентов на группы по последней цифре телефона и потом внезапно узнают, что группы перекошенные. И даже рассказали, что не все хэши одинаково хорошо перемешивают группы и какие предлагаем использовать. Дальше первую неделю A/B видим как стабильно ведем в тесте, радуемся, готовимся праздновать, но на очередном созвоне с заказчиком мимолетом ловим очень тревожную фразу. СТО заказчика решил поделиться своим ноу-хау:«хэш же нам нужен, чтобы результат был максимально непредсказуемым, так что я сделал не hash(id), а hash(id+email), чтобы еще лучше перемешивало группы» 🗿 Осторожно интересуюсь: а когда человек не залогинен, как это работает? СТО: тогда e-mail - пустая строка. Я: а сразу после логина? СТО: сразу после видим e-mail и уже не пустая. В общем, при логине с вероятностью 50% группа менялась, а логин был обязателен для оформления покупки… Кстати, времени у заказчика на еще один правильный А/В не было, так что как вы думаете, что было дальше, и чем закончился проект? :)

🔐 Делаем разбор, вчерашней, простенькой задачки Разработчики телеграмма, подсуетились и немного внесли суеты к нам в опрос, но от этого наш опрос стал еще интереснее😂 Правильный ответ: ✅ Хранить пароли в виде хешей. Почему именно так? Представьте, что злоумышленник получил доступ к базе данных пользователей. Если пароли хранятся в открытом виде, он сразу увидит:

ivan123
qwerty
Password123

И сможет использовать их для входа в систему. Если же в базе хранятся хеши, злоумышленник увидит только результат работы алгоритма хеширования, например:

e10adc3949ba59abbe56e057f20f883e

Сам по себе такой хеш не раскрывает исходный пароль. Да, при слабых паролях злоумышленник может попытаться подобрать их с помощью словарей или brute force, но это уже значительно сложнее, чем просто прочитать пароль из базы. 🧠 Поэтому большинство современных приложений не хранят пароли, а хранят их хеши.

🔐 Что такое Hash? Когда начинают изучать инфраструктурный пентест, очень часто слышат: 🤔"получили NTLM-хеш" 🤔 "Pass-the-Hash" 🤔"слили хеши пользователей" Но что вообще такое хеш?

📌 Hash (хеш) — это результат работы специального алгоритма, который преобразует любые данные в строку фиксированной длины.

Например:

Пароль:
qwerty123

После вычисления хеша получится что-то вроде:

7c6a180b36896a0a8c02787eeafb0e4c

🧠 Главное свойство хеша: 👉 из одного и того же пароля всегда получится один и тот же хеш. Но выполнить обратное преобразование:

Хеш → Пароль

невозможно. Поэтому в большинстве систем хранятся не сами пароли, а их хеши. 💡 Когда пользователь вводит пароль: 1️⃣ Система вычисляет его хеш. 2️⃣ Сравнивает его с тем, который хранится в базе. 3️⃣ Если они совпадают — пользователь успешно проходит аутентификацию. 💀 Почему это интересно пентестеру? Потому что злоумышленнику далеко не всегда нужен сам пароль. Во многих случаях достаточно получить: 👉 NTLM-хеш. А дальше уже становятся возможны такие атаки, как: — Pass-the-Hash — NTLM Relay — Offline Cracking 📌 Поэтому во время инфраструктурного пентеста очень часто охотятся именно за хешами, а не за паролями. Именно вокруг них построено множество современных атак на Active Directory. #infra #ad #hash #authentication