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

Авторизация и аутентификация – что это и в чём отличие.: spayte — LiveJournal

Большинство пользователей, смутно себе представляете, что такое авторизация и аутентификация, часто путаете эти понятия.

Для того, чтобы зайти под собственным аккаунтом в социальную сеть, на сайт или же, например, в электронную почту, Вам необходимо будет ввести логин и пароль. Именно таким образом удастся перейти на собственную страницу. Чаще всего в сети Интернет подобная процедура называется авторизацией.

Однако, с технической точки зрения это неверное определение. Ведь при возникновении каких-либо ошибок Вам придётся понимать, на каком именно этапе происходит сбой. А для этого нужно ориентироваться между процессами аутентификации и авторизации, и знать ключевые отличия между ними.

Основные определения

Аутентификация — это процедура, которая подтверждает подлинность конкретного человека. К примеру, аутентификацией можно назвать процедуру, при которой человек предъявляет свой паспорт или другой документ, подтверждающий его личность.

«>

Авторизация – это принципиально иной процесс, который подразумевает предоставление конкретному лицу, которое ранее прошло аутентификацию, возможность доступа работы с тем или иным ресурсом или же проведения каких-либо конкретных действий.

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

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

Принцип работы

Процедура аутентификации начинается, когда пользователь конкретного ресурса, например, электронной почты, вводит в соответствующих полях свой логин, а также пароль и нажимает кнопку «Enter». Моментально система проверяет в базе данных конкретного юзера и сопоставляет указанный им пароль с тем, который используется по умолчанию.

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

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

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

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

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

Основные отличия терминов

Для того, чтобы понять разницу между двумя чрезвычайно похожими в локализованных системах технологиями стоить вникнуть в их главные особенности. Так, аутентификация характеризуется следующими аспектами:

1. Технология предназначена для непосредственной проверки личности пользователя.
2. Проведение данной процедуры полностью зависит от информации, которую даёт юзер. Другими словами, если указать неверный логин, либо же допустить ошибку в пароле, то система не сможет распознать пользователя, соответственно, аутентификация не будет произведена.
3. Процедура производится однократно для того, чтобы попасть в учётную запись конкретного ресурса в рамках одной сессии.

Что же касается авторизации, то она характеризуется следующими особенностями:

1. Данный процесс направлен на то, чтобы проверить возможность предоставления конкретному юзеру прав на совершение конкретных действий в рамках одного ресурса.
2. Процесс зависит исключительно от системы и не имеет отношения к данным, которые вносит пользователь.
3. Процедура повторяется многократно во время проведения одной сессии и активируется каждый раз, когда юзер пытается совершить то или иное действие.

Очевидно, что без первой процедуры не может производится вторая, и наоборот. Именно поэтому эти термины так тесно взаимосвязаны и многие не видят между ними разницу, хотя она есть и весьма значимая.

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

Методы идентификации и аутентификации пользователя в информационных системах.

Идентификация пользователя – распознавание пользователя компьютерной системы на основании ранее заданного описания. Идентификация имеет целью определение полномочий пользователя (права доступа к данным и выбора режима их использования).

Аутентификация пользователя –процедура проверки прав пользователя на доступ к информации или на выполнение определенных действий.

Идентификация позволяет пользователю назвать себя (сообщить свое имя). Посредством аутентификации вторая сторона убеждается, что субъект действительно тот, за кого он себя выдает (проверка подлинности).

Аутентификация бывает односторонней и двусторонней (взаимной). Пример односторонней аутентификации – процедура входа пользователя в систему.

3 группы способов аутентификации:

1) основанные на том, что пользователь знает некоторую подтверждающую его подлинность информацию. Это парольная аутентификация и аутентификация на основе модели «рукопожатия».

2) основанные на том, что пользователь имеет некоторый материальный объект, который может подтвердить его подлинность (пластиковая карта с идентифицирующей пользователя информацией и т п) – программно-аппаратные методы

3) основанные на таких данных, которые позволяют однозначно считать, что пользователь и есть тот самый субъект, за которого себя выдает (биометрические данные, особенности клавиатурного почерка и росписи мыши и т п)

Парольная аутентификация

Общая информация

При выборе пароля необходимо руководствоваться двумя взаимоисключающими правилами: пароль должен трудно подбираться и легко запоминаться. Сложность подбора пароля определяется мощностью множества символов (N) и минимально возможной длиной пароля (k). Число всех возможных вариантов паролей С=N^k.

Другие параметры политики учетных записей пользователей:

1) max срок действия пароля;

2) несовпадение пароля с логическим именем пользователя;

3) неповторяемость паролей одного пользователя.

Еще один аспект политики учетных записей пользователей – определение противодействия системы попыткам подбора паролей. Правила:

1) ограничение числа попыток входа в систему;

2) скрытие логического имени последнего работавшего пользователя;

3) учет всех попыток входа в систему.

Реакция системы на неудачную попытку входа:

1) блокировка учетной записи за превышение max возможных попыток

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

Для первоначального ввода или для смены паролей используются два правила:

1) символы не отображаются на экране;

2) ввод пароля повторяется дважды.

Хранение пароля в базе данных осуществляется, как правило, в зашифрованном виде. Минусы:

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

Виды парольной аутентификации:

1) с использованием многоразовых паролей;

2) с использованием одноразовых паролей. Пользователь получает список паролей Р1, Р2, … РN. Каждый из паролей действует только на один сеанс входа. В этом случае знание уже использовавшегося пароля ничего не даст злоумышленнику.

Недостатки: организация защищенного хранения длинного списка паролей, неясность с номером следующего пароля, если при вводе предыдущего вход в систему был не осуществлен из-за сбоя в работе системы. Эти недостатки могут быть устранены, если список паролей генерировать на основе необратимой функции, например, хеширования. Пусть Р – начальный пароль пользователя, а F – необратимая функция. Функция F применяется последовательно i раз для получения Pi : F^i(P) = F(F(…F(P)…)). Тогда список одноразовых паролей создается следующим образом: P1 = F^n (P), P2 = F^(n-1)(P), … , Pn = F(P). При сбое в процессе входа пользователя в систему всегда осуществляется выбор последующего пароля из спсика, а система последовательно применяется функцию F к введенному паролю до совпадения с последним принятым от него паролем или до превышения длины списка.

В любом варианте парольной аутентификации подтверждение подлинности осуществляется на основе ввода некоторой конфиденциальной информации, которую можно выманить, подобрать и т п. Аутентификация на основе модели «рукопожатия» во многом свободна от этих недостатков.

Аутентификация на основе модели «рукопожатия»

Пользователь П и система С согласовывают при регистрации пользователей функцию f, известную только им. Протокол аутентификации пользователя в этом случае выглядит следующим образом:

1) С: генерация случайного значения х, вычисление у = f(х), вывод х.

2) П: вычисление у’ = f ‘ (x), ввод y’.

3) C: если y и y’ совпадают, то пользователь допускается к работе в системе, иначе попытка входа в систему отклоняется.

К функции f предъявляется требование, чтобы по известным x и f(x) нельзя было угадать f.

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

Недостатки: большая длительность этой процедуры по сравнению с парольной.

Статьи к прочтению:

Идентификация — трейлер с русскими субтитрами

Похожие статьи:

Аутентификация — это… Что такое Аутентификация?

Аутентифика́ция (англ. Authentication) — процедура проверки подлинности^[1], например: проверка подлинности пользователя путём сравнения введённого им пароля с паролем в базе данных пользователей; подтверждение подлинности электронного письма путём проверки цифровой подписи письма по ключу проверки подписи отправителя; проверка контрольной суммы файла на соответствие сумме, заявленной автором этого файла. В русском языке термин применяется в основном в сфере информационных технологий.

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

Аутентификацию не следует путать с авторизацией^[2] (процедурой предоставления субъекту определённых прав) и идентификацией (процедурой распознавания субъекта по его идентификатору).

История

С древних времён перед людьми стояла довольно сложная задача — убедиться в достоверности важных сообщений. Придумывались речевые пароли, сложные печати. Появление методов аутентификации с применением механических устройств сильно упрощало задачу, например, обычный замок и ключ были придуманы очень давно. Пример системы аутентификации можно увидеть в старинной сказке «Приключения Али́-Бабы́ и сорока разбойников». В этой сказке говорится о сокровищах, спрятанных в пещере. Пещера была загорожена камнем. Отодвинуть его можно было только с помощью уникального речевого пароля: «Сезам, откройся!».

В настоящее время в связи с обширным развитием сетевых технологий, автоматическая аутентификация используется повсеместно.

Элементы системы аутентификации

В любой системе аутентификации обычно можно выделить несколько элементов^[3]:

• субъект, который будет проходить процедуру аутентификации
• характеристика субъекта — отличительная черта
• хозяин системы аутентификации, несущий ответственность и контролирующий её работу
• сам механизм аутентификации, то есть принцип работы системы
• механизм, предоставляющий или лишающий субъекта определенных прав доступа

Факторы аутентификации

Ещё до появления компьютеров использовались различные отличительные черты субъекта, его характеристики. Сейчас использование той или иной характеристики в системе зависит от требуемой надёжности, защищенности и стоимости внедрения. Выделяют 3 фактора аутентификации^[4]:

• Что-то, что мы знаем — пароль. Это секретная информация, которой должен обладать только авторизованный субъект. Паролем может быть речевое слово, текстовое слово, комбинация для замка или персональный идентификационный номер (PIN). Парольный механизм может быть довольно легко реализован и имеет низкую стоимость. Но имеет существенные минусы: сохранить пароль в секрете зачастую бывает проблематично, злоумышленники постоянно придумывают новые методы кражи, взлома и подбора пароля (см. бандитский криптоанализ). Это делает парольный механизм слабозащищенным.
• Что-то, что мы имеем — устройство аутентификации. Здесь важен факт обладания субъектом каким-то уникальным предметом. Это может быть личная печать, ключ от замка, для компьютера это файл данных, содержащих характеристику. Характеристика часто встраивается в специальное устройство аутентификации, например, пластиковая карта, смарт-карта. Для злоумышленника заполучить такое устройство становится более проблематично, чем взломать пароль, а субъект может сразу же сообщить в случае кражи устройства. Это делает данный метод более защищенным, чем парольный механизм, однако, стоимость такой системы более высокая.
• Что-то, что является частью нас — биометрика. Характеристикой является физическая особенность субъекта. Это может быть портрет, отпечаток пальца или ладони, голос или особенность глаза. С точки зрения субъекта, данный метод является наиболее простым: не надо ни запоминать пароль, ни переносить с собой устройство аутентификации. Однако, биометрическая система должна обладать высокой чувствительностью, чтобы подтверждать авторизованного пользователя, но отвергать злоумышленника со схожими биометрическими параметрами. Также стоимость такой системы довольно велика. Но несмотря на свои минусы, биометрика остается довольно перспективным фактором.

Способы аутентификации

Аутентификация по многоразовым паролям

Один из способов аутентификации в компьютерной системе состоит во вводе вашего пользовательского идентификатора, в просторечии называемого «логином» (англ. login — регистрационное имя пользователя) и пароля — некой конфиденциальной информации. Достоверная (эталонная) пара логин-пароль хранится в специальной базе данных.

Простая аутентификация имеет следующий общий алгоритм:

1. Субъект запрашивает доступ в систему и вводит личный идентификатор и пароль
2. Введенные уникальные данные поступают на сервер аутентификации, где сравниваются с эталонными
3. При совпадении данных с эталонными, аутентификация признается успешной, при различии — субъект перемещается к 1-му шагу

Введённый субъектом пароль может передаваться в сети двумя способами:

• Незашифрованно, в открытом виде, на основе протокола парольной аутентификации (Password Authentication Protocol, PAP)
• С использованием шифрования SSL или TLS. В этом случае уникальные данные, введённые субъектом передаются по сети защищенно.

Защищенность

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

Использование многоразовых паролей имеет ряд существенных минусов. Во-первых, сам эталонный пароль или его хэшированный образ хранятся на сервере аутентификации. Зачастую хранение пароля производится без криптографических преобразований, в системных файлах. Получив доступ к ним, злоумышленник легко доберётся до конфиденциальной информации. Во-вторых, субъект вынужден запоминать (или записывать) свой многоразовый пароль. Злоумышленник может заполучить его, просто применив навыки социальной инженерии, без всяких технических средств. Кроме того, сильно снижается защищенность системы в случае, когда субъект сам выбирает себе пароль. Зачастую это оказывается какое-то слово или комбинация слов, присутствующие в словаре. При достаточном количестве времени злоумышленник может взломать пароль простым перебором. Решением этой проблемы является использование случайных паролей или ограниченность по времени действия пароля субъекта, по истечении которого пароль необходимо поменять.

Базы учетных записей

На компьютерах с ОС семейства UNIX, базой является файл /etc/master.passwd (в дистрибутивах Linux обычно файл /etc/shadow, доступный для чтения только root), в котором пароли пользователей хранятся в виде хеш-функций от открытых паролей, кроме этого в этом же файле хранится информация о правах пользователя. Изначально в Unix-системах пароль (в зашифрованном виде) хранился в файле /etc/passwd, доступном для чтения всем пользователям, что было небезопасно.

На компьютерах с операционной системой Windows NT/2000/XP/2003 (не входящих в домен Windows) такая база данных называется SAM (Security Account Manager — Диспетчер защиты учётных записей). База SAM хранит учётные записи пользователей, включающие в себя все данные, необходимые системе защиты для функционирования. Находится в директории %windir%\system32\config\.

В доменах Windows Server 2000/2003 такой базой является Active Directory.

Однако более надёжным способом хранения аутентификационных данных признано использование специальных аппаратных средств (компонентов).

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

Аутентификация по одноразовым паролям

Заполучив однажды многоразовый пароль субъекта, злоумышленник имеет постоянный доступ к взломанной конфиденциальной информации. Эта проблема решается применением одноразовых паролей (OTP – One Time Password). Суть этого метода — пароль действителен только для одного входа в систему, при каждом следующем запросе доступа — требуется новый пароль. Реализован механизм аутентификации по одноразовым паролям может быть как аппаратно, так и программно.

Технологии использования одноразовых паролей можно разделить на:

• Использование генератора псевдослучайных чисел, единого для субъекта и системы
• Использование временных меток вместе с системой единого времени
• Использование базы случайных паролей, единого для субъекта и для системы

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

Во втором методе используются временные метки. В качестве примера такой технологии можно привести SecurID. Она основана на использовании аппаратных ключей и синхронизации по времени. Аутентификация основана на генерации случайных чисел через определенные временные интервалы. Уникальный секретный ключ хранится только в базе системы и в аппаратном устройстве субъекта. Когда субъект запрашивает доступ в систему, ему предлагается ввести PIN-код, а также случайно генерируемое число, отображаемого в этот момент на аппаратном устройстве. Система сопоставляет введенный PIN-код и секретный ключ субъекта из своей базы и генерирует случайное число, основываясь на параметрах секретного ключа из базы и текущего времени. Далее проверяется идентичность сгенерированного числа и числа, введённого субъектом.

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

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

Многофакторная аутентификация

В последнее время всё чаще применяется, так называемая, расширенная или многофакторная аутентификация. Она построена на совместном использовании нескольких факторов аутентификации. Это значительно повышает защищенность системы.

В качестве примера можно привести использование SIM-карт в мобильных телефонах. Субъект вставляет аппаратно свою карту (устройство аутентификации) в телефон и при включении вводит свой PIN-код (пароль).

Также, к примеру в некоторых современных ноутбуках присутствует сканер отпечатка пальца. Таким образом, при входе в систему субъект должен пройти эту процедуру (биометрика), а потом ввести пароль.

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

Можно привести сравнительную таблицу:

Протоколы аутентификации

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

Самый простой протокол аутентификации — доступ по паролю (Password Authentication Protocol, PAP). Его суть состоит в том, что вся информация о субъекте (идентификатор и пароль) передается по сети в открытом виде. Это и является главным недостатком PAP, так как злоумышленник может легко получить доступ к передающимся незашифрованным данным.

Более сложные протоколы аутентификации основаны на принципе «запрос-ответ», например, протокол CHAP (Challenge-Handshake Authentication Protocol). Работа протокола типа «запрос-ответ» может состоять минимум из четырех стадий:

1. Субъект отправляет системе запрос, содержащий его персональный идентификатор
2. Система генерирует случайное число и отправляет его субъекту
3. Субъект зашифровывает полученное число на основе своего уникального ключа и результат отправляет системе
4. Система расшифровывает полученное сообщение на основе того же уникального ключа. При совпадении результата с исходным случайным числом, аутентификация проходит успешно.

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

Принцип действия протоколов взаимной аутентификации отличаются от протоколов типа «запрос-ответ» незначительно:

1. Субъект отправляет системе запрос, содержащий его персональный идентификатор и случайное число N1
2. Система зашифровывает полученное число N1 на основе уникального ключа, генерирует случайное число N2, и отправляет их оба субъекту
3. Cубъект расшифровывает полученное число на основе своего уникального ключа и сравнивает результат с N1. Идентичность означает, что система обладает тем же уникальным ключом, что и субъект
4. Субъект зашифровывает полученное число N2 на основе своего уникального ключа и результат отправляет системе
5. Система расшифровывает полученное сообщение на основе того же уникального ключа. При совпадении результата с исходным числом N2, взаимная аутентификация проходит успешно.

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

В операционных системах семейства Windows NT 4 используется протокол NTLM (NT LAN Manager — Диспетчер локальной сети NT). А в доменах Windows 2000/2003 применяется гораздо более совершенный протокол Kerberos.

См. также

Примечания

Ссылки

Литература

• Ричард Э. Смит Аутентификация: от паролей до открытых ключей = Authentication: From Passwords to Public Keys First Edition. — М.: «Вильямс», 2002. — С. 432. — ISBN 0-201-61599-1

обзор технологии OAuth 2.0 / Блог компании Dodo Engineering / Хабр

Информационная система Dodo IS состоит из 44 различных сервисов, таких как Трекер, Кассы ресторана или Базы знаний и многих других. Чтобы не отвлекаться на несколько аккаунтов, 3 года назад мы написали сервис Auth для реализации сквозной аутентификации, а сейчас пишем уже вторую версию, в основе которого лежит стандарт авторизации OAuth 2.0. Этот стандарт довольно сложный, но если у вас сложная архитектура с множеством сервисов, то OAuth 2.0 вам пригодится при разработке своего сервиса аутентификации. В этой статье я постарался рассказать о стандарте максимально просто и понятно, чтобы вы сэкономили время на его изучение.

Задача Auth

Проблема авторизации в десятках сервисов встречалась ещё несколько лет назад — в начале «эпохи распила монолита». Эту проблему решили новым сервисом, который назвали – Auth. Он помог реализовать бесшовную аутентификацию в различных сервисах и перенести данные о пользователях в отдельные базы данных. 

У сервиса Auth есть три основные задачи:

• Единая точка аутентификации (SSO) для всех сервисов системы. Сервисы не хранят учётные данные, а доверяют это одному выделенному сервису.
• Безопасный и гранулированный доступ к ресурсам. Безопасный, потому что пароли хранятся в одном месте и максимально защищены. Гранулированный, так как владельцы сервисов могут настраивать доступ к ресурсам как они захотят, опираясь на данные, пришедшие из сервиса аутентификации.
• Централизованное управление пользователями и доступом. Благодаря тому, что вся информация о пользователе хранится в сервисе аутентификации, мы можем управлять пользователями централизованно.

Проблемы

Первая версия Auth — часть монолита. Он использует свой собственный протокол общения с сервисами. Такая «схема» была необходима в тот момент, но за несколько лет работы проявились проблемы.

Auth — часть монолита. Следовательно, сервис привязан к релизному циклу, что лишает возможности независимой разработки и деплоя. Кроме того, придется разворачивать весь монолит, если захотелось развернуть Auth, например, при масштабировании сервиса.

Dodo IS зависит от Auth. В старой реализации внешние сервисы обращаются к Auth при каждом действии пользователя, чтобы валидировать данные о нём. Настолько сильная привязка может привести к остановке работы всей Dodo IS, если Auth «приляжет» по какой-то причине.

Auth зависит от Redis. Притом достаточно сильно — неисправность работы Redis’а приведёт к падению Auth’а. Мы используем Azure Redis, для которого заявленный SLA 99,9%. Это значит, что сервис может быть недоступен до 44 минут в месяц. Такие простои не позволительны.

Текущая реализация Auth использует свой протокол аутентификации, не опираясь на стандарты. В большинстве своих сервисов мы используем C# (если говорим о backend) и у нас нет проблем с поддержкой библиотеки для нашего протокола. Но если вдруг появятся сервисы на Python, Go или Rust, разработка и поддержка библиотек под эти языки потребует дополнительных затрат времени и принесет дополнительные сложности.

Текущий Auth использует схему Roles Based Access Control, которая базируется на ролях. Обычно с ролью выдаётся полный доступ к определённому сервису, вместо привязки к конкретному функционалу. Например, в пиццериях есть заместители управляющего, которые могут вести определенные проекты: составлять графики или учитывать сырьё. Но у нас нет выдачи прав на конкретные компоненты системы. Приходится выдавать полный доступ к сервису, чтобы сотрудники могли получить доступ к составлению графиков или настройкам какого-либо компонента учёта.

Проблемы подтолкнули к тому, чтобы спроектировать и написать новую версию Auth. На старте проекта мы потратили 3 недели только на изучение стандартов авторизации и аутентификации OAuth 2.0 и OpenID Connect 1.0. 

Примечание. Утрированно, статья — это пересказ RFC, который приходилось перечитывать несколько раз, чтобы понять, что происходит вокруг. Здесь я постарался уйти от этой сложности и рассказать всё максимально просто, структурировано, кратко и без описания сложных вещей, например, какие символы может содержать в себе ответ сервиса. В отличии от RFC, прочитав это один раз, можно во всём разобраться. Надеюсь, статья будет полезна и сэкономит время при выборе решения для реализации сервиса аутентификации, а может, кого-то заставит задуматься о его необходимости.

Что такое ОAuth3.0?

Разработку нового Auth мы решили начать с изучения доступных протоколов и технологий. Самый распространённый стандарт авторизации — фреймворк авторизации OAuth3.0. 

Стандарт был принят в 2012 году, и за 8 лет протокол меняли и дополняли. RFC стало настолько много, что авторы оригинального протокола решили написать OAuth 2.1, который объединит все текущие изменения по OAuth 2.0 в одном документе. Пока он на стадии черновика.

Актуальная версия OAuth описанна в RFC 6749. Именно его мы и разберем. 

OAuth 2.0 — это фреймворк авторизации.

Он описывает, как должно реализовываться взаимодействие между сервисами для обеспечения безопасной авторизации. Многие нюансы описаны достаточно подробно, например, flow взаимодействия узлов между собой, но некоторые отдаются на откуп конкретной реализации.

Особенности:

• Разделение сущности пользователя и приложения, запрашивающего доступ. Благодаря этому разделению мы можем управлять правами приложения отдельно от прав пользователя. 

• Вместо привычных логина и пароля, которые имеют определенный набор прав и время жизни, мы получаем доступ к ресурсам с помощью случайно сгенерированных строк — токенов.
• Можно выдавать права максимально точечно, опираясь на собственные пожелания, а не на заранее определённый набор прав.

Разберёмся подробнее в особенностях.

Роли

В OAuth 2.0 определены четыре роли:

• Resource owner — сущность, которая имеет права доступа на защищённый ресурс. Сущность может быть конечным пользователем или какой-либо системой. Защищённый ресурс — это HTTP endpoint, которым может быть что угодно: API endpoint, файл на CDN, web-сервис.
• Resource server — сервер, на котором хранится защищённый ресурс, к которому имеет доступ resource owner.
• Client. Это приложение, которое запрашивает доступ к защищённому ресурсу от имени resource owner и с его разрешения — с авторизацией. 
• Authorization server — сервер, который выдаёт клиенту токен для доступа к защищённому ресурсу, после успешной авторизации resource owner.

Каждый участник взаимодействия может совмещать в себе несколько ролей. Например, клиент может быть одновременно resource owner, и запрашивать доступ к своим же ресурсам. Схему взаимодействия рассмотрим дальше.

Важно: клиент должен быть заранее зарегистрирован в сервисе. Как это сделать?

Регистрация клиента

Способ регистрации клиента, например, ручной или service discovery, вы выбираете сами, в зависимости от фантазии конкретной реализации. Но при любом способе при регистрации, кроме ID клиента, должны быть обязательно указаны 2 параметра: redirection URI и client type.

Redirection URI — адрес, на который отправится владелец ресурса после успешной авторизации. Кроме авторизации, адрес используется для подтверждения, что сервис, который обратился за авторизацией, тот, за кого себя выдаёт.

Client type — тип клиента, от которого зависит способ взаимодействия с ним. Тип клиента определяется его возможностью безопасно хранить свои учётные данные для авторизации — токен. Поэтому существует всего 2 типа клиентов:

• Confidential — клиент, который может безопасно хранить свои учётные данные. Например, к такому типу клиентов относят web-приложения, имеющие backend.
• Public — не может безопасно хранить свои учётные данные. Этот клиент работает на устройстве владельца ресурса, например, это браузерные или мобильные приложения.

Токены

Токен в OAuth 2.0 — это строка, непрозрачная для клиента. Обычно строка выглядит как случайно сгенерированная — её формат не имеет значения для клиента. Токен — это ключ доступа к чему-либо, например, к защищённому ресурсу (access token) или к новому токену (refresh Token).

У каждого токена своё время жизни. Но у refresh token оно должно быть больше, т.к. он используется для получения access token. Например, если срок жизни access token около часа, то refresh token можно оставить жить на целую неделю. 

Refresh token опционален и доступен только для confedential клиентов. Пользуясь опциональностью токена, в некоторых реализациях время жизни access token сделано очень большим, а refresh token вообще не используется, чтобы не заморачиваться с обновлением. Но это не безопасно. Если access token был скомпрометирован, его можно обнулить, а сервис получит новый Access token с помощью refresh token. В случае, если refresh token нет, то потребуется проходить процесс авторизации заново.

За access token закреплён определённый набор прав доступа, который выдаётся клиенту во время авторизации. Давайте разберёмся, как выглядят права доступа в OAuth 2.0.

Права доступа

Права доступа выдаются клиенту в виде scope. Scope – это параметр, который состоит из разделённых пробелами строк — scope-token.

Каждый из scope-token представляет определённые права, выдающиеся клиенту. Например, scope-token doc_read может предоставлять доступ на чтение к какому-то документу на resource server, а employee — доступ к функционалу приложения только для работников фирмы. Итоговый scope может выглядеть так: email doc_read employee.

В OAuth 2.0 мы сами создаём scope-token, настраивая их под свои нужды. Имена scope-token ограничиваются только фантазией и двумя символами таблицы ASCII — " и \.

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

Абстрактный OAuth 2.0. Flow c применением Access token

Мы рассмотрели роли, рассмотрели виды токенов, а также как выглядят scope. Посмотрим на flow предоставления доступа к сервису.

Ниже представлена абстрактная схема (или flow) взаимодействия между участниками. Все шаги на данной схеме выполняются строго сверху вниз. Разберём детальнее.

• Client отправляет запрос на доступ к требуемому ресурсу resource owner.
• Resource owner передаёт обратно клиенту authorization grant, который подтверждает личность resource owner и его права на ресурс, доступ к которому запрашивает client. В зависимости от flow это может быть токен или учётные данные.
• Client отправляет authorization grant, полученный в предыдущем шаге authorization server, ожидая от него Access token для доступа к защищённому ресурсу. 
• authorization server убеждается в валидности authorization grant, после чего отсылает access token клиенту в ответ.
• Получив access token, клиент запрашивает защищённый ресурс у resource server. 
• Resource server убеждается в корректности access token, после чего предоставляет доступ к защищённому ресурсу.

Клиент получает одобрение от resource owner, на основе которого ему выдаётся доступ к ресурсу. Всё просто. А будет ли так же просто, если мы добавим в эту схему работу с refresh token?

Абстрактный OAuth 2.0. Flow c применением Refresh token

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

Схема подробнее:

• Client приходит c authorization grant к authorization server и просит предоставить ему access token и refresh token.
• Authorization server убеждается, что с authorization grant всё нормально и возвращает клиенту запрошенные access token и refresh token.
• Client с access token запрашивает защищённый ресурс, пока не получит первую ошибку доступа к ресурсу — invalid token error.
• После получения ошибки доступа, клиент идет к authorization server с refresh token и просит заменить просроченный access token на новый. 
• В ответ клиент получает новый access token, а также новый refresh token, либо продлевается время жизни старого refresh token. 

Что такое grant?

Grant — это данные, которые представляют из себя успешную авторизацию клиента владельцем ресурса, используемые клиентом для получения access token.

Например, когда мы где-либо аутентифицируемся с помощью Google, перед глазами всплывает уведомление. В нём говорится, что такой-то сервис хочет получить доступ к данным о вас или к вашим ресурсам (выводятся запрашиваемые scope-token). Это уведомление называется «Consent Screen».

В момент, когда нажимаем «ОК», в базу данных попадает тот самый grant: записываются данные о том, что такой-то пользователь дал такие-то доступы такому-то сервису. Клиент получает какой-то идентификатор успешной аутентификации, например строку, которая ассоциируется с данными в базе данных.

Существует 4 + 1 способа получения grant — grant type:

• Authorization code — используется для confedencial клиентов — web-сервисов.
• Client credentials — используется для confedential клиентов, которые запрашивают доступ к своим ресурсам или ресурсам, заранее согласованным с сервером авторизации.
• Implicit — использовался public-клиентами, которые умеют работать с redirection URI (например, для браузерных и мобильных приложений), но был вытеснен authorization code grant с PKCE (Proof Key for Code Exchange — дополнительная проверка, позволяющая убедиться, что token получит тот же сервис, что его и запрашивал. Прочитать подробнее — RFC 7636).
• Resource owner password credentials. В RFC 6819, посвящённому безопасности в OAuth 2.0, данный тип grant считается ненадёжным. Если раньше его  разрешалось использовать только для миграции сервисов на OAuth 2.0, то в данный момент его не разрешено использовать совсем.
• Device authorization (добавлен в RFC 8628) – используется для авторизации устройств, которые могут не иметь веб-браузеров, но могут работать через интернет. Например, это консольные приложения, умные устройства или Smart TV.

Актуальными можно считать только authorization code (с PKCE), client credentials и device authorization grant, но мы рассмотрим все. Рассматривать grant будем в порядке возрастания сложности понимания.

Client credentials grant flow

Имеет самый простой flow, напоминающий обычную авторизацию на любом сервисе. Она выполняется с помощью учётных данных клиента, которые представляют собой client id и client secret — аналог логина и пароля для пользователя. Так как для аутентификации требуется client secret, который должен соответствующе храниться, данный flow могут использовать только confedential клиенты.

Схема проста: клиент аутентифицируется на сервере авторизации передавая client id и client secret. В ответ получает access token, с которым уже может получить доступ к нужному сервису.

Этот flow требуется, когда клиент пытается получить доступ к своим ресурсам или ресурсам, заранее согласованным с сервером авторизации. Например, сервису А нужно время от времени ходить в сервис Б и актуализировать там данные о количестве пиццерий в сети.

Resource owner password credentials flow

По текущим рекомендациям безопасности описанных в данном RFC, данный flow не рекомендуется использовать вовсе из-за явных проблем с безопасностью.

На иллюстрации данного flow два Client, а по идее должен быть Client и Authorization Server.


Resource owner передаёт свой логин и пароль клиенту, например, через формы на клиенте. Клиент, в свою очередь, с помощью него получает access token (и, опционально, refresh token).

Здесь есть проблема. Resource owner просто берёт и отдаёт в открытом виде свой логин и пароль клиенту, что не безопасно. Изначально он был сделан только для клиентов, которым вы доверяете или тех, что являются частью операционной системы. Позже он был разрешён только для миграции с аутентификации по логину и паролю на OAuth 2.0. Текущие рекомендации по безопасности запрещают его использование. 

Authorization code

Самый распространённый flow на данный момент. В основном используется для confidential клиентов, но с появлением дополнительной проверки с помощью PKCE, может применяться и для public-клиентов. 

В данном flow взаимодействие client с resource owner проходит через user-agent (браузер). К user-agent есть одно требование: он должен уметь работать с HTTP-редиректами. Без этого resource owner не сможет попасть к серверу авторизации и вернуться обратно с grant. 

Данный flow сложнее, чем предыдущие, поэтому будем разбирать по шагам. Для начала представим, что мы — resource owner и перешли на страницу сервиса онлайн-обучения, который хочет сохранять результаты обучения к нам в облако. Ему требуется получить доступ к нашему ресурсу, например, определённой директории в облаке. Мы нажимаем на «Авторизоваться» и начинается путешествие по Authorization code grant flow:

• На первом шаге клиент перенаправляет resource owner с помощью user-agent на страницу аутентификации Authorization server. В URI он указывает client ID и redirection URI. Redirection URI используется для понимания, куда вернуть resource owner после того, как авторизация пройдёт успешно (resource owner выдаст разрешение на scope, запрашиваемый клиентом).
• Взаимодействуя с сервером авторизации через user-agent, resource owner проходит аутентификацию на сервере авторизации.
• Resource owner проверяет права, которые запрашивает клиент на consent screen и разрешает их выдачу.
• Resource owner возвращается клиенту с помощью user-agent обратно на URI, который был указан как redirection URI. В качестве query-параметра будет добавлен authorization code — строка, подтверждающая то, что resource owner выдал необходимые права сервису. 
• С этим authorization code клиент отправляется на сервер авторизации, чтобы получить в ответ access token (ну и refresh token, если требуется).
• Сервер авторизации валидирует authorization code, убеждаясь, что токен корректный и выдаёт клиенту access token (и опционально refresh token). С его помощью клиент сможет получить доступ к заветному ресурсу. 

Если представить нас на месте resource owner, то мы видим просто перенаправление на сервер авторизации, аутентифицируемся, подтверждаем доступ на Consent screen и нас отправляет на уже работающий сервис. Например, мы проходим это много раз, когда заходим на сервис под учётной записью Google, Facebook или Apple.

Следующий flow построен на основе этого.

Implicit grant

Это оптимизация Authorization code grant flow для public-клиентов, которые умеют работать с redirection URI. Например, для браузерных приложений на JavaScript, или мобильных приложений. Требование к user-agent, с помощью которого взаимодействуют клиент и resource owner, сохраняется: он должен уметь работать с HTTP-редиректами.

Между authorization code и implicit есть основное отличие: вместо получения authorization code и access token по нему, мы сразу получаем access token после успешной авторизации resource owner. Кроме того, здесь не используется client secret из соображений безопасности — приложение можно дизассемблировать и получить его. Подлинность проверяется только по redirection URI.

Многие шаги из данной схемы похожи на шаги из authorization code, но предлагаю их разобрать также подробно. Представим, что некое браузерное приложение хочет сохранять свои настройки в нашем Git-репозитории. Мы нажимаете «Войти в GitHub» и на этом этапе начинается работа Implicit flow:

