Судя по описанию, приведенному в вопросе, логика блокировки привязана к:
- IP-адрес или, возможно, его часть, например, его класс C (первые 3 байта IP-адреса.
- [относительно большое] количество неудачных попыток
Я сомневаюсь, что кто-либо использует MAC-адрес, так как к нему относительно трудно / невозможно добраться, и он предлагает относительно немного преимуществ по сравнению с «идентификацией» IP-адреса (как IP-адреса, так и MAC-адреса могут быть подделаны в любом случае ...)
Причина, по которой Twitter использует IP-адреса, чтобы, вероятно, пытаться держать хакеров в страхе, при этом не доставляя неудобств всем законным пользователям . Идея состоит в том, чтобы предотвратить отказ в обслуживании, позволяя кому-то запретить законному пользователю Twitter использовать службу, просто не входя под этой учетной записью несколько раз (то есть цель состоит в том, чтобы отключить учетную запись, чтобы не угадать ее пароль).
Проблема этого подхода, однако, заключается в том, что он дает «плохим парням» больше шансов в конечном итоге войти; Чтобы снизить этот риск, логика входа в систему также может включать подсчет количества различных IP-адресов, заблокированных в данный момент для данной учетной записи, что позволяет полностью отключить учетную запись, когда это количество достигает порогового значения: «Человек, пять разных IP-адресов несколько раз пытались получить доступ к этой учетной записи ... Давайте заблокируем ее и отправим ее владельцу по электронной почте! ".
Тип логики входа, которую вы должны реализовать для своего веб-приложения, во многом зависит от характера сайта, количества пользователей и т. Д.
Нет ничего плохого в том, чтобы подражать тому, что делают сайты первого уровня, такие как Google и Twitter, но ваша индивидуальная ситуация может предоставить альтернативные возможности или требования.
Например, имея намного меньшее число входов в секунду, вы можете реализовать более изящный набор правил (скажем, правил, которые сопоставляют текущий IP-адрес с IP-адресами, которые ранее / недавно использовались для учетной записи, и в этих случаях будут более терпимыми). Другой пример: если ваши клиенты платят за услугу и / или если их конфиденциальность рассматривается с наценкой, может быть предпочтительнее ошибиться из-за осторожности, то есть [иногда] блокировать законных пользователей, а не разрешать [потенциально] хакеры.