Потестил.
1. Есть ХСС, но тут я не первый, первым был Spyder с хешем 1cd4d78142e0398528f94d8d6183740e.
Причем для реализации не нужно кодировать урл и т.д., просто просим кого-то проверить нужный хеш ссылаясь на то что „у меня сервис что то не открывается”. Но так как авторизации нету, то и куки нам нафиг не нужны, а значит ХСС тоже
.
Но недостаток для пользователя все же есть. Дело в том что если пароль будет вида <password> или <b>password, то в первом случае юзер вообще не увидит результатов, хотя будет надпись «пароль найден», а во втором засветится «пароль найден: password» но уже без <b>. Т.е. если кусок пароля будет содержать открытую и закрытую скобки, то при построении страницы они не будут выведены (хотя в ресурсах страницы мы можем найти результат)
2. Дальше интереснее. Баловался с кавычками. Если пароль будет содержать кавычку (например p”assword, его хеш b2bb20ac9190447c8b0ba957d0c96f3d) и мы его добавим в базу, то при попытке поиска по хешу мы НЕ найдем пароль (есть одно но… если этот хеш будет в базе на других сервисах с которыми дружит данный то все таки найдет). Не найдем потому что в базу пароль попадает в виде p\”assword и соответственно его хеш равен bf9c508e10fa5a958e6d7b57402d2a39. Та же ситуация со слешами, ведь они тоже экранируються. Т.е. если мы добавляем пароль такого вида \\\\\\ то экранирование его преобразует в что-то со множеством слешей
и в базу попадает савсем другой пароль и хеш. С одинарной кавычкой тоже самое.
3. После предыдущего под прицел попали такие сочетания символов: " & и т.д. т.е. заменители служебных символов (как они там правильно называются?). Если пароль будет иметь эти сочетания то при выводе они будут отображаться как те символы которые они представляют. Т.е. если пароль будет вида p"ass (его хеш - afe5d4a6a9b8bc7e8a86385d5ee720b2) то при выводе результатов поиска мы увидим p”ass, что, согласитесь, нам не подходит.
4. Интересное явление наблюдается при «парсинге» с других сервисов паролей содержащих кавычки. Дело в том что если такой пароль будет найден на дружественном сервисе, то он верно отобразиться при поиске, НО в базу будет занесено совсем другое. Например: p””assword (c3cb8f719fee2067b2ab98065f34fa16) если будет находиться в базе пасскракинг.ру то при поиске мы увидим что „пароль найден не у нас и добавлен в базу”, при этом вывод этого пароля будет верный, а вот в базу попадет то что спарсили, а именно p""assword. От этого пароля будет найден хеш и тоже будет занесен в базу. Если мы еще раз попытаемся поискать хеш от p””assword, то сервис его у себя не найдет, а найдет у чужих и ЕЩЕ раз занесет в базу и т.д. Это способ добавления ОДИНАКОВЫХ записей в базу, при этом они НЕ НУЖНЫ там.
Этот случай я до конца не исследовал, там в комбинации с предыдущими возможны разные варианты….. и реакция системы тоже разная
.
5. База позиционируется как база уникальных паролей. В ней нету коротких, 1-8 цифровых и т.д. Но если поискать хеш от этих паролей то его найдут сторонние сервисы и услужливо внесут этот пароль в базу. Во всяком случае об этом пишет сервис «пароль был добавлен…», когда я консультировался с Халкфилдом, он ответил что такие пароли вырезает. (я проверял не всегда вырезает) Вроде бы проблема решена, но если вырезает то возникает следующая ситуация. Например мы ищем хеш от пароля %:?, (он не попадает в категорию для занесения в базу) при этом его нету у дружественных сервисов, то нам пишет ответ «не найден», а сам хеш добавляется в очередь для поиска. Как только пароль будет найден, он НЕ БУДЕТ записан в базу (вот этого проверить не удалось… т.к. не знаю как работает скрипт), юзер который запросил поиск этого пароля, снова запросит и снова получит ответ «не найден, добавлен в очередь» и так пока не надоест. Хотя пароль находиться. Это недостаток НЕхранения найденных коротких паролей, они не будут найдены никогда.
Было что то еще, но пока писал – забыл
Комбинации всего этого получаются интересными…..<”\\"password’ > или “””
Вывод такой….. в базе должны храниться пароли в своем первоначальном виде, без всяких заменителей и экранов. Служебные символы и сочетания должны обрабатываться правильно, тоже при парсинге от других сервисов. Нужна проверка на повторяющиеся записи в базе. Та возможность добавления простых пассов (или все же не добавляет) от дружественных сервисов, а также внесение из-за экранирования кавычек и слешей, да и все остальное…. делает запись о количестве хранимых в базе хешей очень не правдивой с точки зрения УНИКАЛЬНОСТИ базы, т.е. базы хранящей только уникальные пароли найденные юзерами. Ведь на самом деле там меньше таких паролей, остальные либо короткие или цифровые добавленные других серверов, либо пароли которые имеют заэкранированые служебные символы типа кавычек. Может их и не так много но все же.
З.Ы. Если все это не актуально не судите строго просто потрите пост или я сам удалю если будет нужно.
З.Ы.Ы. Еще бы хотелось увидеть исходники скриптов…… была мысль о возможности выполнения «злого» ПХП кода при поиске определенных хешей….Халкфилд обещал дать посмотреть….
Опять дофига написал..... ну не могу иначе
