Już od kilku lat istnieje taki malutki projekcik http://www.openwall.com/phpass/ i chyba staje się coraz popularniejszy bo więcej darmowych skryptów zaczyna z niego korzystać (drupal, WP, ajkieś fora). Osobiście już dawno porzuciłem własne pomysły na rzecz tego. Najsilniejsza metoda to blowfish a ta z kolei według różnych testów jest też bardzo szybka. A i tak na nic nasze starania jeśli user trzyma hasło przypięte do monitora.

Ja zawsze używam następującej metody i jak do tej pory nikomu się nie udało włamać.

W bazie trzymam następujące informacje o haśle:

MD5 z hasła
SHA1 z hasła
długość hasła

i oczywiście mam jeszcze użytą sól do zabiegów MD5 i SHA1, która jest generowana na podstawie informacji: id użytkownika, login użytkownika, data rejestracji (czyli tych danych, które są niezmienne).

Żeby umilić życie te trzy wartości mam zapisane odpowiednio w jednym ciągu. Na niektórych serwisach rezygnuję z użycia SHA1 ponieważ jak do tej pory MD5 z długością hasła dawało skuteczną ochronę.

Oprócz tego kody źródłowe, które są na serwerze są zakodowane więc nie jest łatwo rozpoznać jak dokładnie jest tworzone hasło. Sama zawartość bazy danych niestety niewiele pomoże. Aha - wspominałem już o tym, że wartości wpisywane do bazy o użytkowniku takie jak dane osobowe są zaszyfrowane a klucz szyfrujący/odszyfrujący znajduje się w zakodowanym kodzie źródłowym.

Wiem, że moja metody jest mniej skuteczna niż wielokrotne MD5 haseł ... ale muszę jakoś sobie radzić

Pozdrawiam,
Łukasz

Często w tym wątku pojawia się problem szybkości algorytmu hashowania. Martwicie się, że algorytm będzie wolny, cieszycie się gdy md5 jest superszybkie. Wydaje mi się, że to podstawowy błąd na poziomie założen. Funkcje hashujące których używamy - i nie ważne czy będzie to md5, czy coś z rodziny sha2, albo nawet cos bardziej ekscentrycznego jak haval - nie zostały zaprojektowane do szyfrowania kilku/kilkunasto znakowych haseł, a do hashowania dużych bloków danych, lub do hashowania duzych ilości skrótów w bardzo krótkim czasie(np. podczas sortowania, lub w implementacji protokołu sieciowego). One naprawde SĄ szybkie:)

W przypadku haseł w serwisie webowym, operacja hashowania wykonywana jest tylko raz na każde logowanie, więc nie musi być bardzo szybka. Różnice zajętości ramu podczas obliczeń na poziomie kilu kb także nie są tutaj problemem. Dodatkowo np. obliczanie hasha nie powinno dać się zrównoleglić. Można pewnie wymienić jeszcze kilka założeń które będą prawdziwe dla haseł serwisu webowego, a niekoniecznie prawdziwe przy innych zastosowaniach.

Popatrzmy w jaki sposób można zaatakować hash w serwisie webowym:

a) brute-force. Najbardziej rozpowszechniona i najłatwiejsza metoda ataku.
Problemem jest bardzo duża szybkość komputerów. Atakujący może wygenerować olbrzymie ilości hashów w krótkim czasie. Dodatkowo niezabezpieczony formularz logowania może pozwalać na wielokrotne logowania w krótkim czasie. Za kilkaset $/h można wynając superkomputer obliczający 500,000,000,000 hashy na sekundę!

slownik/brute-force
Problemem jest mała inwencja użytkowników przy wymyślaniu haseł

c) rainbow
Problemem jest generalnie brak "soli" Atakujący ma wygenerowany słownik hashy

d) analiza różnicowa i inne metody matematyczne
W typowym serwisie webowym nie jest to problem, jednak warto pamiętać, że md5(md5($val)) będzie miało prawdopodobnie gorsze właściwości, niż pojedyńcze użycie funkcji hashującej, dlatego należy raczej unikać takiego rozwiązania. Problem wielokrotnego hashowania typu md5(md5(md5(...) leży prymitywnym sposobie podawania danych do funkcji -> tylko za pierwszym razem używamy całości dostępnych danych, za każdym następnym razem do funkcji hashującej wchodzą zawsze dokladnie 32 znaki, a większość "losowości" która tkwiła w oryginalnym haśle, jest (prawdopdobnie) powoli tracona przez funkcje mieszającą. Piszę prawdopodobnie bo nie udało się udowodnić do tej pory ani że jest tracona ani że nie jest, można jednak dość bezpiecznie założyć, że stałe 32 znaki poddawane cały czas temu samemu algorytmowi, maja raczej gorsze właściwości niż losowy ciąg znaków

e) atak DOS
W przypadku serwisu webowego, atak na kolizję przy logowaniu nie ma za bardzo sensu, ale jeśli operacja hashowania jest kosztowna, można doprowadzić do wyczerpania zasobów serwera np. poprzez wielokrotne logownie.


Teraz remedium na nasze problemy:
e) ograniczenie ilości logowań, albo szybka funkcja hashująca
d) używanie całości danych wejściowych przy każdej iteracji algorytmu hashującego, używanie matematycznie poprawnych funkcji hashujących
c) sól.
Słownik i odrzucanie idiotycznych haseł użytkowników. Narzucenie odpowiedniego poziomu skomplikowania na hasła.
a) Wolny algorytm hashowania! przez wolny, rozumiem np. ~10ms

