Все-таки на крытых парковках вроде той, что на вашем фото гораздо удобнее видеть свободные места, обозначенные горящей зеленой лампочкой сверху. В некоторых торговых центрах встречал такую систему, где над каждым парковочным местом датчик занятости с таким индикатором.
Для открытых уличных парковок ваш вариант выглядит конечно более жизнеспособным.
Сервис Have I Been Pwned? известного специалиста по безопасности Троя Ханта позволяет проверить, нет ли в утечках пароля, ассоциированного с вашим почтовым адресом.
Несколько месяцев назад подписал свой email на проверку в базе утечек. Это действительно удобно, чем отслеживать все новости и искать себя в списке. Жаль только, что информация об утечках на этом ресурсе появляется с некоторой задержкой. Например, Рамблера там пока нет.
Пока CVV используется не так часто, как PIN, пользователи не будут его помнить. В нужный момент, просто не смогут что-то купить в интернете. Есть другое решение: карты с динамическим CVV (Data Sheet).
В приложении Рокетбанка для Android был такой баг: когда переходишь в галерею для прикрепления фотографии в чате с техподдержкой или просто открываешь квитанцию, то если просто заблокировать телефон, то следующий запуск приложения не требует ввода пин-кода. Видимо фокус терялся и приложение просто не блокировалось.
Я сообщил об этом сначала в техподдержку, а потом по контактному email с сайта. Олег Козырев (ну или это просто подпись такая у почтового ящика) ответил, что не считает это уязвимостью. Тем не менее через несколько месяцев меня проинформировали, что баг закрыт.
я имею в виду, что если бы браузер мог в своем интерфейсе отображать QR(данные_полученные_от_сервера+URL/domain), то выводить QR на самой станице не надо было бы. То есть это конечно возможно, если станет стандартом.
Например, рядом с адресной строкой предусмотреть поле для QR, при наведении мышкой на которое отображается QR.
Такой атаке подвержены и простой пароль и одноразовый.
Защитой от фишинга может быть, если браузер будет генерировать QR на основании информации, полученной от сервера и текущего URL или доменного имени.
Пароль — 1-ый фактор — то, что пользователь знает
Код из SMS — 2-ой фактор — то, что пользователь имеет. Правильно введенный код из SMS подтверждает владение SIM картой с номером телефона, зарегистрированного на пользователя.
Полагаю, что вопрос в терминологии «двухфакторная» или «двухэтапная» не в самом методе аутентификации, а в реализации. Если второй фактор у вас спрашивается только после успешно введенного первого, то это двухэтапная, а если оба фактора проверяются одновременно, то двухфакторная.
А если у вас лучше с памятью, чем со скоростью вычислений, то выбирайте HOTP. Нужно будет помнить еще и текущее положение счетчика, но зато времени на вычисление уйма.
Цифровая подпись (Digital Signature) — это часть документа, зашифрованная Приватным ключем Подписчика (Issuer)
Обычно шифруется хэш документа. Если шифровать часть документа, то и обеспечить получится только целостность этой части документа.
Выбирается сообщение для шифровки (Message). Что именно шифровать, определяет алгоритм и версия SSL. Для конечного пользователя это неважно, так как все версии шифрования и хэширования также помещаются в сертификат, и при расшифровке эти же версии и используются.
Откуда у вас такая странная информация про создание самоподписанного сертификата? На всякий случай я посмотрел все ссылки, что у вас в источниках, но, к счастью, ничего подобного там не нашел.
По моему, интересная идея.
Можно действительно использовать любой текстовый редактор, чтобы реализовать удобный интерфейс. Открываешь редактор, нажимаешь хоткей и в блокноте быстро печатается интерфейс Пастильды с блэкджеком и псевдографикой. На несколько строчек со структурой, подсказками и пр.
Чтобы пакеты полетели из DMZ в сторону LAN нужно, чтобы маршрутизатор/файрвол их пропускал. Если брать классический файрвол, то вам нужно писать 2 правила: в одну и в другую сторону. Условно как-то так:
allow from LAN-server_IP to DMZ-server_IP TCP port xxxx
allow from DMZ-server_IP to LAN-server_IP TCP port yyyy
Видимо, вы работали с файрволом, который сам видит, какое соединение открывается по разрешенному в одну сторону правилу и автоматически пропускает пакеты в обратную сторону. То есть в нем прописано только первое правило, но фактически, как только сервер из LAN поднял VPN, на файрволе разрешен трафик и от сервера в DMZ до сервера в LAN по конкретному порту. А это равносильно тому же правилу на файрволе.
Туннель позволяет не открывать порт на сервере и не делать правила на межсетевом экране (проброс портов). Зачем это нужно ответил в статье.
Если я правильно понимаю, то у вас создастся динамическое правило на маршрутизаторе пропускающее трафик из DMZ в LAN, как только сервер из LAN попытается создать туннель до сервера в DMZ.
Чем это правило лучше статического правила на такой же пропуск трафика от сервера в DMZ к серверу в LAN?
Добавил, потому что Access Gateway это все-таки один фронт-энд для разных ресурсов, в т.ч. для тех которые не предполагают наличие фронт-энда. Это сокращает количество серверов, торчащих наружу.
К тому же, если он обеспечивает централизованную аутентификацию, то решается вопрос с разными логинами/паролями от разных систем. Проходишь аутентификацию на единой точке входа, а дальше работает SSO для доступа к бэк-энд ресурсам. И не надо аутентифицироваться отдельно на каждом ресурсе. Плюс можно настроить многофакторную аутентификацию к ресурсам, которые сами по себе это не поддерживают.
Поэтому с точки зрения ИБ этот вариант отличается от публикации разных фронт-эндов от разных приложений.
Для открытых уличных парковок ваш вариант выглядит конечно более жизнеспособным.
Несколько месяцев назад подписал свой email на проверку в базе утечек. Это действительно удобно, чем отслеживать все новости и искать себя в списке. Жаль только, что информация об утечках на этом ресурсе появляется с некоторой задержкой. Например, Рамблера там пока нет.
Интересно было бы знать, кому еще помогает Milfgard.
Я сообщил об этом сначала в техподдержку, а потом по контактному email с сайта. Олег Козырев (ну или это просто подпись такая у почтового ящика) ответил, что не считает это уязвимостью. Тем не менее через несколько месяцев меня проинформировали, что баг закрыт.
Например, рядом с адресной строкой предусмотреть поле для QR, при наведении мышкой на которое отображается QR.
Защитой от фишинга может быть, если браузер будет генерировать QR на основании информации, полученной от сервера и текущего URL или доменного имени.
Код из SMS — 2-ой фактор — то, что пользователь имеет. Правильно введенный код из SMS подтверждает владение SIM картой с номером телефона, зарегистрированного на пользователя.
Полагаю, что вопрос в терминологии «двухфакторная» или «двухэтапная» не в самом методе аутентификации, а в реализации. Если второй фактор у вас спрашивается только после успешно введенного первого, то это двухэтапная, а если оба фактора проверяются одновременно, то двухфакторная.
Обычно шифруется хэш документа. Если шифровать часть документа, то и обеспечить получится только целостность этой части документа.
Откуда у вас такая странная информация про создание самоподписанного сертификата? На всякий случай я посмотрел все ссылки, что у вас в источниках, но, к счастью, ничего подобного там не нашел.
Можно действительно использовать любой текстовый редактор, чтобы реализовать удобный интерфейс. Открываешь редактор, нажимаешь хоткей и в блокноте быстро печатается интерфейс Пастильды с блэкджеком и псевдографикой. На несколько строчек со структурой, подсказками и пр.
allow from LAN-server_IP to DMZ-server_IP TCP port xxxx
allow from DMZ-server_IP to LAN-server_IP TCP port yyyy
Видимо, вы работали с файрволом, который сам видит, какое соединение открывается по разрешенному в одну сторону правилу и автоматически пропускает пакеты в обратную сторону. То есть в нем прописано только первое правило, но фактически, как только сервер из LAN поднял VPN, на файрволе разрешен трафик и от сервера в DMZ до сервера в LAN по конкретному порту. А это равносильно тому же правилу на файрволе.
Если я правильно понимаю, то у вас создастся динамическое правило на маршрутизаторе пропускающее трафик из DMZ в LAN, как только сервер из LAN попытается создать туннель до сервера в DMZ.
Чем это правило лучше статического правила на такой же пропуск трафика от сервера в DMZ к серверу в LAN?
К тому же, если он обеспечивает централизованную аутентификацию, то решается вопрос с разными логинами/паролями от разных систем. Проходишь аутентификацию на единой точке входа, а дальше работает SSO для доступа к бэк-энд ресурсам. И не надо аутентифицироваться отдельно на каждом ресурсе. Плюс можно настроить многофакторную аутентификацию к ресурсам, которые сами по себе это не поддерживают.
Поэтому с точки зрения ИБ этот вариант отличается от публикации разных фронт-эндов от разных приложений.