А я бы посмотрел на это с другой стороны: имеет ли отправитель устное/письменное/конклюдентное согласие получателя — это проблема отправителя, а не автора системы. Так что автор системы по такой схеме именно закроется от Регулятора, вписав в договор фразу вида «Отправитель гарантирует, что распоряжается персональными данными получателя на законных основаниях и имеет право поручать их обработку сайту».
Я не юрист, хотя на меня постоянно пытаются «взвалить» и юридическую составляющую процесса исполнения 152-ФЗ.
Попробуйте вступить в переписку с Алексеем Волковым: anvolkov.blogspot.ru/ или Дмитрием Кузнецовым: malotavr.blogspot.ru/. Они оба — весьма увлекающиеся нестандартными ситуациями в 152-ФЗ люди и серьезные специалисты, на письма отвечают охотно и дружелюбно.
P.P.S. Я знаю много случаев успешного прохождения проверок на базе конклюдентного согласия, но у нас в фирме «перестраховываются» и берут письменное. Благо, с клиентом общение происходит лично.
Тогда у Вас challenge формируется фактически клиентом, а значит перехватив однажды пару challenge-response от валидного сеанса, злоумышленник сможет повторить microtime в момент инициализации, а потом успешно пройти проверку, не зная фактически пароля. («replay attack»)
Для Вашего случая фиксированной длины challenge-а можно один раз (но обязательно пароль должен стоять спереди от challenge), собственно получается htdigest, упомянутый выше.
А в общем случае, при создании MAC (message authentication codes) на основе хеш-функций, парольная или ключевая информация применяется дважды — спереди и сзади — для защиты от разных угроз (подробнее посоветовал бы прочесть у Менезеса в п.9.5.2).
1. Сервер генерирует достаточно длинную случайную строку challenge — единственно требование — она не должна никогда повториться, поэтому в нее обычно добавляют текущее время.
2. Сервер направляет challenge клиенту по открытому каналу.
3. Клиент вычисляет response = MD5( password || challenge || password ).
4. Клиент направляет response серверу по открытому каналу.
5. Сервер по имеющемуся у него «истинному» паролю клиента также вычисляет response' = MD5( password || challenge || password ) и сверяет response=response'
В сухом остатке:
а) пароль не передавался по открытому каналу
б) вычислить корректный response не зная password невозможно в силу свойств хеш-функции
в) отправить повторно старый response на challenge нельзя, т.к. он (challenge) никогда не повторяется.
Предлагаю сначала включить 7-ой уровень логов в настройках EasyVPN Client-а и посмотреть, доходят ли пакеты DPD до Вашего ПК за эту минуту подключенности и отвечает ли Ваш ПК на них.
Если нет трафика, то раз в 20 секунд ASA начинает посылает DPD-пакеты.
Если клиент не ответит, на 2 из них, то будет отключен.
Это как раз 60 секунд.
Ищите, почему не доходят DPD либо ответы на них.
Поддерживаю. Люблю щелкать город в такой проекции когда объект, отстоящие друг от друга на километры, кажутся находящимися рядом и имеют одинаковый масштаб. Пространство «исчезает».
Сейчас (с октября 2011 до 1 июля 2013-го) регулируется сразу двумя ФЗ: 1-ФЗ и 63-ФЗ.
Более того, есть очень интересная коллизия о том, что на этот период любая подпись, созданная по 1-ФЗ считается квалифицированной в терминах 63-ФЗ, т.е. принимается везде, кроме ряда узких случаев.
Но это продлится недолго.
