Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В. MySQL на примерах. Авторы: Кузнецов М.В., Симдянов И.В. Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Разное

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Взлом. Подбор пароля.
 
 автор: а-я   (14.07.2008 в 04:41)   письмо автору
 
 

вот такая идея в голове.
Если я возьму какую нить кодировку. допустим китайский.
напишу "qwerty", при вкл. китайской кодировке/ и сохранить такой пароль на сайте.
будут ли проблемы?

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

   
 
 автор: MAR_NIKOZA   (14.07.2008 в 05:49)   письмо автору
 
   для: а-я   (14.07.2008 в 04:41)
 

чё?
:-/

   
 
 автор: sim5   (14.07.2008 в 05:54)   письмо автору
 
   для: а-я   (14.07.2008 в 04:41)
 

А что, если вы включаете поддержку китайского, переключаете клавиатуру на ввод китайского, то вместо кода символа будут иероглифы?

   
 
 автор: а-я   (14.07.2008 в 06:29)   письмо автору
 
   для: sim5   (14.07.2008 в 05:54)
 

что я вас не понял.
Ну вот например, в казахском языке есть специфические буквы (ӘҢҒ и т.д.).
Вот. Ставим их в пароль (например, на мыло)
И все. В БД пароли в основном хранят в виде ХЭШа

Ведь программы подбора не используют эти буквы.
Или как они работают?

   
 
 автор: sim5   (14.07.2008 в 06:35)   письмо автору
 
   для: а-я   (14.07.2008 в 06:29)
 

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

   
 
 автор: а-я   (14.07.2008 в 07:26)   письмо автору
 
   для: sim5   (14.07.2008 в 06:35)
 

хммм... теперь ясно) значит от подбора только админ сайта сможет бороться.
типа банить анкету на несколько минут и т.д.

   
 
 автор: а-я   (14.07.2008 в 06:30)   письмо автору
 
   для: sim5   (14.07.2008 в 05:54)
 

-

   
 
 автор: Loki   (14.07.2008 в 09:45)   письмо автору
 
   для: а-я   (14.07.2008 в 04:41)
 

а вводить вы его только со своего компьютера будете? а если вам понадобится залогиниться с работы (интернет-кафе, мобильного, pda и пр)?

   
 
 автор: MAR_NIKOZA   (14.07.2008 в 10:29)   письмо автору
 
   для: Loki   (14.07.2008 в 09:45)
 

Компьютер будет исходить из установленой кодовой страницы. так что хоть нанайский язык используй, но ASCII линейка будет 256 бит. И нанайская буква ЗЮ станет русской буквой Х.

Если рассчитываешь, что программа обрабатывающая пароли будет специально использовать юникод-функции, тогда конечно твоя идея сработает. Но какой смысл?

Да конечно,каждый символ тогда будет иметь 65365 вариантов, НО: Каждый символ всё равно будет описан двумя байтами! Никакого выигрыша не получится.

   
 
 автор: Loki   (14.07.2008 в 11:21)   письмо автору
 
   для: MAR_NIKOZA   (14.07.2008 в 10:29)
 

>Если рассчитываешь, что программа обрабатывающая пароли будет специально использовать юникод-функции
А вы не используете юникод? Пора... пора переходить в 21 век...

>Никакого выигрыша не получится.
Поясните на примере, а то мне как-то не очень понятно...

   
 
 автор: MAR_NIKOZA   (14.07.2008 в 13:02)   письмо автору
 
   для: Loki   (14.07.2008 в 11:21)
 

1 - В системных программах я не использую юникод обычно.
Буфер для него длиннее в 2 раза нужен, обязательно подключать
стороннюю либу юникода (в MASM её нету) увеличивать код, всё такое прочее...

2 - Я так понял, что автор топика рассчитывал одним байтом выразить символ юникода, чтобы усложнить пароль. Так это не прокатит, WORD нужен. В чём ещё смысл топика...

   
 
 автор: Loki   (14.07.2008 в 15:42)   письмо автору
 
   для: MAR_NIKOZA   (14.07.2008 в 13:02)
 

>2 - Я так понял, что автор топика рассчитывал одним байтом выразить символ юникода,

О... это был бы номер:)

   
 
 автор: а-я   (14.07.2008 в 17:39)   письмо автору
 
   для: MAR_NIKOZA   (14.07.2008 в 10:29)
 

>Компьютер будет исходить из установленой кодовой страницы. так что хоть нанайский язык используй, но ASCII линейка будет 256 бит. И нанайская буква ЗЮ станет русской буквой Х.
>
>Если рассчитываешь, что программа обрабатывающая пароли будет специально использовать юникод-функции, тогда конечно твоя идея сработает. Но какой смысл?
>
> Да конечно,каждый символ тогда будет иметь 65365 вариантов, НО: Каждый символ всё равно будет описан двумя байтами! Никакого выигрыша не получится.

Ну. я давно использую юникод UTF-8/ т.к. сайт начинал работу с мобильной версии.
и разве там всего 2 байта? там вроде от 2 до 6 байтов.
или я ошибаюсь?

   
 
 автор: Eugene77   (14.07.2008 в 18:41)   письмо автору
 
   для: а-я   (14.07.2008 в 04:41)
 

Да. Подобрать даже короткий (по числу символов) пароль в UTF-8 труднее.
Но это надо чтобы сама страница имела кодировку UTF-8.
Иначе преключение раскладки клавиатуры эффекта не даст.

Я лично этим пользуюсь. У меня регистрационные страницы cтрого в UTF-8.

