В общем суть простая.. Был сайт в кодировке window-1251 и соответственно пароли в базе хэшировались в этой кодировке. Потом сайт стал в кодировке UTF-8, данные в базе конвертнул в utf-8, но вот что делать с паролями..

Есть ли возможность преобразовать md5(window-1251) в md5(utf-8)? Или всё же только перерегистрация?

только если есть исходные пароли  

Добавлено через 27 секунд
можно воспользоваться iconv'ом для перекодирования utf8 в cp1251.

на форму входа можно обработку введённых данных в кодировке ср1251 повесить
можно вновь регистрирующихся отслеживать и тд.

я в шоке.. но кажется получилось... тогда не понимаю хэш.. ведь русская буква имеет разное числовое значение в разных кодировках...

может ещё кто подтвердит что простой iconv помогает? 

Добавлено через 1 минуту и 22 секунды
srt, легче заставить всех восстановить пароль у кого не подходит. чем создавать обработчик 

Это сообщение отредактировал(а) Gold Dragon - 24.6.2011, 10:22

А что Вас удивляет?
Правильно разное. Вы конвертируете utf-8 в cp1251 и вычисляете хеш.
Ничего удивительного.

ну я вообще-то думал что
текст в win не равно текст в utf... а значит и хеш должен быть разный.. и уже хеш в win просто не конвертируется в хеш в utf

как вариант, можно в принципе, в неявном для юзеров виде, изменять пароль при входе.

1. добавить поле в базу, что-то типа новый_пароль, установить его в 0 для всех юзеров
2. юзер вводит свои данные
3.  хэшируем пароль в 1251 и в utf
4. пытаемся залогиниться, следующим запросом

5. если юзер зашел, проверить поле new_pass
 - если оно равно 0 - то переписать старый хэш на утэфовский, и установить new_pass в 1
 - если равно 1 - ничего не делать

6. и так пока все юзере не перепишут себе хэши.

ну а новых разумется писать уже в утф.

если оно того стоит конечно...

Это сообщение отредактировал(а) patap - 24.6.2011, 10:54

Стоп. Стоп. Стоп. Хеш да не конвертируется. Исходная строка конвертируется, от нее берется хеш.

т.е. получается.. в базе у меня пароли в кодировке win-1251 преобразованные md5

Чтобы пароли принимались на сайте где всё теперь работает в utf-8 достаточно только преобразовать хэш в базе, так?

нет.

Смотри, у тебя сейчас сайт в utf8, а пароли остались в cp1251. С помощью iconv преобразовали utf8 в cp1251, а затем сделали их хэш.

так пароли то закрыты MD5  обратно то они не вернуться.....

Добавлено через 12 минут и 59 секунд
вот кое что написал для проверки

пользователь вводит пароль, строка в скрипте оказывается в кодировке utf-8, затем ты её конвертишь в cp1251, а от него берёшь хэш. и уже этот хэш и сравниваешь с тем хэшем, который в БД. то есть сравниваемые строки оказываются в одинаковых кодировках перед взятием хэша

bars80080, мне нужно старую базу паролей перегнать  Всё новое конечно уже в utf-8

А пример кода я показал что хэш конвертируется и результат вроде одинаковый

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

так я про это и говорю...   Я тупо конвертирую сам хеш и получается тот же результат что если бы я преобразовал md5 в utf-8... Ну или в моём примере есть ошибка 


Это сообщение отредактировал(а) Gold Dragon - 24.6.2011, 16:47

По идее преобразование хеша не может дать результата т.к. хеш это нечто иное, чем закодированная информация. Хеш просто нереально раскодировать, хотя бы потому, что он не наследует полный объем информации из искомого объекта. 

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

Пока же я в этом не уверен - подскажу самый просто вариант реализации. 

Получая от пользователя ввод пароля мы его как обычно кешируем и сравниваем с кешем newPassword. Если не подошел то сравниваем с кешем oldPasword (я так понимаю, что как правильно перекодировать строку для проверки Вы сами знаетете) . Соответственно у нас несколько результатов.

