Bezpieczeństwo haseł przy użyciu soli Opcje

[nexis]

Zwykle, dla bezpieczeństwa, trzymamy w bazie danych skrót hasła, utworzony za pomocą md5() bądź sha1(). Z myślą o tęczowych tablicach dopisujemy zwykle dodatkowo tzw. sól, która jest trzymana poza bazą danych, zwykle na serwerze.

Chciałbym jednak zwiększyć bezpieczeństwo również po stronie użytkownika i zastosować mechanizm znany z banków internetowych, czyli odpytywanie użytkownika o wybrane znaki hasła. Aby zastosować taki mechanizm jestem jednak zmuszony zapamiętać każdy znak hasła osobno. Powiedzmy, że w tym celu narzucę maksymalną długość hasła na 16 znaków i stworzę w tabeli bazy danych 16 dodatkowych pól (po 1 dla każdego znaku). Jak ma się jednak w/w sposób do tej sytuacji? Sam skrót to praktycznie żadne zabezpieczenie. Zastosowanie soli już bardziej, ale jest to wciąż bardzo słaby mechanizm. Co zrobić?

[thek]

Ok... Pomińmy więc w dalszych rozważaniach sól systemową i skupmy na owej drugiej. W tym momencie powiedz mi jak wygląda sprawa soli w przypadku gdy hasło użytkownika zawiera te same znaki. Jak na razie bowiem przerabiamy temat gdy znaki w haśle są unikatowe (abcd1234), a ja staram dowiedzieć jak w zamyśle Twój algorytm działa w przypadku haseł w stylu (aaaaaaaa). Zauważ, że fragment jaki zresztą zacytowałeś taki wątek porusza. Na razie rozważasz bowiem w przykładach sytuację, gdy żaden ze znaków się nie powtarza. Z postów zaś wynika, iż każdy znak ma swój hash. Dlatego też napisałem w 8 przypadkach 'sól1 + a', bo tak można wnioskować że algorytm działa, z tego co do tej pory napisałeś. A to jest niebezpieczne bo dla tego samego znaku, hash każdego takiego samego będzie identyczny, niezależnie ile soli do niego władujesz. No chyba, że po prostu każdy użytkownik ma swój własny zestaw hashy dla określonych pozycji. Tylko jak zamierzasz to na serwerze zorganizować? Załóżmy 1000 userów, z których każdy ma hasło około 10-15 znakowe. To daje nam całkiem pokaźną ilość hashy do przechowywania gdzieś na serwerze oraz, co istotniejsze systemu zapisu/odczytu tego pakietu, który mocno wpłynie na wydajność zapewne. Zresztą przy zmianie hasła na dłuższe też musiałbyś jakoś rozwiązać problem dopisania nowych hashy do tej "bazy". Problem bezpieczeństwa staje się więc jednocześnie wąskim gardłem w wydajności :/ Algorytm powinien więc być na tyle bezpieczny by dane na których operuje mogły być przechowywane w bazie i/lub mogły być generowane w locie. Stąd zaproponowałem funkcję losowego tokena zmienianego co jakiś określony czas i który byłby składową przy generowaniu zestawu hashy porównawczych dla danego usera. Każda zmienna bowiem to plus dla bezpieczeństwa, gdyż niweluje nam niezmienność takich danych jak hasło lub pewne ciągi wejściowe użyte podczas procesu generowania ciągów hashy porównawczych.

[nexis]

staram dowiedzieć jak w zamyśle Twój algorytm działa w przypadku haseł w stylu (aaaaaaaa)

Podstaw sobie dowolne hasło pod podany przeze mnie, w poprzednim poście, wzór i znałbyś odpowiedź na swoje pytanie. Zakładam, że każdy użytkownik ma unikalną sól dla każdego pojedynczego znaku hasła.

Załóżmy 1000 userów, z których każdy ma hasło około 10-15 znakowe. To daje nam całkiem pokaźną ilość hashy do przechowywania gdzieś na serwerze oraz, co istotniejsze systemu zapisu/odczytu tego pakietu, który mocno wpłynie na wydajność zapewne.

Założyłem, że maksymalna długość hasła będzie wynosiła 16 znaków, więc pełny zestaw soli zostaje generowany już przy rejestracji nowego użytkownika. Jako metodę przechowania soli proponowałem system plików, ale można równie dobrze wykorzystać niezależną bazę danych i przechowanie nawet 16 soli dla każdego użytkownika nie wpłynie praktycznie w żaden sposób na wydajność. Szczególnie, że dane są pobierane jedynie w takich przypadkach jak: rejestracja, logowanie czy zmiana hasła.