Решение хоть и не радикальное, но у взломщиков тоже лень есть...

   
 
 автор: а-я   (14.07.2008 в 20:49)   письмо автору
 
   для: Eugene77   (14.07.2008 в 18:41)
 

>Да. Подобрать даже короткий (по числу символов) пароль в UTF-8 труднее.
>Но это надо чтобы сама страница имела кодировку UTF-8.
>Иначе преключение раскладки клавиатуры эффекта не даст.
- Да, страничка в утф8.


>Решение хоть и не радикальное, но у взломщиков тоже лень есть...

Жесть))

   
 
 автор: MAR_NIKOZA   (14.07.2008 в 22:01)   письмо автору
 
   для: а-я   (14.07.2008 в 20:49)
 

to: а-я

>Ну. я давно использую юникод UTF-8/ т.к. сайт начинал работу с мобильной версии.
и разве там всего 2 байта? там вроде от 2 до 6 байтов.
или я ошибаюсь?

Юникод выражается двумя байтами. (Можно теоретически выразить 65635 символов)

ПУСК \ все программы \ стандартные \ служебные \ таблица символов
Тут прячется Юникод

   
 
 автор: BinLaden   (14.07.2008 в 22:28)   письмо автору
 
   для: MAR_NIKOZA   (14.07.2008 в 22:01)
 

> Можно теоретически выразить 65635 символов

Их практически в Unicode уже около 100000. Следовательно, два байта тут уже не в теме:)

   
 
 автор: MAR_NIKOZA   (14.07.2008 в 23:59)   письмо автору
 
   для: BinLaden   (14.07.2008 в 22:28)
 

Юникод - всегда 2 байта.

UTF-16 и его 655365 вариантов кодируют 100.000 символов и более.
Дело в том что диапазон от UD800 до UDFFF содержит вспомогательные символы связки

Также имеет значение сложение частей. (Умляуты, тильды, и т.д.)
например въетнамская ХРЮ со своей дугой и тильдой
пишется как U006f + U0302 + U0303

   
 
 автор: Loki   (15.07.2008 в 09:30)   письмо автору
 
   для: MAR_NIKOZA   (14.07.2008 в 23:59)
 

>Юникод - всегда 2 байта.

Не всегда. UTF-8 имеет переменный размер символа. (1-6 байтов)
UTF-16 - 2 байта
UTF-32 - 4 байта

   
 
 автор: Trianon   (15.07.2008 в 10:11)   письмо автору
 
   для: BinLaden   (14.07.2008 в 22:28)
 

Справедливости ради стоит упомянуть, что диапазоны символов современных языков за 16-битовую границу не выходят. Или я неправ?

   
 
 автор: BinLaden   (16.07.2008 в 10:06)   письмо автору
 
   для: Trianon   (15.07.2008 в 10:11)
 

Не знаю, не знаю...

http://en.wikipedia.org/wiki/Unicode: "Unicode now includes more than 70,000 Han characters". Это уже означает, что в 16 бит не уложиться.

   
 
 автор: BinLaden   (16.07.2008 в 18:29)   письмо автору
 
   для: Trianon   (15.07.2008 в 10:11)
 

> современных

Не знаю:)

   
 
 автор: Trianon   (16.07.2008 в 19:31)   письмо автору
 
   для: BinLaden   (16.07.2008 в 18:29)
 

Базовая плоскость Unicode

   
 
 автор: BinLaden   (16.07.2008 в 22:24)   письмо автору
 
   для: Trianon   (16.07.2008 в 19:31)
 

Вы меня убедили:)

   
 
 автор: а-я   (16.07.2008 в 22:59)   письмо автору
 
   для: Trianon   (16.07.2008 в 19:31)
 

=) от темы совсем отошли. Но раз спор зашел.
Тогда меня интересует почему такое пишут в руководствах?


MYSQL:
1.
 Корейские, китайские и японские иероглифы использует трехбайтовые последовательности.

2.
 RFC 3629 описывает последовательности кодирования, 
которые берут от одного до четырех байтов. 
В настоящее время MySQL-поддержка для UTF-8 не включает последовательности 
с четырьмя байтами. 
Старый стандарт для кодирования UTF-8 задан RFC 2279 и 
описывает UTF-8-последовательности, которые берут от одного до шести байтов. 
RFC 3629 объявляет RFC 2279 устаревшим, по этой причине последовательности 
с пятью и шестью байтами больше не используются.

3.
 MySQL не поддерживает дополнительные символы, то есть символы, 
которые нуждаются больше, чем в 3 байтах для UTF-8. 
Пакет поддерживает только Basic Multilingual Plane/Plane 0 . 
Только несколько очень редких символов Han дополнительны; 
поддержка для них необыкновенна. Это привело к отчетам типа найденного в Глюке #12600, 
который авторы отклонили как не ошибка. С utf8 мы должны усечь входную строку, 
когда сталкиваемся с байтами, которые не понимаем. Иначе мы не знали бы, 
какой длины многобайтовый символ.


и что означет Maxlen ?

SHOW CHARACTER SET LIKE 'utf%';
Charset      Description            Default collation      Maxlen 
utf8              UTF-8 Unicode     utf8_general_ci       3


может глупые вопросы. но я еще учусь)

   
 
 автор: Trianon   (17.07.2008 в 00:23)   письмо автору
 
   для: а-я   (16.07.2008 в 22:59)
 

>=) от темы совсем отошли. Но раз спор зашел.
>Тогда меня интересует почему такое пишут в руководствах?

Какое - такое? Ничего противоречивого не заметил.

   
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования