Атаки и уязвимости презентация

аудит
Безопасность разработки. 
Безопасность веб приложений.

фраз)
<= 20 символов только из букв – слабые
Считать все символы, чувствительные к регистру
Не разрешать подряд больше двух одинаковых
Ясно указывать и неразрешать установить слабый пароль

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

бд
HMAС SHA 256

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

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

ID
Неверный пароль
По коду ошибки
Блокировать после нескольких попыток

ID (private)
SAML (enterprise)
FIDO: UAF+U2F (PKC) – защита от фишинга, хранение ключа на устройстве, hardware token, biometry

токена, защита ID сессии

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).

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 для шифрования диска
Шифрование работает независимо от доступа к паролям

управление ключами
Ключи хранятся в обособленном хранилище
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"). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested 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)
Аудит, логи
Генерация ключей

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

сессии при закрытии окна броузера
Аудит и ведение лога
Одновременный вход одного пользоваиекоя

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