Mysql как получить хеш пароля
Обновлено: 07.07.2024
SQL сервер использует недокументированную функцию pwdencrypt() для создания хешей пользовательских паролей, которые затем хранятся в главной базе. Иными словами
- пароли криптуются и хранятся в зашифрованном виде.
Получить их можно простым запросом, так как
они хранятся в обычной базе данных:
select password from master.dbo.sysxlogins where
name='sa'
Хеш пароля выглядит примерно так:
Выглядит это надо сказать страшно… Давай-ка разберемся, что влияет на его формирование:
Попробуем к примеру закриптовать пароль 'foo'.
Делается это командой:
Ну а если попробуем через пару секунд еще раз, то получим:
Легко заметить, что мы получаем различные хеши, что означает, что хеш зависит от времени. Таким образом два или боле пользователей могут иметь иметь одинаковые пароли, но при этом хеши паролей будут различны.
Теперь давай попробуем зашифровать 'AAAAAA':
Если повнимательней вглядеться в полученный хеш, то его можно условно разделить на четыре части:
0x0100
84449305
43174C59CC918D34B6A12C9CC9EF99C4769F819B
43174C59CC918D34B6A12C9CC9EF99C4769F819B
Причем третья и четвертая части у нас абсолютно тождественны. Это связанно с тем, что по непонятным причинам пароль сохраняется дважды: в первый раз "как есть" (т.е. с учетом регистра), а второй раз - в верхнем регистре. Так как в нашем примере исходный пароль весь состоял из букв в верхнем регистре, то в результате "двойного сохранения", мы получили абсолютно идентичные части хеша.
Гипотетически это значительно сокращает
время брутфорса, так как надо перебирать
только буквы верхнего регистра.
Но влияет ли время на хеш непосредственно? Ответ - нет. Функция Time() создает лишь исходную точку для функции srand(), которая генерирует два случайных числа. Эти числа объединяются (с большой долей вероятности можно также предположить, что эти числа также приводятся к "сокращенному варианту") и получается salt, который в дальнейшем используется при "производстве" хеша.
Криптование пароля
Пароль преобразуется в Unicode и к нему добавляется salt. Потом все это проходит через функции криптования в advapi32.dll - в результате мы получает "третью" часть хеша (как мы рассматривали в пункте про влияние регистра).
Потом пароль преобразуется в верхний регистр и указанные манипуляции повторяются - получаем "четвертую" часть хеша.
Затем производится "сборка" окончательного вариант хеша, который и будет хранится в базе:
Берется неизменный заголовок:
Затем тот salt, который использовался при криптовании пароля:
Третья и четвертая части - непосредственно сам пароль (в неизменном виде и в верхнем регистре соответственно):
Все! Получается тот самый, некрасивый и страшный хеш:
Как происходит идентификация
Пользователь вводит пару логин/пароль.
Сначала происходит проверка на наличие пользователя с данным логином. Если проверка успешна и пользователь существует, то из соответствующего хеша извлекается salt (вторая часть хеша) и введенный пользователем пароль криптуется с использованием этого salt. Затем полученный результат сравнивается с имеющимся хешем в базе. В случае совпадения пользователь получает доступ, в противном - идет вспоминать пароль…
Слабые места
Не совсем понятно, почему пароль сохраняется в хеше дважды - ведь имея хешированный пароль в верхнем регистре, атакующий имеет возможность существенно сократить объем работы: в начале "расколоть" пароль в верхнем регистре и узнать какие символы используются, а затем просто провести проверку всех комбинаций этих символов в верхнем и нижнем регистрах. Таким образом объем работы по данному алгоритму в десятки, сотни и даже тысячи раз (зависит от длины пароля) меньше, чем при попытке взломать чувствительный к регистру пароль как говорится в "лоб".
Для практической реализации данной идеи была написана консольная программа, листинг которой я тебе и предлагаю
(очень полезно было бы разобрать листинг и
понять как действует программа - впрочем
это, как обычно, на твое усмотрение):
Существует также неконсольная версия данного крякера. Ее создатели утверждают, что она работает быстрее…но она платная, а ты ведь платить не любишь…
От автора: вы куда полезли через ограду, гражданин! На заборе написали пароль, чтоб не забыть. Так может вы с этой стороны написали? Да нет – это не мой написан. Ну, удачных поисков, а всем остальным я расскажу, как узнать пароль MySQL, не перелезая через чужие заборы.
Нет ничего проще!
Если у вас есть элементарные знания и навыки обращения с СУБД MySQL, и (главное) учетная запись администратора, то узнать пароли всех пользователей можно в два счета. Для этого можно использовать как программные оболочки, так и команды SQL.
Что представляет собой сервер СУБД? Это обычная база данных, содержащая в себе всю нужную для работы MySQL информацию. Здесь хранятся все настройки сервера, баз, сведения о плагинах, дате и времени, пользовательские учетные записи, их привилегиях и паролях. В контексте данной статьи нас интересует значения последних.
Чтобы узнать пароль MySQL, нужно зайти на сервер под своей учеткой администратора. Затем открыть системную базу данных с именем «mysql» и сделать выборку значений из таблицы user. Для наглядности все интересующие сведения (значения паролей) мы получим с помощью php MyAdmin.
Откроем системную БД, и посмотрим на содержимое нужной нам таблицы «сблизи»: в одном из ее столбцов прописаны все пароли. Как видите, ничего сложного и для этого нам понадобилось всего несколько минут. Но что это такое? Кто «стибрил» из таблицы понятные значения паролей и заменил их какой-то «абракадаброй»!
Бесплатный курс по PHP программированию
Освойте курс и узнайте, как создать динамичный сайт на PHP и MySQL с полного нуля, используя модель MVC
В курсе 39 уроков | 15 часов видео | исходники для каждого урока
Спокойствие, и только спокойствие! Никто ничего «не стибрил», просто в таблице указываются уже хешированные пароли. А что у вас глаза такие удивленные? Сейчас все разложим «по полочкам».
Как происходит шифрование в MySQL
Дело в том, что данная СУБД использует собственный алгоритм шифрования паролей. Точнее, не шифрования, а хеширования. Из-за этого пока никто не придумал способа, как расшифровать пароли в MySQL.
Существуют различные алгоритмы хеширования, но если при этом будет использоваться криптографическая толь, то шансов получить значение пароля сводится почти к 0. Криптографическая соль – это дополнительная строка, которая присоединяется к первоначальному значению. В результате на выходе (после хеширования) получается почти «невзламываемый» пароль.
Для установки пароля СУБД использует функцию PASSWORD(). Она не возвращает значения, которое было послано ей на обработку. Поэтому использовать данную функцию для получения «читаемого» пароля не получится. Единственное, что можно сделать – это получить хешированную строку по первоначальному значению. Синтаксис запроса:
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Если приложение не очень секретное, то защищать имеет смысл только небольшую часть информации, например, сведения о паролях. Пароли ни в коем случае не следует хранить в открытом виде, поэтому обычно они шифруются. Однако вместо шифрования можно взять за образец принятую в большинстве UNIX-систем да и в самом MySQL практику: применить к паролю алгоритм хеширования и сохранить в таблице получившийся результат (свертку).
В отличие от традиционного шифрования, которое можно обратить, хорошая функция хеширования необратима. Единственный способ узнать пароль, по которому была сгенерирована свертка, - применить требующий огромных вычислительных ресурсов полный перебор (то есть, испробовать все возможные варианты входных данных).
В MySQL есть три функции для хеширования паролей: ENCRYPT(), SHA1 () и MD5Q 1 . Чтобы посмотреть, что они возвращают, проще всего приме-
нить каждую из них к одному и тому же входному тексту. Давайте сделаем это на примере строки p4ssword:
mysql> SELECT MD5(‘p4ssword’), ENCRYPT(‘p4ssword’), SHA1(‘p4ssword’)\G
MD5(‘p4ssword’): 93863810133ebebe6e4c6bbc2a6ce1e7 ENCRYPT(‘p4ssword’): dDCjeBzIycENk
Все три функции возвращают строку букв и цифр фиксированной длины, которую можно сохранить в столбце типа CHAR. Поскольку ENCRYPT () может возвращать буквы в разных регистрах, то лучше указать для столбца тип CHAR BINARY.
Никогда не используйте в приложениях внутреннюю функцию MySQL PAS SWO R D (). Возвращаемые ей результаты зависят от версии MySQL.
Для сохранения свертки данных достаточно такой команды:
mysql> INSERT INTO user_table (user, pass) VALUES (‘user’, MD5(‘p4ssword’) );
Чтобы проверить пароль пользователя user, можно выполнить запрос SELECT и проверить совпадает ли свертка указанного переданного пароля с тем, что хранится в базе. На языке Perl это можно сделать следующим образом:
my $sth = $dbh->prepare(‘SELECT * FROM user_table ‘
. ‘WHERE user = ? AND pass = MD5(?)’);
Хеширование паролей - простой и относительно безопасный способ хранить пароли в базе данных, не опасаясь взлома. Чтобы усложнить атаку по словарю, можно хешировать комбинацию имени и пароля пользователя, так что результат зависит от большего числа переменных:
my $sth = $dbh->prepare(‘SELECT * FROM user_table ‘
. ‘WHERE user = ? AND pass = SHA1(CONCAT(?, ?))’); $sth->execute($username, $username, $password):
Единственная проблема - это риск, сопряженный с тем, что серверу пароли отправляются в открытом виде; он может быть записан в виде обычного текста в журнал на диске и виден в дампе памяти процесса. Чтобы немного снизить этот риск, можно хранить пароль в пользовательской переменной или вообще переместить хеширование на уровень приложения, чтобы устранить проблему на корню. Для большинства языков программирования имеются функции или библиотеки шифрования. Чуть ниже мы рассмотрим вопрос о шифровании на уровне приложения.
MySQL перечисляет учетные записи пользователей в user таблица mysql база данных. Каждая учетная запись MySQL может быть присвоена пароль, хотя user таблица не хранит версию открытого текста пароля, но значение хэш-функции, вычисленное от этого.
MySQL использует пароли в двух фазах клиент-серверной передачи:
Когда клиент пытается соединиться с сервером, есть начальный шаг аутентификации, в котором клиент должен представить пароль, у которого есть значение хэш-функции, соответствующее значение хэш-функции, сохраненное в user таблица для учетной записи клиент хочет использовать.
После того, как клиент соединяется, это может (если у этого есть достаточные полномочия), набор, или измените хэш пароля для учетных записей, перечисленных в user таблица. Клиент может сделать это при использовании PASSWORD() функция, чтобы генерировать хэш пароля, или при использовании генерирующего пароль оператора ( CREATE USER , GRANT , или SET PASSWORD ).
Другими словами сервер проверяет значения хэш-функции во время аутентификации, когда клиент сначала пытается соединиться. Сервер генерирует значения хэш-функции, если соединенный клиент вызывает PASSWORD() функция или использование генерирующий пароль оператор, чтобы установить или изменить пароль.
У методов хеширующего пароля в MySQL есть история, описанная после. Эти изменения иллюстрируются изменениями в следствии PASSWORD() функция, которая вычисляет значения хэша пароля и в структуре user таблица, где пароли сохранены.
Оригинал (пред4.1) Хеширующий Метод
Исходный хеширующий метод, произведенный 16 строк байтов. Такие хеши похожи на это:
Сохранить пароли учетной записи, Password столбец user таблица была в этой точке 16 байтов длиной.
4.1 Хеширующих Метода
Представленный пароль MySQL 4.1, хеширующий, который обеспечивает лучшую безопасность и уменьшает риск прерываемых паролей. Было несколько аспектов к этому изменению:
Отличающийся PASSWORD() функционируйте формат результата
Расширение Password столбец
Управление методом хеширующего значения по умолчанию
Управление разрешенными хеширующими методами для клиентов, пытающихся соединяться с сервером
Изменения в MySQL 4.1 имели место на двух этапах:
MySQL 4.1.0, используемый предварительная версия 4.1 хеширующих методов. Поскольку этот метод был настолько недолгим, следующее обсуждение не говорит больше об этом.
В MySQL 4.1.1 хеширующий метод был изменен, чтобы произвести более длительное 41-байтовое значение хэш-функции:
У более длинного формата хэша пароля есть лучшие криптографические свойства, и аутентификация клиента, основанная на длинных хешах, более безопасна чем это основанное на более старых коротких хешах.
Размещать более длительные хэши пароля, Password столбец в user таблица была изменена в этой точке, чтобы быть 41 байт, ее текущая длина.
Расширенный Password столбец может сохранить хэши пароля и в пред4.1 и в 4.1 форматах. Формат любого данного значения хэш-функции может быть определен два пути:
Длина: 4.1 и пред4.1 хеша составляют 41 и 16 байтов, соответственно.
Хэши пароля в этих 4.1 форматах всегда начинаются " * " символ, тогда как пароли в этих пред4.1 форматах никогда не делают.
Чтобы разрешить явную генерацию пред4.1 хэшей пароля, два дополнительных изменения были произведены:
OLD_PASSWORD() функция была добавлена, который возвращает значения хэш-функции в 16-байтовом формате.
В целях совместимости, old_passwords системная переменная была добавлена, чтобы включить управлению DBA и приложениями хеширующим методом. Значение по умолчанию old_passwords значение 0 причин, хеширующих, чтобы использовать 4.1 метода (41-байтовые значения хэш-функции), но установка old_passwords=1 причины, хеширующие, чтобы использовать пред4.1 метода. В этом случае, PASSWORD() производит 16-байтовые значения и эквивалентен OLD_PASSWORD()
Чтобы разрешить DBA управляют по тому, как клиентам разрешают соединиться, secure_auth системная переменная была добавлена. Запуск сервера с этой переменной отключенные или включенные разрешения или запрещает, что клиенты соединяют использование более старых пред4.1 методов хеширующего пароля. Перед MySQL 5.6.5, secure_auth отключается по умолчанию. С 5.6.5, secure_auth позволяется по умолчанию продвинуть более безопасную конфигурацию значения по умолчанию. (DBA могут отключить это по своему усмотрению, но это не рекомендуется.)
Кроме того, mysql клиент поддерживает a --secure-auth опция, которая походит secure_auth , но от стороны клиента. Это может использоваться, чтобы предотвратить соединения с менее безопасными учетными записями, которые используют пред4.1 хеширующие пароля. Эта опция отключается по умолчанию перед MySQL 5.6.7, включенным после того.
Проблемы совместимости, Связанные с Хешированием Методов
Расширение Password столбец в MySQL 4.1 от 16 байтов до 41 байта влияет на установку или операции обновления следующим образом:
Если Вы выполняете новую установку MySQL, Password столбец делается 41 байт длиной автоматически.
Обновления от MySQL 4.1 или позже к текущим версиям MySQL не должны дать начало никаким проблемам в отношении Password столбец, потому что обе версии используют ту же самую длину столбца и метод хеширующего пароля.
Для обновлений от пред4.1 выпусков до 4.1 или позже, следует обновить системные таблицы после обновления. (См. Раздел 4.4.7, " mysql_upgrade — Таблицы MySQL Check и Upgrade".)
Это явление также происходит для попыток использовать более старый PHP mysql расширение после обновления до MySQL 4.1 или более новый. (См. Раздел 21.9.12, "Типичные проблемы с MySQL и PHP".)
Следующее обсуждение описывает различия между пред4.1 и 4.1 хеширующими методами, и что следует сделать, если Вы обновляете свой сервер, но должны поддержать обратную совместимость с пред4.1 клиентами. (Однако, разрешение соединений старыми клиентами не рекомендуется и должно избежаться если возможный.) Дополнительная информация может быть сочтена в Разделе C.5.2.4," Client does not support authentication protocol ". Эта информация имеет особое значение для баз данных MySQL перехода PHP программистов от версий, более старых чем 4.1 к 4.1 или выше.
Различия между короткими и долгими хэшами пароля важны и для того, как сервер использует пароли во время аутентификации и для того, как это генерирует хэши пароля для соединенных клиентов, которые выполняют изменяющие пароль операции.
На путь, которым сервер использует хэши пароля во время аутентификации, влияет width Password столбец:
Если столбец короток, только аутентификация короткого хеша используется.
Если столбец длинен, он может содержать или короткие или длинные хеши, и сервер может использовать любой формат:
Пред4.1 клиента могут соединиться, но потому что они знают только о пред4.1 хеширующих методах, они могут аутентифицировать только учетные записи использования, у которых есть короткие хеши.
4.1 и позже клиенты могут аутентифицировать учетные записи использования, у которых есть короткие или длинные хеши.
Даже для учетных записей короткого хеша, процесс аутентификации фактически немного более безопасен для 4.1 и позже клиенты чем для клиентов старшего возраста. С точки зрения безопасности градиент от меньше всего до самого безопасного:
Пред4.1 клиента, аутентифицирующие с коротким хэшем пароля
4.1 или более поздний клиент, аутентифицирующий с коротким хэшем пароля
4.1 или более поздний клиент, аутентифицирующий с долгим хэшем пароля
На путь, которым сервер генерирует хэши пароля для соединенных клиентов, влияет width Password столбец и old_passwords системная переменная. 4.1 или более поздний сервер генерируют длинные хеши, только если определенные условия соблюдаются: Password столбец должен быть достаточно широким, чтобы содержать длинные значения и old_passwords не должен быть установлен в 1.
Те условия применяются следующим образом:
Password столбец должен быть достаточно широким, чтобы содержать длинные хеши (41 байт). Если столбец не был обновлен и все еще имеет пред4.1 width 16 байтов, сервер замечает, что длинные хеши не могут вписаться в это и генерируют только короткие хеши, когда клиент выполняет изменяющие пароль операции, используя PASSWORD() функционируйте или генерирующий пароль оператор. Это - поведение, которое происходит, если Вы обновили от версии MySQL, более старого чем 4.1 к 4.1 или позже, но еще не выполнили mysql_upgrade программу, чтобы расшириться Password столбец.
Если Password столбец широк, он может сохранить или короткие или долгие хэши пароля. В этом случае, PASSWORD() функционируйте и генерирующие пароль операторы генерируют длинные хеши, если сервер не был запущен с old_passwords системный набор переменной к 1, чтобы вынудить сервер генерировать короткие хэши пароля вместо этого.
Цель old_passwords системная переменная должна разрешить обратную совместимость с пред4.1 клиентами при обстоятельствах, где сервер иначе генерировал бы долгие хэши пароля. Опция не влияет на аутентификацию (4.1, и позже клиенты могут все еще использовать учетные записи, у которых есть долгие хэши пароля), но это действительно предотвращает создание долгого хэша пароля в user таблица как результат изменяющей пароль работы. Были это разрешало происходить, учетная запись больше не могла использоваться пред4.1 клиентами. С old_passwords отключенный, следующий нежелательный сценарий возможен:
Старые пред4.1 клиента соединяются с учетной записью, у которой есть короткий хэш пароля.
Клиент изменяет его собственный пароль. С old_passwords отключенный, это приводит к учетной записи, имеющей долгий хэш пароля.
В следующий раз, когда старый клиент пытается соединиться с учетной записью, она не может, потому что у учетной записи есть долгий хэш пароля, который требует 4.1 хеширующих методов во время аутентификации. (Как только у учетной записи есть долгий хэш пароля в пользовательской таблице, только 4.1, и позже клиенты могут аутентифицировать для этого, потому что пред4.1 клиента не понимают длинные хеши.)
Этот сценарий иллюстрирует, что, если следует поддерживать пред4.1 клиента старшего возраста, это проблематично, чтобы выполнить 4.1 или более новый сервер без old_passwords набор к 1. Выполняя сервер с old_passwords=1 , изменяющие пароль операции не генерируют долгие хэши пароля и таким образом не заставляют учетные записи становиться недоступными клиентам старшего возраста. (Те клиенты не могут непреднамеренно заблокировать себе, изменяя их пароль и заканчивая с долгим хэшем пароля.)
Нижняя сторона old_passwords=1 это любые пароли создаваемое или измененное использование короткие хеши, даже для 4.1 или позже клиенты. Таким образом Вы теряете дополнительную безопасность, обеспеченную долгими хэшами пароля. Чтобы создать учетную запись, у которой есть длинный хеш (например для использования 4.1 клиентами) или изменить существующую учетную запись, чтобы использовать долгий хэш пароля, администратор может установить значение сеанса old_passwords набор к 0, оставляя глобальный набор значений 1:
Следующие сценарии возможны в MySQL 4.1 или позже. Факторы то, ли Password столбец короток или длинен, и, если долго, начинается ли сервер с old_passwords включенный или отключенный.
Сценарий 1: Короткий Password столбец в пользовательской таблице:
Только короткие хеши могут быть сохранены в Password столбец.
Сервер использует только короткие хеши во время аутентификации клиента.
Для соединенных клиентов, генерирующие хэш пароля операции, включающие PASSWORD() функционируйте или генерирующие пароль операторы используют короткие хеши исключительно. Любое изменение к паролю учетной записи приводит к той учетной записи, имеющей короткий хэш пароля.
Значение old_passwords не важно потому что с коротким Password столбец, сервер генерирует только короткие хэши пароля так или иначе.
Этот сценарий происходит, когда пред4.1 установки MySQL были обновлены до 4.1 или позже но mysql_upgrade не был выполнен, чтобы обновить системные таблицы в mysql база данных. (Это не рекомендуемая конфигурация, потому что она не разрешает использование более безопасных 4.1 хеширующих паролей.)
Сценарий 2: Долго Password столбец; сервер, запущенный с old_passwords=1 :
Короткие или длинные хеши могут быть сохранены в Password столбец.
4.1 и позже клиенты могут аутентифицировать для учетных записей, у которых есть короткие или длинные хеши.
Пред4.1 клиента могут аутентифицировать только для учетных записей, у которых есть короткие хеши.
Для соединенных клиентов, генерирующие хэш пароля операции, включающие PASSWORD() функционируйте или генерирующие пароль операторы используют короткие хеши исключительно. Любое изменение к паролю учетной записи приводит к той учетной записи, имеющей короткий хэш пароля.
В этом сценарии у недавно создаваемых учетных записей есть короткие хэши пароля потому что old_passwords=1 предотвращает генерацию длинных хешей. Кроме того, если Вы создаете учетную запись с длинным хешем перед установкой old_passwords к 1, изменяя пароль учетной записи, в то время как old_passwords=1 результаты в отчете, сделанном короткий пароль, заставляя это потерять преимущества безопасности более длинного хеша.
Чтобы создать новую учетную запись, у которой есть долгий хэш пароля, или изменить пароль любой существующей учетной записи, чтобы использовать длинный хеш, сначала устанавливают значение сеанса old_passwords набор к 0, оставляя глобальный набор значений 1, как описано ранее.
В этом сценарии у сервера есть современное Password столбец, но выполняет с паролем значения по умолчанию хеширующий набор метода, чтобы генерировать пред4.1 значения хэш-функции. Это не рекомендуемая конфигурация, но может быть полезно во время переходного периода, в который пред4.1 клиента и пароли обновляются до 4.1 или позже. Когда это было сделано, предпочтительно выполнить сервер с old_passwords=0 и secure_auth=1 .
Сценарий 3: Долго Password столбец; сервер, запущенный с old_passwords=0 :
Короткие или длинные хеши могут быть сохранены в Password столбец.
4.1 и позже клиенты могут аутентифицировать учетные записи использования, у которых есть короткие или длинные хеши.
Пред4.1 клиента могут аутентифицировать только учетные записи использования, у которых есть короткие хеши.
Для соединенных клиентов, генерирующие хэш пароля операции, включающие PASSWORD() функционируйте или генерирующие пароль операторы используют длинные хеши исключительно. Изменение к паролю учетной записи приводит к той учетной записи, имеющей долгий хэш пароля.
Как обозначено ранее, опасность в этом сценарии состоит в том, что это возможно для учетных записей, у которых есть короткий хэш пароля, чтобы стать недоступными пред4.1 клиентам. Изменение к паролю такой учетной записи, сделанному, используя PASSWORD() функционируйте или генерирующий пароль оператор приводит к отчету, сделанному долгий хэш пароля. От той точки на клиент № пред4.1 может соединиться с сервером, используя ту учетную запись. Клиент должен обновить до 4.1 или позже.
Если это - проблема, можно изменить пароль специальным способом. Например, обычно Вы используете SET PASSWORD следующим образом изменить пароль учетной записи:
Чтобы изменить пароль, но создать короткий хеш, используйте OLD_PASSWORD() функция вместо этого:
OLD_PASSWORD() полезно для ситуаций, в которых Вы явно хотите генерировать короткий хеш.
Недостатки для каждого из предыдущих сценариев могут быть получены в итоге следующим образом:
В сценарии 1 невозможно использовать в своих интересах более длинные хеши, которые обеспечивают более безопасную аутентификацию.
В сценарии 2, old_passwords=1 предотвращает учетные записи с короткими хешами от становления недоступными, но изменяющими пароль учетными записями причины операций с длинными хешами, чтобы вернуться к коротким хешам, если Вы не заботитесь, чтобы изменить значение сеанса old_passwords к 0 сначала.
В сценарии 3 учетные записи с короткими хешами становятся недоступными пред4.1 клиентам, если Вы изменяете их пароли без явного использования OLD_PASSWORD() .
Лучший способ избежать проблем совместимости, связанных с короткими хэшами пароля, не состоит в том, чтобы использовать их:
Обновите все клиентские программы до MySQL 4.1 или позже.
Сбросьте пароль для любой учетной записи с коротким хэшем пароля, чтобы использовать долгий хэш пароля.
Пишу мост между сайтом и win программой.
Пароли пользователей шифруются движком сайта методом md5.
Сделал таким вот способом.
В итоге как зашифровать понятно, а как прочитать такой код из Delphi и расшифровать его в нормальную строку непонятно, ни Яша ни Гугл результатов нормальных не выдал.
Помогите с расшифровкой.
Заранее всем спасибо.
__________________Помощь в написании контрольных, курсовых и дипломных работ здесь
Использование MD5 для проверки хэша пароля с MySQL
Здравствуйте форумчане, у меня возникла такая проблема, надо чтобы пароль введенный в textbox.
Нужно расшифровать MD5 из базы MySql
MysqlConn = New MySqlConnection MysqlConn.ConnectionString = constring Using.
Чтение логина и пароля из базы данных для сохранения в куки
Здравствуйте, у меня такая вот задача: нужно ввести в текст. поля логин и пароль и записать их в.
Т.е. вы хотите подсмотреть пароли своих пользователей? А вы знаете, что это некрасиво ?
Добавлено через 4 минуты
Я просто не знал как это правильно реализовать, ничего я не хочу подсматривать. Мне просто нужно идентифицировать пользователя.
Т.е. как я понял нужно смоделировать ситуацию создания хеша в Delphi аналогично ситуации создания хеша в MySQL. И потом сравнить по введенному логину хеш пароля в базе с хешем пароля введенным пользователем в программе.
Как же создать такой хеш из Delphi и какие параметры использует MD5, т.е. что нужно указать для создания идентичного хеша?
Вроде как MD5 использует всю строку MySQL таблицы и учитывает все филды. Или я не прав?
Вроде как MD5 использует всю строку MySQL таблицы и учитывает все филдыНа самом деле данная функция генерирует дайджест от строки admin и все. Получится строка из 32-х символов 21232f297a57a5a743894a0e4a801fc3.
это нужно смотреть как генерируется хеш в Вашей CMS, т.к. многие СMS добавляют к паролям доп значения для усиления брутфорсостойкости пароля.Хорошо, я Вас понял.
Если опустить тонкости(нужно время на выяснение кода создания кеша Joomla), то как вызвать функцию создания кеша MD5 в Delphi?
Добавлено через 4 минуты
Больше того, в тырнетах есть очень много сервисов, которые позволяют ввести хеш чтобы проверить по базе известных строк, а если такой не обнаружиться попробовать брутануть оный. Но даже они не могут подобрать хеш от строки случайных символов длинной эдак 60 символов.
Читайте также: