Переписавши (15.21) інакше, отримаємо формулу Андерсена

(15.22)

Якщо R, N_СИМ, t_{ВІДКР.ПАР} і A фіксовані, то кожне значення S (довжина пароля) буде давати різну ймовірність Р правильного його відгадування. Тоді для побудуви системи, де незаконний користувач мав би ймовірність відгадування правильного пароля не більшу, ніж Р, варто вибрати таке S, що задовольняє виразу (15.22).

Приклад. Припустимо, що ми хочемо, використовуючи стандартний англійський шрифт, встановити такий пароль, щоб ймовірність його відгадування була не більшою 1/1000 (0,001) після тримісячного систематичного тестування. Припустимо, що швидкість передачі по лінії зв'язку 60·10⁶ симв/хв і що за одну спробу посилається 20 символів. Використовуючи співвідношення (15.22), отримуємо

Для S=6 отримаємо 26^S=3,089·10⁸, і для S=7 – 26⁷=8,03·. Отже, за даних обставин нам варто вибрати S=7.

Як бачимо, на ймовірність Р розкриття пароля робить вплив величина S. Збільшення довжини пароля тільки на один символ значно збільшує час, необхідний зловмисникові для розкриття цього пароля при систематичних спробах, організованих за допомогою ЕОМ. Так, якщо при відповідних умовах очікуваний безпечний час для семисимвольного пароля, обраного з 36-символьного алфавіту, складе близько 9 діб, очікуваний безпечний час для восьмисимвольного пароля складе 11 місяців.

Недоліком схеми з простим паролем є те, що пароль може бути легко використаний іншою особою без відома зареєстрованого користувача (аж до кінця терміну дії пароля, коли йому буде запропоновано поновити пароль). Одним зі шляхів рішення цієї проблеми є видача системою на термінал користувача кожен раз, коли він спілкується із системою, чергового номера, за яким зареєстроване його звертання до системи на даний день і тривалість роботи. Крім того можна вивести також поточний рахунок на даний момент часу. Якщо за цей час хто-небудь скористався чужим рахунком, пильний користувач зможе це знайти.

Звичайно, якщо декільком користувачам приписаний той самий номер користувача, ця схема стає непрактичною. Але звичайно так не робиться. Практика забезпечення таємності вимагає, щоб кожному користувачеві було задано унікальне ідентифікаційне число для забезпечення безпеки. Якщо для проведення розрахунків (або інших цілей) користувачів із системою більш бажано використовувати номери підрозділів або номери проектів, то їх можна запитувати в процесі впізнання разом з ідентифікаторами користувача або робити більш дрібні розрахунки, наприклад окремо для кожного користувача.

Дата добавления: 2014-01-04