No włąsnie, jak widać na końcu szybki algorytm hashujący, jest tak naprawde WADĄ w przypadku typowego serwisu webowego.

Po tym przydlugim wstępie, przejdę do sedna:
http://en.wikipedia.org/wiki/Bcrypt - nie mylić z http://bcrypt.sourceforge.net/
jest to algorytm który spełnia założenia które sobie postawiliśmy. Jest matematycznie poprawny, oparty na sboxach z blowfisha, a do tego można sterować jego złożonością tak żęby osiągnąć wymaganą szybkość(a raczej wolność). Niewielka modyfikacja w szybkości funkcji hashującej i atakujący który próbuje bruteforce potrzebuje nagle lat zamiast minut na złamanie haseł, a dla naszego serwisu różnica rzędu paru ms przy logowaniu nie jest zauważalna.

http://stackoverflow.com/questions/4795385...asswords-in-php

Podsumowując:
1. wolna, poprawna matematycznie funkcja hashująca typu bcrypt
2. słownik
3. ograniczenie ilości logowań
4. sól

Witam. Wiem, że tu bardziej chodzi o hash haseł, ale ja mam pytanie o przenoszenie hash'a między serwerami. Np. jeśli w hashu chcemy przenieść 3 zmienne:



I chcę to przenieść na inny serwer, aby wykorzystać w formularzu w postaci tajnej:



Dodaje do url'a i przechwytuję na inym serwerze w postaci:

example.com/form.php?hash=9812asd65017578gs23487 (liczby przypadkowe z klawiatury, jednak to jest ten wygenerowany hash).

Teraz chciałbym wpisać te 3 zmienne zakodowane w hashu do formularza. Jak to zrobić?

Z góry dzięki za pomoc

Pozdrawiam.

PS. Sorry za odkopanie, ale nie chciałem specjalnie nowego tematu zakładać.

Jeśli chcesz mieć zdekodowane te dane to tak się nie da (a raczej Ty tego nie zrobisz).
jeśli ma to być hash wpisany w input to proszę:

[PHP] pobierz, plaintext 
	<!-- Link : example.com/form.php?hash=9812asd65017578gs23487	-->
	<form action="" method="POST">
		<input type="text" value="<?php $_GET['hash']; ?>">
	</form>
[PHP] pobierz, plaintext 

Podstawy podstawy podstawy!

A co myślicie by zrobić własne hashowanie ?
Funkcja str_replace

A czy przeczytałeś w ogóle ten temat...?

Najlepiej używać bcrypt, bo możemy dostosować 'trudność obliczeń' tzw. rundy, 12 rund tak zwolni prędkość ataku brute-force... że sobie to odpuszczą chyba, że to hasło do biur CIA / FBI

http://www.codinghorror.com/blog/2012/04/speed-hashing.html


Bcrypt: php manual -> crypt

W manulau nie zalecają stosowania md5, sha1, sha256 do heszowania ze względu na zbyt dużą szybkość i możliwy atak brute force. Mam dwa pytania:
1. Czy md5, sha1 i sha256 itp. mogą wygenerwać dwa lub więcej takich samych kluczy dla różnych danych wejściowych ? Przypuszczam, że tak bo inaczej taki algorytm byłby doskonałym archiwizerem. W dokumntacji algorytmu md5 -> http://www.faqs.org/rfcs/rfc1321.html znalałem jednak coś takiego:

Więc jak to jest ?
2. Wbudowane opóźnienie można osiągnąć za pomocą funckji crypt gdzie określamy algorytm, sól i ilość iteracji (to jest wbudowane opóźnienie). Tyle, że funkcja crypt nie obsługiwana przez silnik bazy danych. Jeśli np. w Zend autoryzacja odbywa się przy pomocy Zend_Auth_Adapter_DbTable w ten sposób. To klasa wykorzystuje wbudowaną funcję silnika bazy danych czyli SHA1 i CONCAT
Jak uwierzytelnić za pomocą crypt ?

[PHP] pobierz, plaintext 
$authAdapter = new Zend_Auth_Adapter_DbTable(
                            Zend_Db_Table::getDefaultAdapter(),
                            "users", 
                            "email",
                            "md5",
                            "SHA1(CONCAT('" . Zend_Registry::get('salt') . "', ?, salt))");
[PHP] pobierz, plaintext 

