Ponowne uwierzytelnianie i obrona przed CSRF, aby użytkownicy tego nie odczuli Opcje

[WebCM]

Istnieją 2 metody zabezpieczeń przed CSRF, które chronią tylko częściowo:

1. Sprawdzanie nagłówka Referer - niektórzy w trosce o prywatność go wyłączają
2. Wysyłanie akcji metodą POST - wtedy nie zadziała metoda "na obrazek"

Skuteczniejsze metody:

1. Jednorazowy klucz w ukrytym polu formularza - musi się zgadzać z zapisanym na serwerze
2. Potwierdzanie hasła - np. przy wejściu do panelu admina, ważnych zmianach
3. Kody jednorazowe, SMS, telefon - to już krytyczny poziom zabezpieczeń

Jakie jeszcze znacie skuteczne sposoby zabezpieczeń?

Chcę zastosować takie zabezpieczenia, aby w jak najmniejszym stopniu utrudnić korzystanie z serwisu. Rozważmy jednorazowy klucz. Standardowa implementacja wygląda tak:

[PHP] pobierz, plaintext 
if( wyslano_formularz )
{
  if( empty($_SESSION['authKey']) OR $_POST['authKey'] != $_SESSION['authKey'] )
  {
    echo 'Wyślij formularz ponownie';
  }
}
 
$_SESSION['authKey'] = uniqid();
[PHP] pobierz, plaintext 

Osoba pisze jednocześnie 2 posty. Kiedy wyśle drugi, zobaczy komunikat "Wyślij formularz ponownie". Przyczyna: w sesji zapisujemy klucz pod identyczną nazwą. Innym razem pisze długi post. Znowu do samo. Przyczyna: Sesja wygasa po 20 minutach (można zwiększyć, tylko niezalecane).

Rozważmy ponowne logowanie przy wejściu do panelu admina. Redaktor pisze długi artykuł. Zapisuje. Niestety, sesja wygasła. Musi zalogować się ponownie. Artykuł znika. Zamiast sesji można wykorzystać ciasteczka. Dopóki nie zamknie przeglądarki, nie zostanie wylogowany. Jak nie popełnić błędu? Wystarczy zapisać md5(hasło + coś tam)?

Jak projektować zabezpieczenia, aby nie utrudniać życia użytkownikom?

Ten post edytował WebCM 18.03.2012, 16:41:44

[WebCM]

Przed takim czymś (i innymi problemami - np. nagły zanik prądu u użytkownika) najlepiej chronii okresowe zapisywanie kopii roboczej (szkicu) formularza.

Zarówno IPB i phpBB zapisują klucz w ukrytym polu formularza. Różnica: po wygaśnięciu sesji phpBB każe wysłać formularz ponownie. IPB przyjmie nawet po kilku godzinach. Czyżby trzymał klucz w bazie? **

Powstał temat bezpiecznego logowania. Załóżmy, że ID użytkownika i hasło w MD5 zapisujemy do ciastek z parametrem Tylko HTTP. Stosując tablice tęczowe, można takie hasło odczytać. Można się zabezpieczyć, dodając klucz: md5(haslo + klucz). Klucz można przypisać każdemu użytkownikowi w bazie (nadmiar danych) lub ustalić 1 wspólny dla wszystkich.

Jakie jest prawdopodobieństwo, że klucz zostanie wykradziony z ciągu znaków md5(hasło+klucz), gdzie "hasło" może być dowolne, co najmniej 5 znaków, natomiast "klucz" jest jeden dla wszystkich (np. 13 znaków)? Od czego to zależy?

** A teraz wyskoczył komunikat "Autoryzacja nie pasuje". Podejrzewam, że niektóre fora IPB mają przedłużoną sesję.

Ten post edytował WebCM 23.03.2012, 23:47:55