• Клиент с помощью user-agent и HTTP-редиректа перенаправляет resource owner на сервер авторизации. В параметрах запроса передает client ID и redirection URI, которые нужны для аутентификации клиента и последующего возврата resource owner обратно.
• Resourse owner аутентифицируется, взаимодействуя через user-agent с сервером авторизации. Заодно подтверждает выдачу grant клиенту, с client ID которого он пришёл.
• После подтверждения выдачи grant (нажатия «allow» на consent screen), user-agent возвращает resource owner на redirection URI. Кроме того, в URI fragment передаётся access token (URI fragment — это то, что обычно идёт в URI после символа ‘#’).
• Сам фрагмент сохраняется локально в user-agent. User-agent двигается дальше по redirection URI за web-страницей, которая нужна для получения access token и других необходимых данных из фрагмента. Она может находиться как на самом клиенте, так и на удалённом ресурсе, например, на CDN.
• Web-ресурс возвращает web-страницу (может содержать в себе скрипт), которая может прочитать полностью redirection URI, в том числе и значение, указанное в фрагменте.
• User-agent отрисовывает локально полученную страницу, включая исполнение скриптов, которые он получил от web-hosted client resource, которые получают access token.
• Полученный access token user-agent просто передаёт клиенту.

Это сложный flow. Он мало используется в реальных сценариях. Но его всё ещё можно встретить в legacy-проектах.

Device authorization (RFC 8628)

С 2012 до 2019 появилось много умных устройств, на которых неудобно авторизоваться. Например, неудобно вводить сложный логин и пароль на телевизоре каждый раз при открытии ресурса. На некоторых устройствах это невозможно, например на серверных ОС без графического интерфейса. В августе 2019 этот flow появился как раз для таких сценариев. 

Есть, как минимум, 3 требования к устройствам, чтобы работа с помощью Device authoraztion grant flow была возможна:

• Устройство должно иметь возможность совершать исходящие HTTPS-запросы.
• Устройство должно иметь возможность отображать URI и код пользователю.
• Каждое авторизуемое устройство принадлежит resource owner, который для успешной авторизации должен иметь другое устройство с браузером, чтобы перейти по указанному URI и ввести указанный код.

Возможно, схема кажется сложной из-за обилия стрелок. Разберём её также пошагово, как и разбирали сложные flow до него.

Представим, что мы пытаемся авторизоваться на web-сервисе с помощью телевизора. Мы видим кнопку «Авторизоваться как устройство» и нажимаем. В этот момент начинается наш Device flow:

• Телевизор делает запрос на сервер авторизации, передавая ему свой client ID.
• Сервер авторизации убеждается, что такой клиент зарегистрирован и имеет соответствующий тип grant.
• Если всё хорошо, то Authorization server возвращает device code, user code и verification URI. Device code — это уникальный идентификатор устройства, которое авторизуется в системе.
• Устройство отображает user code и verification URI владельцу этого устройства — resource owner. Redirection URI может быть передан как строкой, так и с помощью QR-кода — ограничений нет.
• После того, как устройство отобразило user code и verification URI, оно начинает раз в некоторое время опрашивать сервер авторизации о её успешности.
• Дальше в бой вступает resource owner. Он переходит по указанному verification URI, аутентифицируется и вводит user code, который он получил от устройства, подтверждая выдачу необходимых scope устройству. На этом действия от имени resource owner закончены.
• Всё это время устройство (пункт 3) опрашивало сервер авторизации о её успешности. Устройство в очередной раз идёт к серверу авторизации со своим device code и client ID в надежде, что авторизация на этот раз прошла.
• В этот раз, когда resource owner подтвердил передачу необходимых прав устройству, сервер авторизации возвращает в ответе на запрос access token (если предусмотрено настройками сервера и refresh token). И с помощью токена устройство уже может продолжать работу с ресурсом.

Несмотря на кажущуюся сложность со стрелочками, этот flow тоже достаточно прост. Если вам требуется взаимодействовать с устройствами (а у нас их много: трекер, касса, витрины и прочие устройства), то вам стоит использовать этот flow.

Вместо вывода

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

Если хотите погрузиться в тематику детальнее, то рекомендую в RFC 6749 (для OAuth 2.0) и RFC 8628 (для Device Flow). Кроме того, следить за актуальными версиями RFC можно на ресурсе, посвящённому OAuth.

Если статья была полезна и захотите подробностей — пишите в комментариях, и в следующих статьях расскажу о PKCE, о протоколе аутентификации OpenID Connect 1.0, о нашей реализации сервера аутентификации и многом другом.

Полезные ссылки:

Аутентификация в мобильных приложениях / Блог компании Инфопульс Украина / Хабр

История с предысторией

Идеальный телефон, как верный пёс, должен узнавать хозяина по запаху и охранять имущество от посторонних.

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

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

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

Скоро этого стало не хватать. У первобытных программистов появились идентификаторы, затем логин с паролем – и вот перед нами классическая Basic Authentication протокола HTTP.

Логин и пароль

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

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

Между прочим, в мобильных телефонах существует понятие PIN-кода. Похоже на пароль? Да. Это защитный механизм, решающий задачу безопасности, при этом прямо не связанный с аутентификацией.

Почему нельзя обойтись только логином? Теоретически можно, а практически очень неудобно. Логин фигурирует в формах запросов и отчётах, его иногда приходится сообщать в службу поддержки. Сделав логин трудным для подбора и скрытым от окружающих, мы уподобим его паролю. А чтобы как-то отображать публичную информацию по нашей учётной записи, придётся добавить новое поле – скажем, ник, – что сделает всё затею не заслуживающей усилий.

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

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

Можно было бы добавить, что всё здесь хорошо и ничего менять не надо, но – нет.

Шифрование

С появлением вычислительных сетей выяснилось, что пароль в открытом виде передавать опасно, так как его по дороге может перехватить злоумышленник. Логичным решением было внедрить шифрование пароля. Так появились Digest Authentication и NTLM. Пользователь вводит всё те же данные, но «по проводам» они передаются в закодированном виде. Расшифровать или взломать их, в принципе, специалисты могут, однако это всё равно надёжнее отправки пароля открытым текстом.

Интересующихся защищёнными каналами связи мы отсылаем к изучению протокола HTTPS, SSL и TLS, а сами движемся дальше, к постижению мобильного дао.

Single-Sign-On

Другим неприятным аспектом всеохватного запароливания оказалось, что не очень-то удобно держать в голове больше одной-двух пар логина и пароля, вводить их всякий раз при входе в программу, особенно если этих программ больше одной. Результатом решения проблемы стали аутентификация oAuth и принцип SSO, то есть Single-Sign-On (войти один раз).

Идея oAuth проста. Вместо того чтобы каждый раз требовать у пользователя его логин и пароль, лучше сделать это один раз, на основании полученных сведений получить так называемый токен у доверенного сервера и далее проводить операции уже с этим токеном. Это особенно удобно в контексте обмена данными между мобильным или web приложением и удалённым сервером, где аутентифицирующие сведения (credentials) необходимо передавать с каждым запросом.

SSO решает немного другую задачу.

В рамках web все приложения, использующие один и тот же доверенный сервер для oAuth-аутентификации (например, сайты с Гугль-аккаунтом), автоматически разделяют между собой сведения пользователя (credentials). То есть, введя логин и пароль в одном приложении, в другое пользователь заходит уже опознанным.

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

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

Где хранятся пароли

У читателя, который не просто скользит взглядом по тексту и смог пробиться через предыдущий абзац, должен возникнуть вопрос: а что же это за место такое, где можно безопасно хранить такие чувствительные данные о пользователе, как логин и пароль? Это место специальное, в зависимости от платформы и технологии называемое по-разному, но чаще всего – KeyChain (iOS, Android). Данные здесь шифруются, доступ к ним ограничен – в общем, это самое безопасное место на устройстве, защищённость которого гарантируется на уровне операционной системы.

Где пароли нельзя хранить

Довести офицера Secure Service до истерики можно хранением пароля в базе данных. Плохой идеей также будет отправлять логины с паролями куда-нибудь в системный лог. Замечание средней недопустимости можно получить за временное хранение пароля в публичных переменных – хорошим тоном считается вычитка сведений о пользователе из KeyChain по мере необходимости, без хранения их где-либо ещё.

TouchID/Fingerprints

Широко известно, что человек обладает уникальными отпечатками пальцев. Кроме того, уникальными являются отпечатки носов и ушей, причём если пальцы – атрибут в основном сугубо человеческий, то носы есть и у домашних животных. На практике опознавание по отпечаткам носов используется для идентификации кошек, собак и коров.

Когда-нибудь, возможно, мы научим наши телефоны опознавать хозяина, просто взяв его в руку, но пока что технология сосредоточилась на дактилоскопии, закрепившейся в криминалистической практике ещё сто лет назад (то, что это очень удобно и для АНБ, мы оставим за рамками статьи).

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

Face ID

Последнее новшество от Apple – аутентификация посредством распознавания лица. Если для отпечатков пальцев достаточно теоретически несложной алгоритмической обработки, то для распознавания лиц прибегают к идеям Розенблатта и строят нейросеть.

Конечно же, мощности нейросети в iPhone недостаточно для игры в шахматы или го, но со своей задачей она справляется. Телефон теперь может опознать своего хозяина визуально.

Эти последние новшества, как нетрудно представить, бесконечно радуют корпоративных офицеров безопасности и настолько же бесконечно раздражают конечных пользователей. Здесь, на передовом технологическом крае, сходятся щит и меч, добро и зло, и лёд, и пламя. Здесь куётся MFA.

Multifactor authentication

Мы не знаем, в чью именно голову пришла эта светлая мысль, но теперь, когда она воплотилась в цифровой вселенной, нам приходится сначала вводить логин и пароль, а затем подтверждать нашу личность ещё и посредством пин-кода.

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

Применение данной технологии для мобильных приложений выглядит немного спорным, но вполне возможным.

Блокчейн и китайские куры

После того, как биткоин и прочие криптовалюты произвели ажиотажный общественный резонанс, было бы странно, если бы лежащий в основе трансакций этих валют блокчейн не привлёк внимание разработчиков систем безопасности.

Как же можно задействовать цепочку блоков для аутентификации? Очень просто.

Применительно к человеку, сама по себе технология блокчейн уже сегодня работает в Эстонии как платформа для электронного гражданства; есть подобные попытки в Бразилии и Финляндии. А японская Sony скрестила MFA и блокчейн (U.S. patent 2017/0310653 A1*). Так что теперь, когда в очередной раз вы где-нибудь введёте код подтверждения из SMS-ки, вполне вероятно, что эта ваша активность будет сохранена навечно (в рамках существования нашей цифровой вселенной).

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

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

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

—

* patents.google.com/patent/US20170310653A1/en

Как ты реализуешь аутентификацию, приятель? / Блог компании Mail.ru Group / Хабр

Все знают о стандартной аутентификации пользователя в приложении. Это олдскульная процедура регистрации — пользователь вводит адрес почты, пароль и т. д., — а затем при входе мы сравниваем почту и/или пароль с сохранёнными данными. Если совпадает, даём доступ. Но времена изменились, и сегодня появилось много других методов аутентификации. Если хотите оставаться востребованным программистом/разработчиком в этом меняющемся, словно калейдоскоп, мире разработки ПО, то вы должны знать обо всех этих новых методах.

Нельзя отрицать, что в любых приложениях и ОС «аутентификация» — крайне важный элемент обеспечения сохранности пользовательских данных и регулирования доступа к информации. Чтобы понять, какой метод аутентификации для вас лучше, нужно разбираться в достоинствах и недостатках всех методов, а также неплохо представлять, как же они работают.

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

Будем считать, вы уже знаете о том, что большая часть веба/интернета построена на протоколе HTTP. Также вам нужно знать, как работают веб-приложения, что означает аутентификация пользователя в приложении и что такое клиент-серверная архитектура.

Готовы? Поехали.

Аутентификация на основе сессий

Протокол HTTP не отслеживает состояния, и, если мы аутентифицируем пользователя с помощью имени и пароля, наше приложение не будет знать, тот ли это человек, что и в предыдущем запросе. Нам придётся аутентифицировать снова. При каждом запросе HTTP не знает ничего о том, что происходило до этого, он лишь передаёт запрос. Так что, если вам нужны личные данные, придётся снова логиниться, чтобы приложение знало, что это точно вы. Может сильно раздражать.

Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространённый и широко известный метод, используемый уже давно.

Процедура аутентификации на основе сессий:

1. Пользователь вводит в браузере своё имя и пароль, после чего клиентское приложение отправляет на сервер запрос.
2. Сервер проверяет пользователя, аутентифицирует его, шлёт приложению уникальный пользовательский токен (сохранив его в памяти или базе данных).
3. Клиентское приложение сохраняет токены в куках и отправляет их при каждом последующем запросе.
4. Сервер получает каждый запрос, требующий аутентификации, с помощью токена аутентифицирует пользователя и возвращает запрошенные данные клиентскому приложению.
5. Когда пользователь выходит, клиентское приложение удаляет его токен, поэтому все последующие запросы от этого клиента становятся неаутентифицированными.

У этого метода несколько недостатков.

• При каждой аутентификации пользователя сервер должен создавать у себя запись. Обычно она хранится в памяти, и при большом количестве пользователей есть вероятность слишком высокой нагрузки на сервер.
• Поскольку сессии хранятся в памяти, масштабировать не так просто. Если вы многократно реплицируете сервер, то на все новые серверы придётся реплицировать и все пользовательские сессии. Это усложняет масштабирование. (Я считал, этого можно избежать, если иметь выделенный сервер для управления сессиями, но это сложно реализовать, да и не всегда возможно.)

Аутентификация на основе токенов

Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.

При аутентификации на основе токенов состояния не отслеживаются. Мы не будем хранить информацию о пользователе на сервере или в сессии и даже не будем хранить JWT, использованные для клиентов.

Процедура аутентификации на основе токенов:

1. Пользователь вводит имя и пароль.
2. Сервер проверяет их и возвращает токен (JWT), который может содержать метаданные вроде user_id, разрешений и т. д.
3. Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук.
4. Последующие запросы к серверу обычно содержат этот токен в качестве дополнительного заголовка авторизации в виде Bearer {JWT}. Ещё токен может пересылаться в теле POST-запроса и даже как параметр запроса.
5. Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
6. Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.

Более подробное описание.

У метода есть ряд преимуществ:

• Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передаёт затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
• В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
• При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
  
  Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, ещё одно обращение — для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение — для получения данных.
  
  А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
• У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.

Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.

Беспарольная аутентификация

Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»

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

Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:

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

Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.

И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии.

Если вы пользуетесь Slack, то уже могли столкнуться с беспарольной аутентификацией.

Medium предоставляет доступ к своему сайту только по почте. Я недавно обнаружил, что Auth0, или Facebook AccountKit, — это отличный вариант для реализации беспарольной системы для вашего приложения.

Что может пойти не так?

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

В чём преимущества?

Как часто вы пользуетесь ссылкой «забыли пароль» для сброса чёртового пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей, идиот». Уважаю. Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.

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

Если вы думаете, что какие-то пользователи предпочтут старомодные логин/пароль, то предоставьте им оба варианта, чтобы они могли выбирать.

Сегодня беспарольная аутентификация быстро набирает популярность.

Единая точка входа (Single Sign On, SSO)

Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например Gmail, а потом идёшь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автомагически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube — это сервисы Google, но всё же раздельные продукты. Как они аутентифицируют пользователя во всех продуктах после единственного входа?

Этот метод называется единой точкой входа (Single Sign On, SSO).

Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:

1. Пользователь входит в один из сервисов Google.
2. Пользователь получает сгенерированную в Google Accounts куку.
3. Пользователь идёт в другой продукт Google.
4. Пользователь снова перенаправляется в Google Accounts.
5. Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.

Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.

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

Аутентификация в соцсетях

Уверен, эта картинка знакома всем:

Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.

Формально социальный логин — это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.

Лучшее из двух миров

Пользователи могут войти в ваше приложение одним кликом, если у них есть аккаунт в одной из соцсетей. Им не нужно помнить логины и пароли. Это сильно улучшает опыт использования вашего приложения. Вам как разработчику не нужно волноваться о безопасности пользовательских данных и думать о проверке адресов почты — они уже проверены соцсетями. Кроме того, в соцсетях уже есть механизмы восстановления пароля.

Как использовать

Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth3 (некоторые используют OAuth2, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов, ваше приложение — клиент, а пытающийся войти в ваше приложение пользователь — владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).

Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.

Двухфакторная аутентификация (2FA)

Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.

Другой знакомый пример — двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включён этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищённым, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.

Вместо одноразового пароля в качестве второго фактора могут использоваться отпечатки пальцев или снимок сетчатки.

При двухфакторной аутентификации пользователь должен предоставить два из трёх:

• То, что вы знаете: пароль или PIN.
• То, что у вас есть: физическое устройство (смартфон) или приложение, генерирующее одноразовые пароли.
• Часть вас: биологически уникальное свойство вроде ваших отпечатков пальцев, голоса или снимка сетчатки.

Большинство хакеров охотятся за паролями и PIN-кодами. Гораздо труднее получить доступ к генератору токенов или биологическим свойствам, поэтому сегодня двухфакторка обеспечивает высокую безопасность аккаунтов.

То есть это универсальное решение? Возможно, нет.

И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.

Аутентификация или авторизация?

Некоторые путают термины «аутентификация» и «авторизация». Это разные вещи.

• Аутентификация — это проверка вашей личности. Когда вы входите в приложение с именем и паролем, вы аутентифицируетесь.
• Авторизация — это проверка наличия у вас доступа к чему-либо. Это может быть набор разрешений на какие-то действия. Например, если вы создали в приложении ресурс, то вы можете быть единственным, кому разрешено удалять этот ресурс (потому что вы владелец), а другие пользователи для того не «авторизованы».

Ещё тут?

Поздравляю, вы успешно дочитали длинную, нудную и скучную статью.

обзор форм авторизации и альтернативных способов идентификации пользователей — Офтоп на vc.ru

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

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

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

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

Истоки проблемы

Все мы не очень любим авторизацию через пароль. Чем больше сервисов мы используем, тем больше паролей приходится запоминать.

Приложения SaaS, социальные сети и другие службы требуют соблюдать строгие правила введения паролей, которые затрудняют вход в систему для честных пользователей. Неужели авторизация вида «имя пользователя и пароль» настолько незаменима, что мы готовы смириться с этим препятствием при использовании сервисов и продуктов?

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

Для этого уже есть несколько методов и постоянно появляются новые. Традиционную аутентификацию при помощи пароля можно сделать комфортной и удобной. Вот актуальные способы:

• имя пользователя и пароль;
• кодовая фраза;
• двухфакторная идентификация;
• социальный вход;
• беспарольная авторизация;
• биометрическая идентификация;
• подключенное устройство.

Я буду оценивать каждый метод, исходя из нескольких факторов:

• частота использования: легкость настройки и обслуживания;
• безопасность: сложность идентификации для постороннего человека;
• комфорт: простота идентификации для пользователя аккаунта.

Имя пользователя и пароль

Буду честен: у меня возникают проблемы с традиционной моделью. В идеальном мире я бы устранил пароли вообще, но в реальности я пользуюсь этим методом в 99% своих проектов.

Почему? Такая проверка подлинности — наиболее понятный способ авторизации, и люди будут считать его самым надежным. Можно многое улучшить с точки зрения удобства и простоты использования. Создание и восстановление паролей можно упростить, а вход в систему ускорить и сделать менее запутанным.

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

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

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

Ограничивать или исключать правила для паролей

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

Регистрация на сайте GoDaddy

В США и Великобритании 73% взрослых людей
используют на всех своих аккаунтах один и тот же пароль. Если ваши правила не дают пользователю использовать его стандартный пароль — он создает уникальный и, как правило, очень быстро его забывает. Исключив правила для паролей, вы даете пользователю возможность помнить пароль, чем повышаете юзабилити своего сервиса.

Зачем нам навязывают этот комплекс правил? Существуют исследования, которые утверждают, что длинные пароли эффективнее паролей с различными символами, но об этом я расскажу позже.

Напоминать пользователю о правилах

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

Авторизация на cайте BrowserStack

Именно эта модель безопасности долгие годы медленно меня убивает. Я гораздо тщательнее многих слежу за своими паролями, но всё равно их забываю. Если добавить такую форму напоминания в окно авторизации, это значительно увеличит юзабилити сайта и количество успешных авторизаций.

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

Это довольно распространенная опция, в особенности для мобильных устройств, но стоит применять ее повсеместно (включая рабочие компьютеры).

Если кто-то использует функцию общего доступа к экрану или проводит презентацию, можно спрятать символы при вводе пароля, но таких пользователей единицы. Всем остальным удобнее видеть, какой пароль они набирают. Такой метод успешно применяют Yahoo и Sprint — это убедительно доказывает, что нам больше не нужно маскировать пароли.

Подсказки Люка Вроблевски

Люк Вроблевски написал отличный
обзор идей, как можно «открыть» пароль, и описал, как лучше интегрировать их. Он утверждает, что маскирование паролей — устаревшая практика.

Конкретизировать сообщение об ошибках ввода

Всегда сообщайте пользователю, если он ввел неправильное имя или неверный

lawyer_s_coursebook_cht

КУРСЫ АНГЛИЙСКОГО ЯЗЫКА АДВОКАТА

Поддержка серии TOLES — «Ведущие мировые экзамены по юридическому английскому языку»

Это первая часть захватывающей новой публикации «Учебник английского языка юриста». Это первая часть уникального учебника из десяти частей, предназначенного для студентов, изучающих юридический английский язык по всему миру, особенно тех, кто готовится к серии экзаменов TOLES. Книга разделена на легко управляемые разделы, каждый из которых посвящен жизненно важным навыкам современного юриста-международника.Он является разумной отправной точкой как для учителей, так и для студентов и рекомендуется для учащихся, которые более уверенно владеют общим английским языком, а также для тех, кто все еще развивает свои языковые навыки, изучая или практикуя право.

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

ПОЧЕМУ ЭТА ЮРИДИЧЕСКАЯ КНИГА НА АНГЛИЙСКОМ ЯЗЫКА ТАК УСПЕШНА?

Эта книга открывает новое направление «Английский язык как право».Он основан на консультациях с юристами-международниками относительно того, какие навыки практикующие юристы действительно должны приобрести в процессе изучения английского языка. Его уникальный стиль и подход — результат сотен часов преподавания с юристами и студентами юридических факультетов со всего мира. Эта книга:

• предполагает, что студенты или учителя не знают права или юридического английского языка. Он освежающе ясно объясняет юридический словарь.

• развивает навыки и уверенность в юридическом английском с реалистичной отправной точки.Он не просит учащихся начинать с задач, которые им недоступны.

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

• занимается сложными ключевыми вопросами, такими как коммерческие контракты и написание писем, в практической и всесторонней форме, необходимой международным юридическим фирмам.

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

• обновлено. В нем учтены недавние языковые реформы и предстоящие изменения в правовой системе Великобритании.

© Кэтрин Мейсон и Розмари Аткинс, 2007

ИЗОБРАЖЕНИЕ КНИГИ

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

Каждый из десяти разделов разделен на словарный раздел A (Foundation) и раздел B (высшее) по рабочим навыкам.Раздел A является жизненно важной подготовкой к целевым задачам, содержащимся в разделе B. Эта структура позволяет учащимся развивать навыки и уверенность, при этом всегда уделяя особое внимание точности.

В конце каждого раздела есть несколько упражнений в стиле экзаменов TOLES, которые проверяют словарный запас и навыки, описанные в этом разделе. Десять единиц в этой книге различаются по длине. Это по двум причинам. Во-первых, более сложные области обучения, такие как понимание контрактов, требуют больше объяснений и повторений, чем другие.Во-вторых, количество времени, затрачиваемого на каждую единицу, отражает ее актуальность для иностранных юристов.

Раздел А (Фундамент)

• Поддерживает студентов, готовящихся к экзамену TOLES Foundation.

• Знакомит учащихся с основным словарным запасом для выполнения реалистичных задач из раздела B.

• Включает полезные разделы «службы поддержки» для поощрения самостоятельности учащихся.

• Само по себе полезное учебное пособие для всей серии экзаменов TOLES.

Раздел Б (Высшее)

• Поддерживает студентов, готовящихся к сдаче экзамена TOLES Higher.

• Поощряет активное использование словаря, представленного в Модуле A.

• На основе реалистичных и стимулирующих задач.

• Включает в себя полезные банки предлогов и словосочетаний для эффективного обучения.

АВТОРЫ

Кэтрин Мейсон и Розмари Аткинс в настоящее время преподают юридический английский в Кембридже. Они оба имеют юридическое образование, а также являются опытными преподавателями английского языка как иностранного.Как команда, они провели обучение юридическому английскому языку для множества ведущих юридических фирм по всему миру, а также работали с персоналом таких организаций, как Британский совет и Европейский суд.

ДОПОЛНИТЕЛЬНАЯ СЕРИЯ

Экзамены TOLES являются лидерами мирового рынка юридических экзаменов по английскому языку. Многие организации уже представили своих кандидатов, в том числе Общество юристов Англии и Уэльса.

Если вы хотите узнать больше о TOLES и о том, как серия экзаменов может помочь вам и вашим студентам, обратитесь в офис TOLES по адресу info @ toles.co.uk.

Мы надеемся, что этот раздел книги окажется для вас полезным и вам понравится.

© Кэтрин Мейсон и Розмари Аткинс, 2007

Упражнение 2

Вставьте слово из ключевого словаря упражнения 1 в следующие предложения.

Упражнение 3

Вот список некоторых важных областей права.Прочтите, что говорят юристы, на следующей странице. Они говорят о своей работе. Подберите юриста с правильной областью права.

.

Кодекс ОСПС: 9 важных и обязательных элементов

11 сентября 2001 г. . Ты помнишь эту дату?

Это, друг мой, дата, которая оказала большое влияние на то, как мы управляем нашими кораблями. Это дата, которая привела к появлению кода ISPS.

Бьюсь об заклад, когда вы слышите о коде ISPS, вы думаете о таких местах, как Сомали и Нигерия. Но безопасность была проблемой для судоходства гораздо дольше, чем это.

ИМО разработала множество кодексов, правил и соглашений с момента своего создания в 1948 году.

Если не все, то большинство из этих соглашений было вызвано каким-то серьезным инцидентом. Например, код ISM появился из-за инцидента с «Вестником свободного предпринимательства». МАРПОЛ возник в результате инцидента в каньоне Торри. И, как всем известно, СОЛАС был разработан из-за печально известного падения Титаника.

Код

ISPS, вероятно, единственный код, который был разработан из-за инцидента не на море. Он был рассмотрен и разработан после теракта 11 сентября в США.

Итак, что именно требует от нас код ISPS. Давайте обсудим 10 элементов кода ISPS, о которых нам нужно знать.

1. План охраны судна

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

Кодекс ОСПС, часть A / 9.4 дает минимальные баллы, которые должны быть включены в план охраны судна.

План охраны судна должен быть одобрен государством флага судна или признанной организацией по безопасности (RSO) от имени государства флага.RSO обычно является классификационным обществом судна.

Обработка План безопасности судна на борту

План охраны судна должен храниться в шкафчике. Если он находится на открытом месте, это может привести к несоответствию во время проверки PSC или аудита ISPS.

Мастер и SSO не должны предоставлять доступ к SSP какой-либо внешней стороне. Доступ может быть предоставлен только сотруднику службы безопасности Компании и лицу, проводящему аудит безопасности.

Если какой-либо инспектор PSC запрашивает доступ к SSP, этот запрос следует вежливо отклонить.

Могут возникать ситуации, когда инспектор PSC считает, что существует несоответствие, связанное с безопасностью, и единственный способ доказать ему, что этого несоответствия не существует, — показать ему SSP.

В этих случаях главный / SSO может показать только тот раздел SSP, который требуется для доказательства несоответствия как недействительного.

2. Оценка охраны судна

Оценка безопасности судна — это первый шаг к разработке плана безопасности.

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

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

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

Вот в чем суть оценки безопасности корабля.

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

Оценка безопасности судна — это своего рода оценка риска безопасности судна.

Оценка безопасности судна призвана ответить на эти пять вопросов.

• Есть ли повод атаковать корабль?
• Какие основные операции на судне и районы подвержены нарушениям безопасности?
• Существуют ли какие-либо меры безопасности или процедуры?
• Каким образом можно атаковать корабль?
• Каковы вероятность и последствия такой атаки?

Оценка охраны судна является основой для разработки плана охраны судна.Офицер службы безопасности компании обязан провести первоначальную оценку безопасности судна.

Вот пример оценки безопасности корабля.

3. Судовой охранник

Код

ISPS требует, чтобы компания назначила офицера охраны судна. Член экипажа, назначенный SSO, должен пройти обучение безопасности, требуемое согласно STCW.

Основные обязанности судового охранника

• для реализации и поддержания всех элементов плана безопасности судна и
• для связи с сотрудником службы безопасности компании и сотрудником службы безопасности портового средства (PFSO) для всех мероприятий, связанных с безопасностью

Совершенно очевидно, что для реализации SSP на борту SSO должен сам знать о том, что SSP требует от SSO и экипажа судна.

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

Например, SSO должен знать

• процент багажных вахт на проходах, подлежащих проверке на каждом уровне безопасности
• Порядок действий при обнаружении на борту несопровождаемого багажа
• Зоны ограниченного доступа согласно программе самообучения
• Оборудование безопасности на борту и какое обслуживание требуется для этого
• Порядок и необходимый интервал тестирования судовой системы охранного оповещения

Одной из важных обязанностей SSO является проверка плана охраны судна.Идея обзора состоит в том, чтобы со временем сделать SSP устойчивым. SSO должна искать недостатки в SSP и указывать на них в обзоре SSP.

Некоторые компании могут иметь быстрый контрольный список для проверки плана безопасности судна. Даже если нет контрольного списка, SSO может проверить SSP в меру своих возможностей.

Например, SSO может обнаружить, что доступ, который должен быть ограниченной областью, не обозначен как ограниченная область в SSP.

Он может обнаружить, что нет четких инструкций, можно ли допустить на борт сотрудников службы безопасности порта с оружием.

Независимо от того, что SSO должно включать в SSP, чего нет, он может упомянуть об этом в своем обзоре SSP.

4. Сотрудник службы безопасности компании

Код ISPS

также требует, чтобы компания назначила сотрудника службы безопасности. Основные обязанности сотрудника службы безопасности компании —

.

• Провести оценку безопасности судна
• Разработать план охраны судна и представить его на утверждение
• обеспечить эффективное внедрение SSP на борту

Одной из важных обязанностей CSO является регулярное предоставление информации о безопасности SSO и судну.

5. Уровни безопасности

Код

ISPS устанавливает три уровня безопасности.

• Уровень безопасности 1
• Уровень безопасности 2
• Уровень безопасности 3

Уровень безопасности 1 требует минимальных мер безопасности и является нормальным уровнем безопасности, на котором должны работать все корабли и порты.

уровень безопасности 3 требует самых строгих мер безопасности.

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

Есть один часто задаваемый вопрос, связанный с уровнями безопасности. Вопрос в том, «Кто определяет уровень безопасности на борту»?

Кто определяет уровни безопасности на борту?

Когда судно находится в море, уровень безопасности устанавливается государством флага судна. Государство флага не может давать указания судну напрямую, но может делать это через CSO.

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

В порту судно должно иметь такой же уровень безопасности, как и порт. Перед прибытием агент сообщает все детали безопасности порта, а также сообщает уровень безопасности судна.

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

Теперь могут быть случаи, когда уровень безопасности корабля выше, чем порт, который он вызывает.В этом случае SSO должен проконсультироваться с CSO. CSO может посоветовать снизить уровень корабля без снижения мер безопасности.

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

CSO после консультации с flag может посоветовать сохранить более высокий уровень безопасности. В этом случае судно должно проинформировать порт о более высоком уровне безопасности.

6. Декларация безопасности

Как следует из названия, декларация безопасности — это декларация безопасности между двумя сторонами.Одна из сторон — собственное судно, а другая сторона может быть портом или другим кораблем.

Вопрос в том, когда нам нужна декларация безопасности и зачем нам декларация безопасности?

Давайте сначала ответим на вопрос «когда».

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

Кодекс

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

А вообще DOS нужно заливать при

• Судно эксплуатируется с более высоким уровнем безопасности, чем порт, который он вызывает
• Судно эксплуатируется с более высоким уровнем безопасности, чем другое судно, с которым оно совершает операции с
• Судно заходит в порт, в котором отсутствует план охраны портового средства. Это будет в случае, когда порт находится в стране, которая не ратифицировала код ISPS

.

• Судно выполняет операции с судном, флаг которого не ратифицировал Кодекс ОСПС и, следовательно, не имеет утвержденного плана охраны судна.

Другой вопрос, зачем вообще ДОС заливать.Как вы могли заметить в приведенных выше ситуациях, судно либо находится на более высоком уровне безопасности, либо имеет дело с портом или судном, которое не соответствует кодексу ISPS.

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

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

Во втором случае, когда порт или судно не соответствуют требованиям ISPS, нам необходимо сделать совместное заявление о том, что порт или другое судно будет выполнять некоторые обязанности по обеспечению безопасности в соответствии с декларацией безопасности.

Многие корабли или компании требуют, чтобы DOS выполнялась при каждой операции порта и корабля. Это не обязательно, и при этом мы просто тратим бумагу и энергию на что-то совершенно ненужное.

7. Учения и учения по обеспечению безопасности

Компания обязана разработать планировщик учений по безопасности, который должен охватывать все ситуации безопасности.

Эти упражнения могут включать в себя такие ситуации, как

• Угроза взрыва в порту / в море
• изменение уровня безопасности
• Обыск безбилетного пассажира или бомбы

Вся идея этих упражнений и упражнений состоит в том, чтобы проверить эффективность внедрения кода ISPS. Эти учения должны быть направлены на выявление разрыва между ожидаемыми результатами и фактическими показателями.

SSO должен вести записи всех учений по обеспечению безопасности, проведенных на борту.

8.Международный сертификат безопасности судна

Международный сертификат охраны судна — это установленный законом сертификат. Код ISPS применяется ко всем судам более 500 GRT. Кодекс ОСПС требует, чтобы эти суда имели действующий «Международный сертификат безопасности судна».

Но как судно может получить «Международный сертификат безопасности судна» (ISSC)?

Новый строительный корабль или корабль, который меняет флаг или класс, получит промежуточный ISSC. Промежуточный ISSC будет выдан после проверки государством флага или RSO (обычно классом), что все элементы SSP реализованы на борту.

Промежуточный ISSC действителен в течение шести месяцев.

Выдается полный ISSC

• после внедрения SSP не менее 30 дней
• Успешный аудит ISPS был проведен флагом или RSO от имени флага

Полный срок действия ISSC действителен в течение 5 лет при условии промежуточной проверки и подтверждения флагом или RSO от имени флага.

9. Судовая система оповещения о безопасности

Одним из основных средств безопасности на борту, требуемых кодексом ISPS, является судовая система оповещения.

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

Обычно при нажатии кнопки SSAS предупреждение переходит в состояние флага и CSO. Но в некоторых государствах флага может потребоваться, чтобы оповещение принималось только CSO.

Судовая система охранного оповещения (SSAS) должна проверяться не реже одного раза в год.

Процедура проверки приведена в SSP. SSO должен знать эту процедуру тестирования.

Заключение

Код

ISPS, возможно, не смог положить конец инцидентам безопасности по всему миру. Но он определенно заложил основу для сдерживания проблем безопасности во всем мире.

Это сдерживание будет эффективным только в том случае, если мы будем знать и эффективно применять все элементы кодекса ISPS.

.

Типы недостатков PSC и как с ними бороться?

Позвольте мне начать с этого вопроса.

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

Если да, то этот пост не для вас.

Это потому, что если нет недостатков PSC, то и обрабатывать нечего.

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

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

Во всяком случае, вы можете получить дефицит PSC, на который вы не можете согласиться.

Но вопрос не в этом.

Вопрос в том, какие действия следует предпринять персоналу судна (особенно капитану), чтобы избежать задержек на судне после выявления недостатка PSC.

Начнем.

Чтение акта государственной инспекции порта

После завершения государственной проверки порта капитану судна предоставляется отчет о проверке.

По крайней мере, мастер должен проверить эти три вещи перед подписанием.

• Название судна и дата проверки

• Если судно задержано из-за выявленных недостатков.

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

Вот формат отчета PSC MOU Индийского океана.

А вот формат отчета PSC Парижского меморандума о взаимопонимании.

Независимо от формата отчета о проверке капитан должен найти и проверить эти три части информации в отчете на предмет их правильности.

Отчет PSC без недостатков

Что может быть более удовлетворительным, чем выполнение проверки PSC с нулевыми недостатками?

После проверки PSC с недостатком NIL капитан должен подать отчет в соответствии с файловой системой компании.

Капитан может также потребовать сохранить отсканированную копию отчета об инспекции в электронной системе управления документами судна.

Если компания подписалась на Q88, для мастера разумно обновить базу данных Q88, указав последнюю дату проверки PSC.

Даже если проверка не выявила никаких недостатков, капитан должен проинформировать береговый офис о проверке PSC.

Кроме этого, никаких других действий, необходимых для проверки PSC, не требуется.

Отчет PSC с недостатками

Если в результате проверки PSC были обнаружены некоторые недостатки, в форме A отчета PSC будет отмечено «да».

Все выявленные недостатки будут затем описаны в Форме B отчета PSC, который будет приложен к «Форме A».

Код действия

предоставляется для каждого отмеченного недостатка в форме B отчета о проверке PSC.

Для каждого недостатка будет один или несколько кодов действий.

• Код 10: Недостаток устранен
• Код 15: Устранить неисправность в следующем порту
• Код 16: Устранить недостаток в течение 14 дней
• Код 17: Устранить неисправность перед вылетом
• Код 18: Устранить недостаток в течение 3 месяцев
• Код 30: обнаруживаемая недостаточность
• Код 40: проинформирован следующий порт
• Код 45: устранение задерживаемой неисправности в следующем порту 50. Государство флага / консул проинформированы
• Код 55: консультация государства флага
• Код 70: признанная организация проинформирована
• Код 85: расследование нарушения положений о сбросе (МАРПОЛ)
• Код 99: Другое

Устранение недостатков

Я всегда считаю, что найти дефект труднее, чем исправить его.

Таким образом, как только недостаток обнаружен, исправить его несложно.

Но вопрос в том, кто должен одобрить устранение выявленного недостатка?

Достаточно ли заявления капитана о том, что «неисправность устранена»?

Нужно ли инспектору PSC повторно посещать судно для подтверждения исправления?

Или это класс, которому необходимо проверить устранение недостатка?

Ну, все будет зависеть от

• Государственный контроль порта и / или Меморандум о взаимопонимании с государственными предприятиями
• Вид и область дефекта

Например, для большинства недостатков USCG требует, чтобы классификационные общества подтвердили, что недостаток был устранен.

Я видел в российских портах, что инспектор PSC совершал повторный визит, чтобы убедиться в закрытии дефекта.

И, наконец, в большинстве китайских портов заявления мастера считается достаточным для устранения большинства недостатков.

Как правило, все недостатки, связанные с оборудованием и конструкцией судна, должны быть устранены классификационным обществом судна.

В этом случае классификационное общество выдает судну «состояние класса» и закрывает его после устранения дефекта.

Поскольку различные органы государственного портового контроля могут иметь разные способы устранения недостатков, капитану целесообразно уточнить это у инспектора PSC.

Рассмотрение недостатков PSC как несоответствий

Процедуры большинства компаний требуют, чтобы любой недостаток PSC рассматривался как несоответствие.

Процедуры компании по устранению несоответствий должны соблюдаться для устранения недостатков PSC.

Процедура устранения недостатка PSC будет такой же, как и устранение любого несоответствия в соответствии с руководствами по СУБП.

На танкерах, рассматривающих наблюдение PSC как несоответствие, является требованием согласно SIRE.

Недостатки кода 17

Недостатки кода 17

являются наиболее частыми недостатками во время проверок PSC.

Все недостатки с кодом 17 необходимо устранить перед вылетом.

И наиболее частая область сомнений заключается в том, нужно ли сотрудникам PSC повторно посетить, чтобы убедиться, что недостаток кода 17 был исправлен?

PSC в одном порту может потребовать повторного посещения для проверки, а в других портах это может не потребоваться.

Капитан судна должен уточнить у инспектора PSC, требуется ли повторная проверка или нет.

Если требуется повторная проверка, мастер должен проинформировать PSC через агента после устранения недостатка.

После повторной проверки мастер должен убедиться, что все недостатки кода 17 были отмечены кодом 10, что означает, что недостаток был исправлен.

Независимо от того, требует ли PSC повторная проверка закрытия, важно, чтобы любой недостаток кода 17 был исправлен до того, как судно покинет порт.

Судно, которое выходит из порта без устранения недостатка кода 17, считается непригодным для плавания. Выход в море непригодного для плавания корабля может иметь серьезные последствия для капитана корабля.

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

Электронная почта может быть примерно такой.

Недостатки, кроме кода 17

Недостатки

Code 17 требуют быстрых действий.Недостатки необходимо устранить перед выходом из порта.

Но это не относится к другим недостаткам, таким как код 15 (должен быть исправлен перед отправлением из следующего порта) или код 18 (должен быть исправлен в течение 3 месяцев).

Хотя период времени для устранения недостатка различается для каждого из этих недостатков, процесс одинаков.

Например, при недостатке кода 15 капитан должен послать подтверждение о закрытии из-за недостатка до отхода из следующего порта.

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

Устраняемые недостатки

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

Обычная путаница — это то, что делает недостаток кода 17 задерживаемым недостатком.

Например, является ли «Сарт не работает» недостатком кода 17 или недостатком, который может быть задержан?

Ну, грань, отделяющая недостаток кода 17 от недостатка, который можно задержать, тонкая, но должностному лицу государства порта не так сложно определить.

Процедура, используемая для выявления задерживаемого недостатка, предоставлена ​​должностным лицам государства порта в справочнике PSC Меморандума о взаимопонимании.

Например, для Парижского меморандума о взаимопонимании ниже приведены основные критерии, по которым ИКГП принимает решение о задержании судна.

• суда, которые небезопасны для выхода в море, будут задержаны при первой проверке независимо от времени простоя судна в порту;
• , судно будет задержано, если недостатки на судне достаточно серьезны, чтобы заслужить, чтобы ИКГП вернулся на судно, чтобы убедиться, что они были исправлены до отплытия судна.

В справочнике Парижского меморандума о взаимопонимании для инспекторов ЧОК также указаны области недостатков, которые могут считаться основанием для задержания.

Например, ниже приведены недостатки в соответствии с СОЛАС, которые можно рассматривать как основание для задержания.

Это всего лишь рекомендации. Недостаток в любой из этих областей не означает, что судно будет задержано.

Давайте, например, рассмотрим этот критерий.

отсутствие, несоответствие или серьезное повреждение огней, форм или звуковых сигналов

Означает ли это, что судно будет задержано, если один из навигационных огней будет обнаружен неработающим?

Абсолютно нет.

А что, если ни одна из лампочек не работает. Тогда есть что-то серьезное в недостатке, и, скорее всего, судно будет задержано.

Порядок задержания судна

Если ИКГП решает задержать судно, он направит капитану уведомление о задержании.

ИКГП также направит уведомление о задержании флагу судна и классификационному обществу судна.

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

Капитан должен подтвердить в компании, если судно должно сообщить государству флага.

Апелляционные процедуры

Если капитан / компания считает, что судно было задержано необоснованно, компания может отправить уведомление об апелляции в PSC.

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

Вопреки распространенному мнению, флаг или судовладелец нередко подают апелляцию против задержания судна.

Совершенно верно.

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

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

Кроме того, имидж бренда компании сильно пострадал. База данных по судам и компаниям с очень низкими показателями эффективности публично размещена на веб-сайтах большинства Меморандумов о взаимопонимании PSC.

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

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

Апелляция необязательно должна быть направлена ​​на несогласие с недостатком. Апелляция также может быть подана, если владельцы или флаг считают, что недостатком должен был быть код 17, а не задерживаемый недостаток.

Например, вот случай, когда государство флага не согласилось с задержанием судна.

Устранение недостатков содержания под стражей

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

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

Например, если недостаток связан с МАРПОЛ, нам необходимо знать, связан ли недостаток с дефектным оборудованием или наблюдением, связанным с сертификацией или документацией.

В этом помогает

кодов недостатка PSC.

Допустим, что недостаток связан с расширенной программой обследования, и PSC предоставил код недостатка как 01315.

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

Еще одна вещь, о которой мы должны помнить, касается недостатков содержания под стражей, связанных с ISM и ISPS.

Задержания из-за недостатков, связанных с ISM и ISPS, закрываются только после внешних аудитов ISM и ISPS.

Опять же, их можно определить по кодам дефектов.

Позвольте мне прояснить возможные недостатки, связанные с ISM, на примере.

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

Не всегда.

Возьмем для примера недостаток, связанный с неработающими пожарными извещателями в жилых помещениях.

Один неработающий пожарный извещатель будет иметь код 17. Недостаток будет под кодом 07106, и его необходимо исправить перед вылетом.

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

Дефицит снова будет под кодом 07106.

Поскольку судно будет задержано, ИКГП поднимется на борт судна, чтобы убедиться, что пожарные извещатели исправлены.

Как только ИКГП будет удовлетворен, постановление о задержании будет снято, и судну будет разрешено отплыть.

Теперь давайте рассмотрим эту последнюю ситуацию, когда, скажем, обнаружено, что 10 или более пожарных извещателей не работают. Излишне говорить, что это будет дефект, подлежащий задержанию по коду дефекта 07106.

Но это также создает впечатление у инспектора государства порта, что код ISM не применяется эффективно на борту.

Как?

Потому что, будь он эффективен, неисправные пожарные извещатели были бы обнаружены в ходе последних еженедельных тестов.

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

В этом случае ИКГП выдал бы второй задерживаемый недостаток, связанный с кодом ISM, который может быть чем-то вроде…

Код ISM внедряется неэффективно, поскольку, по всей видимости, еженедельные проверки пожарных извещателей не проводятся.

Таким образом, одно наблюдение может привести к двум задержкам.

И, как я упоминал ранее, недостатки, не относящиеся к ISM, необходимо устранить, исправив отмеченное наблюдение или дефект.

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

Заключение

С годами время простоя судов в порту резко сократилось, что дает меньше времени персоналу судна для устранения недостатков PSC, выявленных во время инспекций PSC.

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

.