1. Подошел newPassword - отлично, этот пользователь уже перешел на новый режим работы
2. Подошел oldPassword - отлично, пользователь успешно авторизовался и мы, в данном случаае имея только что введенный исходник пароля делаем из него новый кеш в нужной нам кодеровке для сохранения в newPassword. Хорошая работа - этот пользователь, сам того не подозревая перешел на новый режим работы. (поле oldPassword можно почистить, чтоб иметь возможность делать выборку пользователь не перешедших на новый режим)
3. Не подошли оба пароля - увы, тут мы нечем не поможем бедолаге =)

Для реализации нужно минут 30 максимум - вполне элементарные действия. После теста - надо придумать какую-нибудь маргетинговую фишку, чтоб нагнать народ. Ждем с пол года и делаем рассылку всем тем, у кого заполненно поле oldPassword , но не заполненно newPassword с информацией о том, что если они в течение недели не авторизируються на сервисе, то их аккаунт удалят.

=) Через неделю чистим аккаунты пользователей которые давно забыли про Ваш рессурс и удаляем лишний столбец из бд. Поздравляю - миграция закончена.

BuShaRt, ты всё правильно говоришь... Самое простое заставить всех перерегистрироваться. во-первых, напомнить о себе. Во-вторых, почистить базу пользователей

но(!)

Посмотри мой пример. Это то что я думаю или же всё таки я нарушил логику и пытаюсь выдать желаемое за действительное?

А в переменной $a сейчас точно данные в win? 

текстовый файл в кодировке win.. сам проверь 

Добавлено через 24 секунды
да и хеш то разны получается

Сейчас проверить не могу, но как буду дома проверю - уж очень интересно стало.

BuShaRt, ну если и у тебя получится.. то я вообще в шоке  

Сравнивать то надо две последние строки. Если текст с русскими буквами - хэши различаюся, если только латинские - одинаковые.
Латинские буквы вроде кодируются одинаково и в UTF-8 и в Win1251,  отсюда и хэши однаковые.
Если я прав, и пароли у вас на сайте только из латинских букв и цифр, то конвертировать их не нужно.



Это сообщение отредактировал(а) Alchimik - 26.6.2011, 07:15

конечно разные строчки... :( это я что-то навертел в своём коде.. Да и по логике такое не должно быть.. В общем, тему можно закрыть..

Суть простая, заставить всех перерегистрироваться. И полезно для сайта, и для заявить о себе. Да и полезно для парольной безопасности, типа чтоб все хоть раз пароли обновили..

Конечно можно отдельный модуль написать чтоб воспринимал старые пароли с последующей конвертацией их в новые, но скорее всего это лишь трата времени 

так у вас пароли на сайте не на латинице?

ps: мне бы совсем не понравилось, еслиб меня ни с того, ни с сего заставили регестрироваться заново...

Это сообщение отредактировал(а) Alchimik - 26.6.2011, 08:51

Добрался до рабочей станции. Alchimik правильно подметил - в примере строка $aaa будет равная $aa т.к. именно ее и конвертируете. Но для успешности эксперимента строка $aaa должна после конвертации стать равной $bb. 

По поводу того как теперь быть, я настоятельно не рекомендую вынуждать людей проходить повторную регистрацию - пример который я привел не вынуждает Вас писать целый модуль. Надо добавить одно поле в таблицу и написать порядка с десятка строк, чтоб все работало. После этого людей надо будет вынудить не регистрироваться заново, а просто авторизоваться (под предлогом того, что они давно не заходили на сайт). Согласитесь - войти и авторизоваться не так хлопотно как заново проходить регистрацию.

Добавлено через 8 минут и 8 секунд
Еще раз привожу алгоритм.

1. Проверяем соответствие нового пароля в utf. (этот кусок кода по идее уже есть - это авторизация по умолчанию). Если результат успешен, то все отлично, если же пароль не подошел мы вместо того, чтоб сразу переходить к пункту 3, делаем пункт 2.
2. Проверяем соответствие старого пароля. Если он подошел, то хешируем исходник в utf и сохраняем как новый пароль, почистив старый. Если же и старый пароль не подошел то переходим к пункту 3.
3. Оба пароля не подошли => пользователь ввел что-то не то.

Пункту 1 и 3 у Вас уже есть, Вам просто на время надо втиснуть между ними пункт 2.