Философия безопасности входа - PullRequest
6 голосов
/ 17 января 2011

Мне дали код другого разработчика, который создал несколько политик безопасности для входа.Например, если вы попытаетесь войти в систему с именем пользователя, которое существует в базе данных, начнется запись количества неудачных попыток входа в систему.Затем, после достижения 3 попыток входа в систему, он добавляет еще одну запись в журналы, но добавляет в LockedOut бит 1.

Ребята, вы считаете, что это хорошая политика безопасности?Разве кто-то, пытающийся получить доступ, не попробует большое количество случайных имен пользователей и принудительно заблокирует всех из своей учетной записи?Это кажется плохой философией для безопасности.

Я думаю, что лучшей процедурой безопасности будет блокировка любого, кто сделал 3 попытки, в соответствии с таблицей IP, которая отслеживает различные попытки пользователя и истекает через 30 минут,так, чтобы предотвратить DDoS.

Как вы, ребята, разрабатываете свою безопасность входа в систему ??Вот что в основном сделал этот разработчик:

if username is in database:
   if first login: increase fail-attempt counter.
   if second login: lock out username.
   else: don't let him in.
else:
incorrect password.

edit: Окончательная процедура:

public void ResolveTimeouts()
{
    if (data.Expire <= DateTime.Now)
    { // it will only delete ONE single entry from the database, 
      // that happens to be this user's IP
      // If and only if, The expiration date is older than right now.
        Delete(this.data);
        data.Attempts = 0;
    }
}


int uid = UserExists(username);
if(uid < 1){
  ResolveTimeOuts(); // this will delete IPs from table if expiration passed
  if(loginAttempts >= 3){
    "Fail login, you have been locked out for " + TIMEOUT + " minutes";
    ExtendExpiration(TIMEOUT);
  } else {
    IncrementAttempts();
    "fail login, incorrect username or password.";
  }
} else {
  if(authenticate(uid, password)){
    "Successfully logged in.";
  } else {
    // INSERT lock out specific username feature here.
    "failed login, incorrect username or password.";
  }
}

Ответы [ 6 ]

2 голосов
/ 17 января 2011

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

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

2 голосов
/ 17 января 2011

Я не согласен.Я чувствую, что блокировка имени пользователя в целом безопаснее (без учета IP).

Что происходит, когда злонамеренный хакер подделывает IP-адрес?Хакер может перебирать IP-адреса и постоянно перебирать имя пользователя.

Я блокируюсь после трех попыток на 15 минут.

Комментарии к вашей правке:

Я бы сделал что-то вроде этого:

if(resolveTimeOuts()){ 
  bool uid = UserExists(); 
  //do other stuff
}else{ 
  "Your IP has been locked. Enter this code to prove you are human."
  // Captcha or math equation.
}

Хотя, Я не буду удалять просроченные IP-запросы в resolveTimeOuts().Это может увеличить время выполнения функции.Сделайте что-то вроде этого:

if(resolveTimeOut()){ 
  bool uid = UserExists(); 
  //do other stuff
}else{ 
  "Your IP has been locked. Enter this code to prove you are human."
  if(rand(1,5) == 5){
     // or something equivalent
     deleteExpiredRequests();
  }
  // Captcha or math equation.
}

Это даст ускоренное выполнение resolveTimeOut(), и если IP запрашивает слишком быстро, все истекшие тайм-ауты будут удалены.Вид двойного удара для хакера DoS.Они получают другую страницу, и генерация страницы может быть замедлена до deleteExpiredRequests(), если истек срок действия.

Редактировать два: Это более или менее то, что я бы реализовал.Я бы написал полный код, но я программирую на PHP.

bool function humanRequest(){
    // decide if the request lag is humanistic or bot speed
    // for example: last_request > this_request - 500;
}

if(!humanRequest()){
    // redirect to a Captcha page or die with a warning or something (like SO does)
}
uid = getUsername(username);
if(uid > 0){
    // validated request
}
else{
    // increase attempts
    // you could have a separate column for IP requests or whatever
    // lock out username after 3 attempts
}

Вы могли бы поставить humanRequest() в обоих случаях проверки имени пользователя.По сути, если они запрашивают какое-либо имя пользователя в течение короткого периода времени, внесите их в черный список.Но если вы проверяете имена пользователей на специальной странице (которая включается только тогда, когда кто-то пытается войти), это уже позаботится об этом.

Таким образом, вам нужно только добавить другую таблицу.Нет необходимости изменять вашу таблицу.

1 голос
/ 02 августа 2011

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

1 голос
/ 17 января 2011

Компромиссом будет блокировка на короткий период времени, чтобы значительно замедлить автоматические атаки, но не слишком долго для законного пользователя, который допустил «законную» ошибку.ИМХО, в большинстве случаев может хватить 10 секунд, , если применяется политика надежного пароля .

1 голос
/ 17 января 2011

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

Тем не менее, существуют определенные руководящие принципы и стандарты, которые приняты в качестве передового опыта. Я бы предложил начать с OWASP: http://www.owasp.org/index.php/Guide_to_Authentication

Обычная схема - отключение пользователя после определенного количества попыток на определенный период времени для предотвращения перебора. Обычный стандарт, который я видел на практике в хорошо написанных веб-приложениях, - это 3 недопустимых попытки, которые приводят к блокировке на 1 час.

Кстати, конкретный вопрос о локауте можно найти на сайте OWASP здесь: http://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Account_Lockout

Цитата из статьи (жирный шрифт добавлен мной для акцента):

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

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

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

Учитывая, что намерение пароля Система блокировки должна защищать от атаки грубой силы, разумный Стратегия заключается в том, чтобы заблокировать учетные записи для Количество часов. Это значительно замедляет атакующих, позволяя счета должны быть открыты для законных Пользователи .

1 голос
/ 17 января 2011

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

Цель упражнения - предотвратить атаки методом грубой силы.

...