Tak, gdyż wynika to z dziedziny, w której są tworzone hashe. Jest ona znacznie bardziej ograniczona niż treść, którą można hashować.


Masz tu błędne założenie projektowe - PO CO obarczać bazę hashowaniem?

To akurat nie moje założenie tak jest zaimplementowana metoda w zend framework, jakoś jednak przeżyje z sha1 + podwójna sól. No chyba, że ktoś na zend posługuje się crypt i byłby chętny opisać jak się za to zabrać

Zawsze offtopowałem ^^.
A do tematu:

Można zrobić coś takiego, myślę że to coś da

[PHP] pobierz, plaintext 
<?
$rand = rand(1,11);
$dodatek = md5($rand);
$haslo = 'megatajne123';
$hashcalk = md5($rand, $haslo);
echo $hashcalk;
?>
[PHP] pobierz, plaintext 

A output raw bardzo dziwny :
y Z��o��~���
Nie wiem co to znaczyć ma, no ale myślę że hasło zahaszowane dobrze Raczej te kilka bajtów ktoś by rozszyfrowywał z 10 lat hahahaha

to niczym się nie różni jak zwykłe md5($haslo, $sól). Masz bcrypt od takich zadań.

To na dobrą sprawę jest nic innego, jak

[PHP] pobierz, plaintext 
md5(rand(1, 11), true);
[PHP] pobierz, plaintext 

To nawet skrót hasła nie jest i tylko przez idiotoodporność PHP-a błędami na lewo i prawo nie rzuca. Pod żadnym pozorem nie powinno się z czegoś takiego korzystać.

A ogarnijcie to:

[PHP] pobierz, plaintext 
<?
function hash($string) {
 
  $hashe = array(
                              "sha512","ripemd128","ripemd256","ripemd320","whirlpool",
                              "tiger128,3","tiger160,3","tiger192,3","tiger128,4","tiger160,4",
                              "tiger192,4","snefru","gost","adler32","crc32","crc32b");
  foreach($hashe as $hash) {
    hash($hash, $string); 
  }
  return $string;
}
?>
[PHP] pobierz, plaintext 

ma to sens?
wklejcie do notatnika, zincludujcie albo w tym samym pliku poza funkcja echo hash('string');
mysle ze cos da ^^ ciekawe, jak bardzo przedluza czas wykonania niz samo md5

Nie ma:

Po 1: Bo infinite recursion

Po 2: Sam "tok myślenia" takiego kodu to pomysł delikatnie mówiąc wysoce nierozsądny

Bardzo dobre spostrzeżenie wówczas po-któreś tam hashowanie nie ma znaczenia, tylko obciąża kod po stronie serwera. Jeśli tak mogę się wtrącić w dyskusję a do tego postu doszedłem tylko.
Natomiast hashowanie haseł nie jest metoda kompresji, ktoś kto tak myśli bardzo sie myli, to że powstają 32 znaki o tym nie świadczy, to błędny wniosek. Raz że takie hashowanie powinno być jednostronne a dwa że jest stratne, czyli za długie treści są obcinane, po to właśnie, aby nie można było odszyfrować tego hasła, nie zawsze tak jest, ale tak powinno być. Algorytm matematyczny nam to gwarantuje, unikalność hasha i tylko wyniki są porównywane jeśli tak to jestes zalogowany itp - to aluzja do wcześniejszego posta.
Natomiast co do łamiania algorytmów (nie brute force) to nie nie odbywa sie to tak jak sie wielu wydaje. Przykładem może być base64_encode, proszę sobie kilkukrotnie kodować jakąs treść i zobaczyć wynik. Jeśli dany algorytm jest złamany to nie będzie miało znaczenia ile razy był użyty bo będzie to rozpoznawalne, przedłuży pracę ale da sie zrobić i czas nie będzie zbytnio długi, bo złamanie nie jest tak czasochłonne jak brute force.

Skoro przytoczyles moja wypowiedz sprzed ponad 10 lat to ja moze tylko uaktualnei to troche:
wtedy byla mowa o zwyklym md5, sha1, i dodaniu jakiejs tam soli.
Teraz, gdy w metodach hashowania mozna okreslic, ze hashowanie ma zajac np. 1sekunde, to juz metoda hashowania na serwerze ma znaczenie, gdyz moze bardzo znacznie wydluzyc czas ataku BF i najzwyklej w swiecie taki atak sie nie powiedzie spowodow czasowych

Nie lepiej zrobić coś takiego?

[PHP] pobierz, plaintext 
 
$haslo = "Konstantynopolitańczykówianeczka";
$hash = hash(md5,$haslo);
 
for($i=1;$i<=10000;$i++)
{
 
    $hash = hash(sha1,$hash);
 
}
 
echo $hash;
 
[PHP] pobierz, plaintext 

@Przemek19 Polecam przeczytac ten temat od poczatku. Masz tam wyjasnione czemu twoja metoda jest totalnie do bani i totalnie niebezpieczna

Ok, miałem 2 minuty, więc nie doczytałem