Почему до сих пор браузеры обеспечиваются широким набором различных кодировок
Данная статья имеет цель собрать воедино и разобрать принципы и механизм работы кодировок текста, подробно этот механизм разобрать и объяснить. Полезна она будет тем, кто только примерно представляет, что такое кодировки текста и как они работают, чем отличаются друг от друга, почему иногда появляются не читаемые символы, какой принцип кодирования имеют разные кодировки.
Чтобы получить детальное понимание этого вопроса придется прочитать и свести воедино не одну статью и потратить довольно значительное время на это. В данном материале же это все собрано воедино и по идее должно сэкономить время и разбор на мой взгляд получился довольно подробный.
О чем будет под катом: принцип работы одно байтовых кодировок (ASCII, Windows-1251 и т.д.), предпосылки появления Unicode, что такое Unicode, Unicode-кодировки UTF-8, UTF-16, их отличия, принципиальные особенности, совместимость и несовместимость разных кодировок, принципы кодирования символов, практический разбор кодирования и декодирования.
Вопрос с кодировками сейчас конечно уже потерял актуальность, но все же знать как они работают сейчас и как работали раньше и при этом не потратить много времени на это думаю лишним не будет.
Предпосылки Unicode
Первые 7 бит (128 символов 2 7 =128) в этой кодировке были отданы под символы латинского алфавита, управляющие символы (такие как переносы строк, табуляция и т.д.) и грамматические символы. Остальные отводились под национальные языки. То есть получилось что первые 128 символов всегда одинаковые, а если хочешь закодировать свой родной язык пожалуйста, используй оставшуюся емкость. Собственно так и появился огромный зоопарк национальных кодировок. И теперь сами можете представить, вот например я находясь в России беру и создаю текстовый документ, у меня по умолчанию он создается в кодировке Windows-1251 (русская кодировка использующаяся в ОС Windows) и отсылаю его кому то, например в США. Даже то что мой собеседник знает русский язык, ему не поможет, потому что открыв мой документ на своем компьютере (в редакторе с дефолтной кодировкой той же самой ASCII) он увидит не русские буквы, а кракозябры. Если быть точнее, то те места в документе которые я напишу на английском отобразятся без проблем, потому что первые 128 символов кодировок Windows-1251 и ASCII одинаковые, но вот там где я написал русский текст, если он в своем редакторе не укажет правильную кодировку будут в виде кракозябр.
Думаю проблема с национальными кодировками понятна. Собственно этих национальных кодировок стало очень много, а интернет стал очень широким, и в нем каждый хотел писать на своем языке и не хотел чтобы его язык выглядел как кракозябры. Было два выхода, указывать для каждой страницы кодировки, либо создать одну общую для всех символов в мире таблицу символов. Победил второй вариант, так создали Unicode таблицу символов.
Небольшой практикум ASCII
Возможно покажется элементарщиной, но раз уж решил объяснять все и подробно, то это надо.
Вот таблица символов ASCII:
Тут имеем 3 колонки:
- номер символа в десятичном формате
- номер символа в шестнадцатиричном формате
- представление самого символа.
Unicode
С предпосылками создания общей таблицы для всех в мире символов, разобрались. Теперь собственно, к самой таблице. Unicode — именно эта таблица и есть (это не кодировка, а именно таблица символов). Она состоит из 1 114 112 позиций. Большинство этих позиций пока не заполнены символами, так что вряд ли понадобится это пространство расширять.
Разделено это общее пространство на 17 блоков, по 65 536 символов в каждом. Каждый блок содержит свою группу символов. Нулевой блок — базовый, там собраны наиболее употребляемые символы всех современных алфавитов. Во втором блоке находятся символы вымерших языков. Есть два блока отведенные под частное использование. Большинство блоков пока не заполнены.
Итого емкость символов юникода составляет от 0 до 10FFFF (в шестнадцатиричном виде).
Записываются символы в шестнадцатиричном виде с приставкой «U+». Например первый базовый блок включает в себя символы от U+0000 до U+FFFF (от 0 до 65 535), а последний семнадцатый блок от U+100000 до U+10FFFF (от 1 048 576 до 1 114 111).
Отлично теперь вместо зоопарка национальных кодировок, у нас есть всеобъемлющая таблица, в которой зашифрованы все символы которые нам могут пригодиться. Но тут тоже есть свои недостатки. Если раньше каждый символ был закодирован одним байтом, то теперь он может быть закодирован разным количеством байтов. Например для кодирования всех символов английского алфавита по прежнему достаточно одного байта например тот же символ «o» (англ.) имеет в юникоде номер U+006F, то есть тот же самый номер как и в ASCII — 6F в шестнадцатиричной и 111 в десятеричной. А вот для кодирования символа "U+103D5" (это древнеперсидская цифра сто) — 103D5 в шестнадцатиричной и 66 517 в десятеричной, тут нам потребуется уже три байта.
Решить эту проблему уже должны юникод-кодировки, такие как UTF-8 и UTF-16. Далее речь пойдет про них.
UTF-8 является юникод-кодировкой переменной длинны, с помощью которой можно представить любой символ юникода.
Давайте поподробнее про переменную длину, что это значит? Первым делом надо сказать, что структурной (атомарной) единицей этой кодировки является байт. То что кодировка переменной длинны, значит, что один символ может быть закодирован разным количеством структурных единиц кодировки, то есть разным количеством байтов. Так например латиница кодируется одним байтом, а кириллица двумя байтами.
Немного отступлю от темы, надо написать про совместимость ASCII и UTF
То что латинские символы и основные управляющие конструкции, такие как переносы строк, табуляции и т.д. закодированы одним байтом делает utf-кодировки совместимыми с кодировками ASCII. То есть фактически латиница и управляющие конструкции находятся на тех же самых местах как в ASCII, так и в UTF, и то что закодированы они и там и там одним байтом и обеспечивает эту совместимость.
Давайте возьмем символ «o»(англ.) из примера про ASCII выше. Помним что в таблице ASCII символов он находится на 111 позиции, в битовом виде это будет 01101111 . В таблице юникода этот символ — U+006F что в битовом виде тоже будет 01101111 . И теперь так, как UTF — это кодировка переменной длины, то в ней этот символ будет закодирован одним байтом. То есть представление данного символа в обеих кодировках будет одинаково. И так для всего диапазона символов от 0 до 128. То есть если ваш документ состоит из английского текста то вы не заметите разницы если откроете его и в кодировке UTF-8 и UTF-16 и ASCII (прим. в UTF-16 такие символы все равно будут закодированы двумя байтами, по этому вы не увидите разницы, если ваш редактор будет игнорировать нулевые байты), и так до момента пока вы не начнете работать с национальным алфавитом.
Сравним на практике как будет выглядеть фраза «Hello мир» в трех разных кодировках: Windows-1251 (русская кодировка), ISO-8859-1 (кодировка западно-европейских языков), UTF-8 (юникод-кодировка). Суть данного примера состоит в том что фраза написана на двух языках. Посмотрим как она будет выглядеть в разных кодировках.
В кодировке ISO-8859-1 нет таких символов «м», «и» и «р».
Теперь давайте поработаем с кодировками и разберемся как преобразовать строку из одной кодировки в другую и что будет если преобразование неправильное, или его нельзя осуществить из за разницы в кодировках.
Будем считать что изначально фраза была записана в кодировке Windows-1251. Исходя из таблицы выше запишем эту фразу в двоичном виде, в кодировке Windows-1251. Для этого нам потребуется всего только перевести из десятеричной или шестнадцатиричной системы (из таблицы выше) символы в двоичную.
01001000 01100101 01101100 01101100 01101111 00100000 11101100 11101000 11110000
Отлично, вот это и есть фраза «Hello мир» в кодировке Windows-1251.
Теперь представим что вы имеете файл с текстом, но не знаете в какой кодировке этот текст. Вы предполагаете что он в кодировке ISO-8859-1 и открываете его в своем редакторе в этой кодировке. Как сказано выше с частью символов все в порядке, они есть в этой кодировке, и даже находятся на тех же местах, но вот с символами из слова «мир» все сложнее. Этих символов в этой кодировке нет, а на их местах в кодировке ISO-8859-1 находятся совершенно другие символы. А конкретно «м» — позиция 236, «и» — 232. «р» — 240. И на этих позициях в кодировке ISO-8859-1 находятся следующие символы позиция 236 — символ "ì", 232 — "è", 240 — "ð"
Значит фраза «Hello мир» закодированная в Windows-1251 и открытая в кодировке ISO-8859-1 будет выглядеть так: «Hello ìèð». Вот и получается что эти две кодировки совместимы лишь частично, и корректно перекодировать строку из одной кодировке в другую не получится, потому что там просто напросто нет таких символов.
Тут и будут необходимы юникод-кодировки, а конкретно в данном случае рассмотрим UTF-8. То что символы в ней могут быть закодированы разным количеством байтов от 1 до 4 мы уже выяснили. Теперь стоит сказать что с помощью UTF могут быть закодированы не только 256 символов, как в двух предыдущих, а вобще все символы юникода
Работает она следующим образом. Первый бит каждого байта кодирующего символ отвечает не за сам символ, а за определение байта. То есть например если ведущий (первый) бит нулевой, то это значит что для кодирования символа используется всего один байт. Что и обеспечивает совместимость с ASCII. Если внимательно посмотрите на таблицу символов ASCII то увидите что первые 128 символов (английский алфавит, управляющие символы и знаки препинания) если их привести к двоичному виду, все начинаются с нулевого бита (будьте внимательны, если будете переводить символы в двоичную систему с помощью например онлайн конвертера, то первый нулевой ведущий бит может быть отброшен, что может сбить с толку).
01001000 — первый бит ноль, значит 1 байт кодирует 1 символ -> «H»
01100101 — первый бит ноль, значит 1 байт кодирует 1 символ -> «e»
Если первый бит не нулевой то символ кодируется несколькими байтами.
Для двухбайтовых символов первые три бита должны быть такие — 110
110 10000 10 111100 — в начале 110, значит 2 байта кодируют 1 символ. Второй байт в таком случае всегда начинается с 10. Итого отбрасываем управляющие биты (начальные, которые выделены красным и зеленым) и берем все оставшиеся ( 10000111100 ), переводим их в шестнадцатиричный вид (043С) -> U+043C в юникоде равно символ «м».
для трех-байтовых символов в первом байте ведущие биты — 1110
1110 1000 10 000111 10 1010101 — суммируем все кроме управляющих битов и получаем что в 16-ричной равно 103В5, U+103D5 — древнеперситдская цифра сто ( 10000001111010101 )
для четырех-байтовых символов в первом байте ведущие биты — 11110
11110 100 10 001111 10 111111 10 111111 — U+10FFFF это последний допустимый символ в таблице юникода ( 100001111111111111111 )
Теперь, при желании, можем записать нашу фразу в кодировке UTF-8.
UTF-16
UTF-16 также является кодировкой переменной длинны. Главное ее отличие от UTF-8 состоит в том что структурной единицей в ней является не один а два байта. То есть в кодировке UTF-16 любой символ юникода может быть закодирован либо двумя, либо четырьмя байтами. Давайте для понятности в дальнейшем пару таких байтов я буду называть кодовой парой. Исходя из этого любой символ юникода в кодировке UTF-16 может быть закодирован либо одной кодовой парой, либо двумя.
Начнем с символов которые кодируются одной кодовой парой. Легко посчитать что таких символов может быть 65 535 (2в16), что полностью совпадает с базовым блоком юникода. Все символы находящиеся в этом блоке юникода в кодировке UTF-16 будут закодированы одной кодовой парой (двумя байтами), тут все просто.
символ «o» (латиница) — 00000000 01101111
символ «M» (кириллица) — 00000100 00011100
Теперь рассмотрим символы за пределами базового юникод диапазона. Для их кодирования потребуется уже две кодовые пары (4 байта). И механизм их кодирования немного сложнее, давайте по порядку.
Для начала введем понятия суррогатной пары. Суррогатная пара — это две кодовые пары используемые для кодирования одного символа (итого 4 байта). Для таких суррогатных пар в таблице юникода отведен специальный диапазон от D800 до DFFF. Это значит, что при преобразовании кодовой пары из байтового вида в шестнадцатиричный вы получаете число из этого диапазона, то перед вами не самостоятельный символ, а суррогатная пара.
Чтобы закодировать символ из диапазона 10000 — 10FFFF (то есть символ для которого нужно использовать более одной кодовой пары) нужно:
- из кода символа вычесть 10000(шестнадцатиричное) (это наименьшее число из диапазона 10000 — 10FFFF)
- в результате первого пункта будет получено число не больше FFFFF, занимающее до 20 бит
- ведущие 10 бит из полученного числа суммируются с D800 (начало диапазона суррогатных пар в юникоде)
- следующие 10 бит суммируются с DC00 (тоже число из диапазона суррогатных пар)
- после этого получатся 2 суррогатные пары по 16 бит, первые 6 бит в каждой такой паре отвечают за определение того что это суррогат,
- десятый бит в каждом суррогате отвечает за его порядок если это 1 то это первый суррогат, если 0, то второй
Для примера зашифруем символ, а потом расшифруем. Возьмем древнеперсидскую цифру сто (U+103D5):
- 103D5 — 10000 = 3D5
- 3D5 = 0000000000 1111010101 (ведущие 10 бит получились нулевые приведем это к шестнадцатиричному числу, получим 0 (первые десять), 3D5 (вторые десять))
- 0 + D800 = D800 ( 110110 0 000000000 ) первые 6 бит определяют что число из диапазона суррогатных пар десятый бит (справа) нулевой, значит это первый суррогат
- 3D5 + DC00 = DFD5 ( 110111 1 111010101 ) первые 6 бит определяют что число из диапазона суррогатных пар десятый бит (справа) единица, значит это второй суррогат
- итого данный символ в UTF-16 — 1101100000000000 1101111111010101
- переведем в шестнадцатиричный вид = D822DE88 (оба значения из диапазона суррогатных пар, значит перед нами суррогатная пара)
- 110110 0 000100010 — десятый бит (справа) нулевой, значит первый суррогат
- 110111 1 010001000 — десятый бит (справа) единица, значит второй суррогат
- отбрасываем по 6 бит отвечающих за определение суррогата, получим 0000100010 1010001000 (8A88)
- прибавляем 10000 (меньшее число суррогатного диапазона) 8A88 + 10000 = 18A88
- смотрим в таблице юникода символ U+18A88 = Tangut Component-649. Компоненты тангутского письма.
Кодировка представляет собой таблицу символов, где каждой букве алфавита (а также цифрам и специальным знакам) присвоен свой уникальный номер - код символа.
Стандартизирована только половина таблицы, т.н. ASCII-код - первые 128 символов, которые включают в себя буквы латинского алфавита. И с ними никогда не бывает проблем. Вторая же половина таблицы (а всего в ней 256 символов - по количеству состояний, который может принять один байт) отдана под национальные символы, и в каждой стране эта часть различна. Но только в России умудрились придумать целых 5 различных кодировок. Термин "различные" обозначает то, что одному и тому же символу соответствует разный цифровой код. Т.е. если мы неправильно определим кодировку текста, то нашему вниманию предстанет абсолютно нечитаемый текст.
Кодировки появились исторически. Первая широко используемая российская кодировка называлась KOI-8. Ее придумали, когда адаптировали к русскому языку систему UNIX. Это было еще в семидесятых - до появления персоналок. И до сих пор в UNIX это считается основной кодировкой.
Потом появились первые персональные компьютеры, и началось победное шествие DOS. Вместо того чтобы воспользоваться уже придуманной кодировкой, Microsoft решила сделать свою, ни с чем не совместимую. Так появилась DOS-кодировка (или 866 кодовая страница). В ней, кстати, были введены спецсимволы для рисования рамок, что широко использовалось в программах написанных под DOS. Например, в том же Norton Commander-е.
Параллельно с IBM-совместимыми развивались и Macintosh-компьютеры. Несмотря на то, что их доля в России очень мала, тем не менее, потребность в русификации существовала и, разумеется, была придумана еще одна кодировка - MAC.
Время шло, и 1990 году Microsoft явила на свет первую успешную версию Windows 3.0-3.11. А вместе с ней и поддержку национальных языков. И снова был проделан такой же фокус, как и с DOS. По непонятным причинам они не поддержали ни одну, из уже существовавших ранее (как это сделала OS/2, принявшая за стандарт DOS-кодировку), а предложили новую Win-кодировку (или кодовая страница 1251). Де-факто, она стала самой распространенной в России.
И, наконец, пятый вариант кодировки связан уже не с конкретной фирмой, а с попытками стандартизации кодировок на уровне всей планеты. Занималась этим ISO - международная организация по стандартам. И, догадайтесь, что они сделали с русским языком? Вместо того, чтобы принять за "стандартную русскую" какую-нибудь из вышеописанных, они придумали еще одну (!) и назвали ее длинным неудобоваримым сочетанием . Разумеется, она тоже оказалась ни с чем не совместимой. И в настоящий момент эта кодировка практически нигде не применяется. Кажется, ее используют только в базе данных Oracle. По крайней мере, я ни разу не видел текст в этой кодировке. Тем не менее, ее поддержка присутствует во всех броузерах.
Сейчас идет работа над созданием новой универсальной кодировки (UNICODE), в которой предполагается в одну кодовую таблицу запихнуть все языки мира. Тогда точно проблем не будет. Для этого на каждый символ отвели 2 байта. Таким образом, максимальное количество знаков в таблице расширилось до 65535. Но до момента, когда все перейдут на UNICODE, остается еще слишком много времени.
Web-дизайн и кодировки
А теперь о том, как все эти кодировки связаны с web-дизайном. Проблема заключается как в web-серверах, так и в броузерах. Обе составляющие должны общаться на одном языке и в одной кодировке, и только в этом случае броузер будет понимать то, что ему посылает сервер.
Имеется способ указать кодировку странички не на сервере, а непосредственно в HTML-коде. Для этого используется специальная версия META-тега с параметром charset, задающим нужный язык. Например, для странички написанной в кодировке Win1251, соответствующий код будет выглядеть так:
Но, к сожалению, с этим тегом связано несколько проблем. В России очень распространен способ, при котором web-сервер автоматически определяет, в какой кодировке приходит запрос от клиента и отдает страничку web-броузеру уже перекодированной. Вот тут нас и поджидает небольшой подводный камень. META-тег может сыграть плохую шутку. Дело в том, что указания на страничке имеют приоритет по сравнению с командами, присылаемыми web-сервером и правильно перекодировав страничку, сервер, тем не менее, не может изменить содержимое тега META. Происходит несовпадение реальной кодировки, в которой пришла страничка, и указаниями в теге META. Такую страничку нельзя будет нормально просмотреть и перекодировать средствами броузера. Выбор кодировки вручную в данном случае не поможет, т.к. тег META имеет приоритет и над установками броузера. Единственный способ сделать это - сохранить страничку и удалить злосчастный тег.
В связи со всеми этими проблемами в РУНЕТ-е не рекомендуется применять данный тег вообще. В таком случае просмотр будет осуществляться в той кодировке, на которую настроен броузер, если сервер не пришлет уведомление о кодировке документа. В случае несовпадения ее можно достаточно легко переключить. Кроме того, если по умолчанию выставлять кодировку Win-1251, то у 95% Ваших посетителей страничка сразу же будет показана правильно.
Проблемы с таблицами стилей
В последнее время в связи с широким распространением DHTML, CSS и 4-х версий броузеров возникла новая проблема, связанная с кодировками. И причиной ее появления служит использование каскадных таблиц стилей (CSS).
Как известно, CSS позволяет нам задать конкретный шрифт, который будет использоваться для отображения текста. И вроде бы, мы можем пользоваться абсолютно любым шрифтом, и от этого захватывает дух. Но проблема заключается в том, что шрифты берутся из набора, установленного на компьютере у посетителя, а вовсе не у Вас. И именно Ваш набор шрифтов совершенно не обязан быть у других. Как правило, его там и нет.
Что же делать? Неужели нельзя пользоваться разными шрифтами? Можно! Но с рядом ограничением и пониманием того факта, что даже при этих ограничениях у некоторых людей Ваша страничка не будет просматриваться.
Каковы же эти ограничения?
Первое и основное заключается в том, чтобы использовать только стандартные шрифты, поставляемые с Windows и гарантированно находящиеся на машине клиента. А этих шрифтов, как известно всего три. Вот их список: "Arial", "Times New Roman", "Courier".
А второе - корректное описание шрифта в таблице стилей и перечисление в списке также и других заменяющих шрифтов. В конце списка должно быть обязательное указание общего семейства шрифта (с засечками, без засечек, моноширинный и т.д.). При помощи такого описания мы увеличиваем потенциальную аудиторию нашего сайта. Пример корректного описания шрифтов в таблице стилей показан ниже.
Почему же нельзя использовать другие шрифты? Потому что в этом случае недостающий шрифт будет подменен ближайшим подходящим по умолчанию. Для уменьшения вероятности этого мы и используем в CSS список заменяющих шрифтов. Но еще хуже, если шрифт будет на компьютере, но окажется нерусифицированной версией. В этом случае текст будет отображен некими спецсимволами из набора знаков центральной Европы - всевозможные знаки с умляутами, апострофами, тильдами и т.п.
Из всего вышесказанного следует вывод - со шрифтами следует работать осторожно. И до сих пор много чисто текстовых надписей отливается в GIF. Ситуация не изменится до тех пор, пока шрифт нельзя будет загружать на клиентскую машину, подобно тому, как это происходит с картинкой. На самом деле, такая технология уже есть и реализована, например, в 4-ом Internet Explorer. Но она еще слишком сыра и, что самое главное, шрифт должен быть представлен в специальном формате. Будем надеяться, что в будущем это станет стандартом, а пока нужно с осторожностью пользоваться шрифтами, отливая редкие в графику и используя в CSS только стандартные.
Цель работы. Целью работы является изучение характеристик парольных систем защиты, приобретение и закрепление на практике навыков по определению стойкости парольных систем, а также получение практических навыков по работе с парольными системами.
Порядок выполнения работы.
1. Изучить теоретическую часть
2. Выполнить задания в соответствии с заданным вариантом и отразить результате в отчете
3. Представить отчет на проверку преподавателю. Отчет должен содержать номера пунктов работы, их наименование и (в правой колонке) результат выполнения каждого пункта.
Теоретическая часть
Вопросы защиты информации в компьютерных системах стояли на протяжении всей истории развития компьютерной техники. Особое значение они приобрели с превращением компьютера в личное средство связи и развитием компьютерных сетей. Доступ к любой информации в компьютерной системе и информации в ней может быть:
· санкционированным (официально разрешенным);
Под несанкционированным доступом к информации (НСД) согласно руководящим документам Гостехкомиссии (Федеральной службы по техническому и экспортному контролю) принято понимать доступ к информации, нарушающий установленные правила разграничения доступа и осуществляемый с использованием штатных средств, предоставляемых средствами вычислительной техники или автоматизированной системой (АС).
НСД может носить случайный или намеренный характер. Можно выделить несколько обобщенных категорий методов защиты от НСД, в частности:
В данной работе основное внимание уделено именно технологическому методу защиты, а конкретнее – защите на основе паролей, которая является наиболее распространенным видом защиты компьютерной информации. При реализации парольной защиты вход в систему, запуск приложения, запрос на доступ к данным и т.д. сопровождается запросом пароля и последующей его проверкой на достоверность.
Пароль пользователя - некоторое секретное количество информации (слово), известное только пользователю и парольной системе. Пароль представляет собой последовательность символов некоторого алфавита и специальных знаков. Последовательность должна удовлетворять определенным требованиям, некоторые из которых являются предметом изучения в данной работе.
Под парольной системой принято понимать программно-аппаратный комплекс, реализующий процедуру идентификации пользователей в компьютерной системе на основе одноразовых или многоразовых паролей. Обычно такой комплекс интегрирован с подсистемами разграничения доступа и регистрации событий.
Парольная система защиты является основным и наиболее часто используемым средством защиты персональной информации в различных компьютерных системах и сетях и, именно поэтому, от стойкости парольной системы защиты зависит обеспечение конфиденциальности информации пользователя.
Критерии стойкости пароля:
· пароль не должен быть коротким, поскольку это упрощает его подбор. Рекомендуемая минимальная длина - восемь символов;
· пароль не должен быть словарным словом или простым их сочетанием, это упрощает его подбор по словарю;
· пароль не должен состоять только из общедоступной информации о пользователе (имя, фамилия, год рождения, имена и года рождения родственников и т.д.).
Существует множество реализаций парольных систем, в структуре которых можно выделить несколько наиболее важных компонентов:
· база учетных записей пользователей;
· модуль сопряжения с другими подсистемами безопасности.
Потенциальные угрозы, направленны на каждый из элементов парольной системы защиты, однако, основные важным аспектом является защита базы учетных записей, которая содержит идентификаторы пользователей (имена) и их пароли. Завладев и раскрыв эту базу, злоумышленник сможет зарегистрироваться в системе от имени любого пользователя и выполнить любые доступные данному пользователю действия.
В большинстве систем пользователи имеют возможность самостоятельно формировать пароли, хотя в некоторых они получают их от администраторов. При этом для увеличения надежности формируемых пользователями паролей в информационных системах реализуется ряд требований, среди которых выделим следующие:
1. Установление минимальной длины пароля (не менее заданного системой числа символов).
2. Использование в пароле различных групп символов.
3. Установление максимального срока действия пароля.
4. Ограничение числа попыток ввода пароля.
5. Поддержка режима принудительной смены пароля пользователя.
6. Использование задержки при вводе неправильного пароля.
7. Запрет на выбор пароля самими пользователями и автоматическая генерация паролей (для особо важных случаев).
8. Принудительная смена пароля при первой регистрации пользователя в системе.
А также ряд других, которые для пользователя порой даже не видны.
Злоумышленник может реализовывать угрозы парольной системы защиты в двух режимах – интерактивном, т.е. с применением штатных средств парольной системы (интерфейса пользователя), и неинтерактивном (например, он может применить программу для определения паролей в этой базе). Наиболее опасным является неинтерактивный вариант, т.к. злоумышленник может с большой скоростью «подбирать» пароли.
Для численной оценки параметров парольной системы защиты используются следующие показатели:
A - мощность алфавита паролей, т. е. то множество знаков, которое может применяться при вводе пароля.
L - длина пароля (в знаках). Может изменяться для обеспечения заданной стойкости парольной системы.
S - мощность пространства паролей, т. е. множество всех возможных паролей в системе.
Мощность пространства паролей связана с мощностью алфавита паролей и длиной паролей следующим выражением:
V - скорость подбора пароля (соответственно различают скорость подбора пароля для интерактивного (1-2 паролей / минуту) и неинтерактивного (10 и более паролей / секунду) подбора паролей).
T - срок действия (жизни) пароля (обычно задается в днях).
P - вероятность подбора пароля в течение срока его действия.
Вероятность подбора пароля можно определить следующим образом:
В конкретной ситуации задают некоторые желательные значения для одних параметров (например, очень маленькое значение вероятности подбора пароля) и высчитывают остальные параметры.
Очевидно, что с увеличением длины пароля и/или мощности алфавита паролей вероятность подбора пароля уменьшается. А при увеличении срока жизни пароля, вероятность его подбора увеличивается.
К сожалению, на практике, достаточно часто пользователи не задумываются над вопросом сложности задаваемого ими пароля. Интересные данные, подтверждающие этот факт, получены в результате исследования базы учетных записей одной отечественной социальной сети [1] и представлены в таблице 1.2.1.
Всего исследовано паролей | 83524 (100%) |
Доля паролей состоящих только из цифр | 20,8% |
Доля паролей состоящих только из букв | 46,3% |
Доля паролей состоящих только из букв и цифр | 32,9% |
Доля паролей состоящих только из русских букв | 18,6% |
Доля паролей состоящих из латинских букв | 21,1% |
Доля паролей состоящих русских и латинских букв | 6,6% |
До выполнения работы рассмотрим на примерах решения типовых задач, позволяющих получить важные для пользователя параметры используемого им пароля.
Пример 1.
Задание: определить время перебора всех паролей, состоящих из 6 цифр.
Решение:
Алфавит составляют цифры (A=10).
Длина пароля 6 символов (L=6).
Таким образом, получаем количество вариантов: S=A L =10 6 (паролей).
Примем скорость перебора паролей V=10 паролей/секунду.
Получаем время перебора всех паролей:
T = S / V = 10 5 секунд =~1667минут =~28часов =~1,2 дня.
Если после каждого из m=3 неправильно введённых паролей ввести паузу в v=5 секунд.
Получаем продолжительность всех пауз при переборе всех паролей:
Tпауза = (S * v) / m = (10 6 * 5) / 3 = 1666667 секунд =~27778 минут =~463 часа =~19,3 дня.
Титог = T + Tпауза = 1,2 + 19,3 = 20,5 дня
Таким образом, за счет введения пауз при неправильном вводе пароля можно существенно увеличить время интерактивного подбора пароля.
Пример 2.
Задание: Определить минимальную длину пароля, алфавит которого состоит из 10 символов, время перебора которого было бы не меньше 10 лет.
Решение:
Алфавит составляют символы A = 10.
Длина пароля рассчитывается: L = logA S = lg S.
Определим количество вариантов:
S = T * V = 10лет * 10паролей/сек. = 10 * 365 * 24 * 60 * 60 * 10 =~3,15 * 10 9 вариантов
Таким образом, получаем длину пароля:
L=lg (3,15*10 9 ) = 9,5
Следовательно, что длина пароля должна быть не менее 10 символов.
Практическая часть
Подготовка к работе.
· Создайте файл отчета в Word по образцу, приведённому в приложении 1, и заполните его шапку.
ПРИМЕЧАНИЕ. Ваша фамилия (с инициалами) должна являться именем файла отчета.
· Получите номер варианта из табл. 1.2.2 и занесите его в отчет. Далее все задания выполняются согласно номеру варианта.
1. Задание №1. В номерах многих отелей имеется сейф с доступом по паролю из четырех десятичных цифр. Предполагая, что скорость ручного перебора составляет четыре пароля в минуту и отсутствует задержка после ввода неправильного пароля определите время перебора всех возможных паролей.
2. Задание №2.
2.1. Скопируйте в файл отчёта данные Вашего варианта из таблицы 1.2.2 (строку).
2.2. Определите время перебора всех паролей (T 1 , T 2) со следующими параметрами:
· алфавит состоит из A символов;
· длина пароля символов L 1 и L2;
· скорость перебора V паролей в секунду.
После каждого из m неправильно введённых паролей идёт пауза в v секунд.
Ход решения занесите в отчет.
2.3. Занесите полученные данные в таблицу.
2.4. Сравните полученные в п. 2.2 результаты для L1 и L2 сделайте вывод. Оцените, как параметры m и v влияют на возможность подбора пароля.
2.5. Сделанный вывод и оценки занесите в отчёт.
Вариант | A | L 1 | L 2 | V | m | v | T 1(дней) | T 2(дней) |
1 | 10 | 6 | 3 | 10 | 3 | 5 | ||
2 | 2 | 6 | 3 | 10 | 3 | 5 | ||
3 | 8 | 6 | 3 | 10 | 3 | 5 | ||
4 | 16 | 6 | 3 | 10 | 3 | 5 | ||
5 | 10 | 4 | 6 | 10 | 3 | 5 | ||
6 | 2 | 4 | 6 | 10 | 3 | 5 | ||
7 | 8 | 4 | 6 | 10 | 3 | 5 | ||
8 | 16 | 4 | 6 | 10 | 3 | 5 | ||
9 | 2 | 3 | 6 | 1 | 5 | 3 | ||
10 | 8 | 3 | 6 | 1 | 5 | 3 | ||
11 | 10 | 3 | 6 | 1 | 5 | 3 | ||
12 | 16 | 3 | 6 | 1 | 5 | 3 | ||
13 | 100 | 3 | 6 | 1 | 5 | 3 | ||
14 | 20 | 4 | 6 | 1 | 4 | 3 | ||
15 | 30 | 4 | 6 | 1 | 4 | 3 | ||
16 | 50 | 3 | 6 | 1 | 4 | 3 | ||
17 | 10 | 2 | 4 | 1 | 3 | 4 | ||
18 | 20 | 2 | 4 | 1 | 3 | 4 | ||
19 | 30 | 2 | 4 | 1 | 3 | 4 | ||
20 | 40 | 2 | 4 | 1 | 3 | 4 | ||
21 | 10 | 4 | 2 | 1 | 1 | 1 | ||
22 | 10 | 4 | 6 | 1 | 3 | 1 | ||
23 | 30 | 4 | 6 | 1 | 3 | 1 | ||
24 | 40 | 4 | 6 | 2 | 1 | 3 | ||
25 | 10 | 8 | 4 | 2 | 1 | 3 | ||
26 | 10 | 6 | 3 | 10 | 3 | 5 | ||
27 | 2 | 6 | 3 | 10 | 3 | 5 | ||
28 | 8 | 6 | 3 | 10 | 3 | 5 | ||
29 | 16 | 6 | 3 | 10 | 3 | 5 | ||
30 | 10 | 4 | 6 | 10 | 3 | 5 |
3. Задание №3.
3.1. Скопируйте в файл отчёта данные Вашего варианта из таблицы 1.2 .3 (строку).
3.2. Определите минимальную длину пароля (L), алфавит которого состоит из A1 и A2 символов, время перебора которого было не меньше T лет.
Скорость перебора V паролей в секунду.
Ход решения занесите в отчет.
3.3. Сравните полученные в п. 3.2 результаты для A1 и A2 сделайте вывод. Сделанный вывод занесите в отчет.
Вариант | A 1 | A 2 | T (лет) | V | L 1 | L 2 |
1 | 10 | 5 | 1 | 10 | ||
2 | 8 | 4 | 1 | 10 | ||
3 | 10 | 4 | 1 | 10 | ||
4 | 10 | 2 | 1 | 10 | ||
5 | 8 | 2 | 1 | 10 | ||
6 | 16 | 8 | 2 | 10 | ||
7 | 16 | 4 | 2 | 10 | ||
8 | 16 | 10 | 2 | 10 | ||
9 | 10 | 8 | 2 | 10 | ||
10 | 5 | 10 | 3 | 2 | ||
11 | 4 | 8 | 1 | 2 | ||
12 | 4 | 10 | 2 | 2 | ||
13 | 2 | 10 | 3 | 2 | ||
14 | 2 | 8 | 2 | 2 | ||
15 | 8 | 10 | 1 | 2 | ||
16 | 8 | 16 | 1 | 2 | ||
17 | 4 | 16 | 2 | 2 | ||
18 | 20 | 2 | 1 | 2 | ||
19 | 30 | 4 | 1 | 2 | ||
20 | 10 | 30 | 1 | 2 | ||
21 | 10 | 16 | 1 | 1 | ||
22 | 10 | 2 | 1 | 2 | ||
23 | 20 | 4 | 2 | 10 | ||
24 | 8 | 16 | 2 | 4 | ||
25 | 4 | 8 | 3 | 10 | ||
26 | 10 | 5 | 1 | 10 | ||
27 | 8 | 4 | 1 | 10 | ||
28 | 10 | 4 | 1 | 10 | ||
29 | 10 | 2 | 1 | 10 | ||
30 | 8 | 2 | 1 | 10 |
4. Сохраните отчет и представьте оформленный отчет по выполненной работе преподавателю на проверку.
Контрольные вопросы
1. Что такое несанкционированный доступ?
2. Что такое парольная система и каковы ее основные компоненты?
3. Перечислите основные численные характеристики парольных систем защиты и их взаимосвязь между собой.
4. Какова зависимость между вероятностью подбора пароля и мощностью алфавита паролей при прочих равных характеристиках?
5. Перечислите особенности реализации парольных систем защиты, которые позволяют увеличить время подбора пароля методом тотального перебора.
6. Приведите примеры неудачных паролей и поясните, почему это так.
7. Как связаны мощность алфавита паролей и мощность пространства паролей?
Раздел 2 . Технические средства информационных систем
Цель работы: Изучить принципы представления в Интернет текстовой информации. Получить практические навыки кодирования и декодирования текстовой информации.
Порядок выполнения работы.
1. Изучить теоретическую часть
2. Выполнить задания в соответствии с заданным вариантом и отразить результате в отчете
3. Представить отчет на проверку преподавателю. Отчет должен содержать номера пунктов работы, краткое содержание задания в каждом пункте и (в правой колонке) результат выполнения каждого пункта.
Теоретическая часть
Широкое распространение компьютерных сетей стало возможным благодаря решению не только вопросов связи компьютеров, но и их информационной совместимости. На начальном этапе проблемы с совместимостью приводили к полному искажению текстов, и даже возник специальный термин: кракозя́бры (крякозя́бры) - бессмысленный набор символов (абракадабра), чаще всего получаемый на компьютере в результате неправильного перекодирования исходного текста.
Проблему «кракозябр» можно было решить либо внедрением методов указания используемой кодировки, либо внедрением единой (общей) для всех кодировки.
До сегодняшнего дня существуют разные стандарты для представления, символов, которые отличаются лишь порядком нумерации символов. На рис. 1.1.2. можно видеть набор кодировок браузера Explorer 11, которыми до сегодняшнего дня оснащается этот браузер.
Набор кодировок браузера Explorer 11
Долгое время наиболее распространённым был американский стандартный код для информационного обмена - ASCII [American Standard-Code for Information Interchange], который был введён в США еще в 1963г. В 1977 году в несколько модифицированном виде он был принят в качестве всемирного стандарта Международной организации стандартов (International Standards Organization -. ISO) под названием ISO-646. Согласно этому стандарту каждому символу поставлено в соответствие число от 0 до 255.
В ОС Linux для представления русских букв еще используется кодировка КОИ-8. Однако, она во-первых, не допускает одновременное представление русских и, например, французских букв. Во-вторых, такая кодировка совершенно непригодна для представления, китайских иероглифов.
В 1991 году была создана некоммерческая организация «Консорциум Юникода» (англ. Unicode Consortium, Unicode Inc.), которая предложила новый стандарт – Unicode, который обеспечил одновременное представление математических символов, букв греческого алфавита, латиницы, кириллицы и многое другое. Возможности данной кодировки настолько широки, что сейчас в ее набор включены даже наборы картинок (смайлики), см. Рис. 1.1.3..
Пример набора картинок (смайликов), вошедших в стандарт Unicode.
Кодировка Unicode использует 16 разрядов, и может содержать 65536 символов. Это символы большинства народов мира, элементы иероглифов, спецсимволы, 5000 – мест для частного использования, резерв из 30000 мест.
Именно достоинств стандарта Unicode позволили ему уверенно потеснить все остальные кодировки в течении 10 лет (рис. 1.1.4.) и, сегодня, проблема кракозябры встречается гораздо реже чем 6-8 лет назад.
Динамика роста популярности Unicode в Интернет
В данной работе с использованием таблиц кодировки различного типа проводится перевод текстового материала в цифровой вид и обратно.
В таблицах 1.1.1-1.1.4 представлены кодировки для четырех стандартов, используемых в сети Интернет до настоящего времени и с которыми выполняются практические задания в данной работе. В таблицах приняты следующие обозначения:
· Dec – десятичные цифры;
· Hex – шестнадцатеричные цифры.
Таблица UNICODE
Таблица ASCII
Таблица Windows-1251
Таблица КОИ-8
Десятичный код | Символ | Десятичный код | Символ | Десятичный код | Символ |
192 | ю | 214 | ж | 235 | К |
193 | а | 215 | в | 236 | Л |
194 | б | 216 | ь | 237 | М |
195 | ц | 217 | ы | 238 | Н |
196 | д | 218 | з | 239 | О |
197 | е | 219 | ш | 240 | П |
198 | ф | 220 | э | 241 | Я |
199 | г | 221 | щ | 242 | Р |
200 | х | 222 | ч | 243 | С |
201 | и | 223 | ъ | 244 | Т |
202 | й | 224 | Ю | 245 | У |
203 | к | 225 | А | 246 | Ж |
204 | л | 226 | Б | 247 | В |
205 | м | 227 | Ц | 248 | Ь |
206 | н | 228 | Д | 249 | Ы |
207 | о | 229 | Е | 250 | З |
208 | п | 230 | Ф | 251 | Ш |
209 | я | 231 | Г | 252 | Э |
210 | р | 232 | X | 253 | Щ |
211 | с | 233 | И | 254 | Ч |
212 | т | 234 | Й | 255 | Ъ |
213 | у | 160 | пробел |
Кодовая таблица азбуки Морзе
Практическая часть
Подготовка к работе.
· Создайте файл отчета в Word по образцу, приведённому в приложении 1, и заполните его шапку.
ПРИМЕЧАНИЕ. Ваша фамилия (с инициалами) должна являться именем файла отчета.
· Получите номер варианта из табл. 1.1.6 и занесите его в отчет. Далее задания выполняются согласно номеру варианта, если иное не указано в задании.
Вариант | Пункт практической части № 3 СТАНДАРТ/ 10-или 16-ричный код | Пункт практической части № 5 | Пункт практической части № 6 |
1 | UNICODE/10 | кодирование | 111504101715021100 |
2 | UNICODE/16 | таможня | 04151315040504150215 |
3 | Windows-1251/10 | МИИТ | 02142111150215 |
4 | Windows-1251/16 | РУТ | 2605170513052031050215 |
5 | КОИ-8 / 10 | Москва | 131518110200 |
6 | UNICODE/10 | юрист | 1310141811 |
7 | Windows-1251/16 | студент | 15131811 |
8 | UNICODE/16 | инспектор | 02142111150215 |
9 | Windows-1251/10 | граница | 1813151205141811 |
10 | КОИ-8 / 10 | паспорт | 18152510 |
11 | UNICODE/10 | терминал | 111504101715021100 |
12 | Windows-1251/16 | досмотр | 010517121014 |
13 | КОИ-8 / 10 | Смоленск | 133314230514 |
14 | UNICODE/16 | Мурманск | 130004171004 |
15 | КОИ-8 / 10 | пост | 2015131811 |
16 | UNICODE/10 | контроль | 2605170513052031050215 |
17 | UNICODE/16 | евросоюз | 18152510 |
18 | Windows-1251/10 | франция | 111504101715021100 |
19 | Windows-1251/16 | Германия | 133314230514 |
20 | UNICODE/16 | Бельгия | 010517121014 |
21 | Windows-1251/10 | Швеция | 02142111150215 |
22 | КОИ-8 / 10 | Монако | 15131811 |
23 | Windows-1251/16 | Италия | 04151315040504150215 |
24 | UNICODE/16 | Испания | 131518110200 |
25 | UNICODE/10 | Австрия | 2605170513052031050215 |
26 | UNICODE/16 | шифр | 02142111150215 |
27 | Windows-1251/16 | Декларация | 010517121014 |
28 | КОИ-8 / 10 | кодировка | 133314230514 |
29 | Windows-1251/10 | Интернет | 15131811 |
30 | UNICODE/10 | телефон | 130004171004 |
Выполнение работы
1. Закодируйте свое имя и фамилию латинскими буквами 16-ричными цифрами в коде ASCII (с помощью таблицы 1.1.2. ASCII). Числа разделять пробелом, а фамилию и имя тремя пробелами.
Результат занесите в отчет.
2. Закодируйте свое имя и фамилию кириллицей 10-ричными цифрами, разделяя цифры пробелами а фамилию и имя тремя пробелами в трех разных стандартах:
Результат занесите в отчет.
3. Используя таблицы кодировок, закодируйте по условиям вашего варианта название нашего института – ЮРИДИЧЕСКИЙ ИНСТИТУТ. Результат занесите в отчет.
4. Используя кодовую таблицу азбуки Морзе (табл. 1.1.5.) Расшифруйте (декодируйте), что здесь написано (буквы отделены друг от друга пробелами).
Результат поместите в отчет
5. Закодируйте с помощью азбуки Морзе слова согласно варианту, используя символы «-» и «.». Результат поместите в отчет.
6. Используя произвольную кодировочную таблицу 1.1.7, приведенную ниже расшифруйте текст заданный кодом в таблице вариантов (первая цифра кода – номер строки, вторая – номер столбца).
Результат занесите в отчет.
7. Оформите и представьте отчет на проверку преподавателю.
Контрольные вопросы
1. Что такое крякозябры и в чем причина их появления?
2. Что такое ASCII?
3. Какая кодировка является наиболее популярной в Интернет и почему?.
4. Чем определяется популярность кода UNICODE в Интернет?.
5. Почему до сих пор браузеры обеспечиваются широким набором различных кодировок?
6. Когда UNICODE стал наиболее популярной кодировкой в Интернет?
7. Можно ли используя браузер Explorer 11 получить на экране пример крякозябры и, если да, то как?
Возвращаясь к избитой проблеме с кодировками русских букв, хотелось бы иметь под рукой некий единый справочник или руководство, в котором можно найти решения различных сходных ситуаций. В своё время сам перелопатил множество статей и публикаций, чтобы находить причины ошибок. Задача этой публикации — сэкономить время и нервы читателя и собрать воедино различные причины ошибок с кодировками в разработке на Java и JSP и способы их устранения.
Варианты решения могут быть не единственными, охотно добавлю предложенные читателем, если они будут рабочими.
Итак, поехали.
1. Проблема: при получении разработанной мной страницы браузером весь русский текст идёт краказябрами, даже тот, который забит статически.
Причина: браузер неверно определяет кодировку текста, потому что нет явного указания.
Решение: явно указать кодировку:
a) HTML: добавляем тэг META в хидер страницы:
б) XML: указываем кодировку в заголовке:
в) JSP — задаём тип контента в заголовке:
г) JSP — задаём кодировку возвращаемой страницы
д) Java — устанавливаем хидер ответа:
2. Проблема: написанный в JSP-странице статический русский текст почему-то идёт краказабрами, хотя кодировка страницы задана.
Причина: статический текст был написан в кодировке, отличной от заданного странице.
Решение: изменить кодировку в редакторе (например, для AkelPad нажимаем «Сохранить как» и выбираем нужную кодировку).
3. Проблема: получаемый из запроса текст идёт кракозябрами.
Причина: кодировка запроса отличается от используемой для его обработки кодировки.
Решение: установить кодировку запроса или перекодировать в нужную.
а) Java, со стороны отправителя не задана нужная кодировка — перекодируем в нужную:
Примечание: кодировка ISO-8859-1 устанавливается по умолчанию, если не была задана другая.
б) Java, со стороны отправителя задана нужная кодировка — устанавливаем кодировку запроса:
4. Проблема: отправленный GET-параметром русский текст при редиректе приходит кракозябрами.
Причина: упаковка русского текста в URI по умолчанию идёт в ISO-8859-1.
Решение: упаковать текст в нужной кодировке вручную.
а) JSP, URLEncoder:
5. Проблема: текст из базы данных читается кракозябрами.
Причина: кодировка текста, прочитанного из базы данных, отличается от кодировки страницы.
Решение: установить соответствующую кодировку страницы, либо перекодировать полученные из базы данных значения.
а) Java, перекодирование считанной в db_string базы данных строки:
6. Проблема: текст записывается в базу данных кракозябрами, хотя на странице отображается правильно.
Причина: кодировка записываемой строки отличается от кодировки сессии работы с базой данных, либо от кодировки базы данных (стоит помнить, что они не всегда совпадают).
Решение: установить необходимую кодировку сессии или перекодировать строку.
а) Java, перекодирование записываемой строки db_string в кодировку сессии или базы данных:
б) Java, MySQL, настройка параметров подключения в строке dburl, передаваемой функции коннекта:
в) MySQL, настройка параметров подключения в XML-описателе контекста, добавляем атрибут к тегу \:
г) MySQL, прямая установка кодировки сессии вызовом SET NAMES (connect — объект подключения Connection):
7. Проблема: если ничего не помогло…
Решение: всегда остаётся самый «топорный» метод — прямое перекодирование.
а) Для известной кодировки источника:
[String MyValue = new String(source_string.getBytes("utf-8"),"cp1251");]
б) Для параметра запроса:
[String MyValue = new String(request.getParameter("MyParam").getBytes(request.getCharacterEncoding()),"cp1251");]
Дополнение, или что нужно знать:
1. Кодировки базы данных и сессии подключения могут различаться, в зависимости от конкретной СУБД и драйвера. К примеру, при подключении к MySQL стандартным драйвером com.mysql.jdbc.Driver без явного указания кодировка сессии устанавливалась в UTF-8, несмотря на другую кодировку схемы БД.
2. Кодировка упаковки строки запроса в URI по умолчанию устанавливается в ISO-8859-1. С подобным можно столкнуться, например, при передаче явно заданного текста в редиректе с одной страницы на другую.
3. Взаимоотношения кодировок страницы, базы данных, сессии, параметров запроса и ответа не зависят от языка разработки и описанные для Java функции имеют аналоги для PHP, Asp и других.
Примечание: восстановить ссылки на источники нет возможности, все примеры взяты из собственного кода, хотя когда-то так же выискивал их по многочисленным форумам.
Надеюсь, этот небольшой обзор поможет начинающим веб-программистам сократить время отладки и сберечь нервы.
Читайте также: