Предотвращение перехвата сеанса Facebook

Я создаю веб-приложение для финансовых услуг, и моя компания хочет включить в него аутентификацию через Facebook. Поскольку мы находимся в мире финансов, безопасность имеет первостепенное значение. Я использую facebook PHP SDK для интеграции, но меня очень беспокоит перехват сеанса. Когда я учился в колледже, я на сеансе выбивал дерьмо из всех вокруг меня (что было очень весело), ​​но я пытаюсь найти способ предотвратить это с помощью своего приложения.

Моя компания хочет, чтобы процесс аутентификации был как можно более упрощенным, а это означает, что что-то вроде двухфакторной аутентификации нежелательно. Но запрос пользователя на другую информацию ПОСЛЕ входа в facebook кажется наиболее безопасным способом сделать это. Мне интересно, может ли кто-нибудь из вас, умных людей, придумать какой-нибудь другой способ защитить это, сохраняя при этом весь процесс простым и быстрым?


person user1387983    schedule 10.05.2012    source источник
comment
Возможно, вы получите лучшие ответы на security.stackexchange.com.   -  person Mike Samuel    schedule 10.05.2012
comment
Да, но файл cookie аутентификации facebook отправляется в открытом виде. Использование SSL на моем сайте не помешает кому-то перехватить аутентификационный файл cookie в незащищенной сети, не так ли?   -  person user1387983    schedule 10.05.2012
comment
Поскольку мы находимся в мире финансов, безопасность имеет первостепенное значение. Моя компания хочет включить в нее аутентификацию в Facebook. ♫♩ Одна из этих вещей не похожа на другую, одна из них не принадлежит... ♪♬   -  person ceejayoz    schedule 10.05.2012


Ответы (1)


Другая часть информации полезна только в том случае, если P(атакующий-имеет-дополнительную-информацию | атакующий-захватил-сессию) низкий.

Если вы можете использовать сложный второй фактор в первый раз, когда они взаимодействуют (или взаимодействуют с учетом безопасности) с вами, а затем запоминать машину, с которой они подключаются, чтобы пропустить второй фактор при последующих посещениях, то вы можете получить оптимизированное взаимодействие в целом. .

Запрос чего-то вроде их баланса в их последнем заявлении для аутентификации устройства в первый раз может быть хорошим вторым фактором — это докажет, что они уже знают что-то, что предположительно является привилегированным, связанным с этой учетной записью.

Кроме того, отправка текста со случайным номером на мобильное устройство, связанное с учетной записью, может выступать в качестве второго фактора, предполагая, что они не подключаются с этого устройства.

person Mike Samuel    schedule 10.05.2012