Атаки и уязвимости

1. Лекция 7

Атаки и уязвимости

2. Пройденные темы

Аутентификация
Токенизация и управление сессией
Управление ключами и криптография
Авторизация
Протоколы TLS и Oauth

3. Оставшиеся темы

• Безопасность приложений: anti-tampering
software, anti-subversion, intrusion detection.
• Мониторинг, анализ действий
пользователя, аудит
• Безопасность разработки.
• Безопасность веб приложений.

4. Тестирование аутентификации

• Имена пользователей
• Корректная проверка e-mail
• Использование сильных паролей
–
–
–
–
–
–
>=10 символов
<=128 (чтобы не создавать фраз)
<= 20 символов только из букв – слабые
Считать все символы, чувствительные к регистру
Не разрешать подряд больше двух одинаковых
Ясно указывать и неразрешать установить слабый
пароль

5. 3 из 4

Нижний регистр
Верхний регистр
Особый символ
Цифра
Правила упомянуты на странице смены
пароля

6. Процедура забытого пароля

• Хороший вопрос – универсальный,
запоминаемый, постоянный, безопасный
• Отправка по стороннему каналу
• Безопасное хранение. Пояснять.
• Минимальная длина ответа
• Периодический просмотр
• Аутентификация для смены вопроса
• Устаревание сессии, не менять сессию
• Два набора вопросов
• Устаревание набора вопросов

7. Хранение пароля

• Использовать PBKDF2, bcrypt, scrypt
• Соль (генератор), PBKDF2(cоль, пароль) –
запись в бд
• HMAС SHA 256

8. TLS для аутентификации

• Использовать только TLS для страницы логина
и последующих:
– Атака на страницу логина - данные могут быть
переданы
– Атака на ID сессии – сессия может быть
скомпрометирована
• Взаимный обмен сертификатами у клиента и
сервера при рукопожатии (испольщуется
постоянный компьютер, комптютер
организации и пользователь не боится
сертификатов)

9. Дополнительно

• Для избежания CSRF, clickjacking, session
hijacking – требование переаутентификации
про каждом важном действии (смена
пароля установка адреса покупка и тд) –
атака на ID сессии
• Многофакторная аутентификация – знать,
иметь, быть
• OTP + hardware token

10. Сообщения об ошибках и блокировка

• Не давать инфо об статусе пользователя:
– Устарел
– Блокирован
– Неверный ID
– Неверный пароль
– По коду ошибки
• Блокировать после нескольких попыток

11. Сторонние приложения (аутентификация без пароля)

• Использовать Oauth для аутентификации
(1.0а или 2.0)
• Open ID (private)
• SAML (enterprise)
• FIDO: UAF+U2F (PKC) – защита от фишинга,
хранение ключа на устройстве, hardware
token, biometry

12. Дополнительно

Доступ к истории
Логины по умолчанию
Выход из аккаунта
Запоминание пользователя
CAPTCHA

13. OWASP

• Authentication:
https://www.owasp.org/index.php/Authentica
tion_Cheat_Sheet
• https://www.owasp.org/index.php/Choosing_
and_Using_Security_Questions_Cheat_Sheet
• http://goodsecurityquestions.com/

14. Управление сессией

• Требовать подтверждение (clickjacking)
• Генерация токена для защиты от
CSRF(криптографически или случайно)
• Защита токена, защита ID сессии

15. Transaction authentication

Users should be able to easily distinguish the authentication process from the transaction authorization process
Malware can trick users in authorizing fraudulent operations, when an application requires a user to perform the
same actions for authentication as for transaction authorization. Consider the following example:
An application is using the same method for user authentication (usually as a second factor to traditional
login/password) and for transaction authorization. E.g. by using a OTP token, Challenge-response codes, operation
signing using external smartcard, ...
A malware may present the user a false error message after the first step (authentication to the application) and
trick the user into repeating the authentication procedure. The first authentication code will be used by the
malware for authentication, whereas the second code would be used to authorize a fraudulent transaction. Even
challenge-response schemes could be abused using this scenario as malware can present a challenge taken from a
fraudulent transaction and trick the user to provide response. Such an attack scenario is used widely in malware
attacks against electronic banking.
In the abovementioned scenario, the same method was used to authenticate the user and to authorize the
transaction. Malware can abuse this behaviour to extract transaction authorization credentials without the user’s
knowledge. Social engineering methods can be used despite utilized authentication and operation authorization
methods but the application shouldn’t simplify such attack scenarios.
Safeguards should allow the user to easily distinguish authentication from transaction authorization. This could be
achieved by:
using different methods to authenticate and to authorize,
or using different actions in an external security component (e.g. different mode of operation in CAP reader),
or presenting the user a clear message about what he/she is “signing” (What You See Is What You Sign Principle).

16. Криптографическое хранение данных

• Архитектура и дизайн
• CCM, GCM – аутентифицированное шифрование (AES+time+message
ID)
• NIST approved algorithms
• ISO TR 14742 "Recommendations on Cryptographic Algorithms and their
use" or Algorithms, key size and parameters report – 2014
• AES 256, RSA 3072, SHA 256
• Режимы шифрования AES – CCM, GCM, CBC+HMAC
• Библиотека – FIPS 140-2
• Не реализовывать
• Сильный пароль для хранения ключейб хранить пароли защищенно
• Генератор псевдослучайных NIST RNG Test tool
• Разные ключи для разных данных
• XTS для шифрования диска
• Шифрование работает независимо от доступа к паролям

17. Управление ключами

Устаревание ключей
Безопасное хранение ключей (доступ)
Ключи отдельно от данных
Ключи генерируются независимо
Документировтаь управление ключами
Ключи хранятся в обособленном хранилище
1-3 года – обновление ключей
PCI DSS requirement 3 – хранение PAN
– Cryptography based on industry-tested and accepted algorithms, along with strong key lengths
and proper key-management practices. Cryptography is a method to protect data and includes
both encryption (which is reversible) and hashing (which is not reversible, or "one way"). SHA1 is an example of an industry-tested and accepted hashing algorithm. Examples of industrytested and accepted standards and algorithms for encryption include AES (128 bits and
higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and
higher), and ElGamal (1024 bits and higher).
KEK(master key)
Аудит, логи
Генерация ключей

18. Транспорт ключа

• Протокол – Диффи Хеллман+сертификаты
• Транспорт – TLS (не SSLv3)
• Разделенное хранение

19. Криптомодуль

• Проверен сертифицирован
• Функции, доступ к ним и хранилище

20. Session Management

ID сессии – 128 бит, случайно, криптографически
Встроенное управление вместо своего
Secure Cookies (Id по зашифрованному каналу)
encrypted HTTPS (SSL/TLS) connection
Различные хосты и соединения для защищенных и
незащищенных данных
• SSL/TLS (HTTPS) does not protect against session
• ID prediction, brute force, client-side tampering or
fixation. Yet, session ID disclosure and capture from the
network traffic is one of the most prevalent attack
vectors even today

21. Cookies

Httponly
Encrypted
Указывать домен и путь
Устаревание

22. Устаревание сессии

• В режиме простоя
• Обновление или абсолютное устаревание
• "Cache-Control: no-cache,no-store« and
"Pragma: no-cache«
• Закрытие сессии при закрытии окна броузера
• Аудит и ведение лога
• Одновременный вход одного пользоваиекоя

23. AC

• Implement role based access control to assign permissions to
application users for vertical access control requirements
• Avoid assigning permissions on a per-user basis
• Perform consistent authorization checking routines on all
application pages
• Where applicable, apply DENY privileges last, issue ALLOW
privileges on a caseby-case basis
• Where possible restrict administrator access to machines located
on the local area network (i.e. it’s best to avoid remote
administrator access from public facing access points)
• Log all failed access authorization requests to a secure location for
review by administrators
• Perform reviews of failed login attempts on a periodic basis

24. Best practices

• Централизованный контроль
• Проерять авторизацию всех запросов
• Проверять данные пользователя