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

[fr33d0m]

@fr33d0m: Nie, nie będzie mógł wysłać czegoś w imieniu użytkownika bo nie będzie wstanie podać odpowsiedniego klucza.

A ja Ci mówię, że się da z przynajmniej 99% skutecznością.
Zalogowany user na podatnym portalu wejdzie na Twoją stronę, gdzie Twój serwer pobierze i przeanalizuje kod źródłowy. Jedyny warunek jest taki, że zalogowany user nie może wejść w trakcie "ataku" na daną podstronę/formularz bo wygeneruje nowy/e token/y. PHP+AJAX/cURL

@WebCM
Prawdopodobieństwo rozszyfrowania klucza zależy przede wszystkim od popularności i tematyki Twojego portalu. To tak jak z algorytmem MD5, który kiedyś był uważany za perfekcyjny, a dziś można poznać większą ilość hashy ze względu na jego popularność i słabe hasła większości internautów. Załóżmy, że ktoś założył u Ciebie 100 kont z różnym hasłem aby przeanalizować jak działa Twoja "sól" stosowana do ciastka - taki cios z pewnością odczuje Twój algorytm, który zdradzi chociażby kilka drobnych informacji na jakiej zasadzie ciastko jest hashowane. Osobiście uważam, że lepiej nie ryzykować z podawaniem hasła w cookies, które można wykraść na wiele sposobów i samemu lub w grupie przeanalizować. Żeby nie było, jestem jak najbardziej za cookiesami i przedłużaniem/autoryzowaniem sesji, ale w sposób, który przedstawił marcio.