Frameworks Repository

Few days ago I started new page with hope to test new web technologies and keep up to date with SEO technics.

On site I plan to gather all possible frameworks (as much I could handle to manage) with options to easy search and compare. For now I started adding most popular frameworks – I hope you may help (I’m working on proposal page).

You may found it here: http://frameworks.click

Please share it 馃檪

Generator hashy z baz膮 “w chmurze”

Temacik nieco nadmuchany a pomys艂 prosty – oba moje rozwi膮zania do 艂amania hasy (RainbowDB/Hybrid Rainbow DB) korzystaj膮 z Google’a jako opcji “last restort” gdy nie mog膮 nic znale藕膰. Ta funkcja jest tym bardziej skuteczna im wi臋cej hashy mo偶na znale藕膰 w Google’u. Ale Googiel idealny nie jest – nie ma ich wszystkich… jeszcze 馃槈

Postanowi艂em pom贸c Googlowi by膰 lepsz膮 wyszukiwark膮 hash’y i stworzy艂em prosty generator dla kolejno generowanych hase艂. Skrypcik wrzuci艂em do kilku darmowych hosting贸w i pozosta艂o czeka膰 a偶 dane zaczn膮 si臋 indeksowa膰 馃檪

Wynik dzia艂ania skryptu mo偶na zobaczy膰 cho膰by tutaj: www.hashe.yoyo.pl

Plik ze 藕r贸d艂em dost臋pny jest tutaj: hashes.php

Kod mo偶na obejrze膰 tu:

<html>
<head>
<title>Hash List</title>
</head>
<body>
<div id="content">
<h1>Welcome to Hash List!</h1>

<p>This site will feed search engines with hashes of all common passwords :)</p>

<?
$signs = "qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM1234567890`~!@#$%^&*()-=_+[]\\{}|;':\",./<>?";
$howmany = 500;
#$algos = hash_algos();
$algos = array("md5", "sha1");

$index = !isset($_GET['i']) ? 0 : (int)$_GET['i'];
$array_num = !isset($_GET['n']) ? 1 : (int)$_GET['n'];
$array_num = $array_num > 26 ? 25 : $array_num;

function carthezian_set($index, $count=1) {
    global $signs;
    $lists_len = strlen($signs);
    $string = "";
    
    for($i=0; $i<$count; $i++) {
        $r = $index % $lists_len;
        $index = (int)($index / $lists_len);
        $string = $string . $signs[$r];
    }
    
    return $string; 
}

function hash($alg, $pw) {
	if($alg == 'md5') {
		return md5($pw);
	} elseif($alg == 'sha1') {
		return sha1($pw);
	}
}
?>
<h3>Used signs: <?=$signs?></h3>
<h4>Word length: <?=$array_num?></h4>
<h4>Possible passwords: <?=pow(strlen($signs), $array_num)?></h4>

<?if(($index + $howmany) >= pow(strlen($signs), $array_num)):?>
        <a href="?i=0&n=<?=$array_num+1?>">Next &rsaquo;</a>
<?else:?>
        <a href="?i=<?=$index + $howmany?>&n=<?=$array_num?>">Next &rsaquo;</a>
<?endif?>

<table>
<tr>
<th>Password</th>
<?foreach($algos as $alg):?>
<th><?=strtoupper($alg)?> hash of password</th>
<?endforeach?>
</tr>
<?for($i=$index; $i<$index + $howmany; $i++):?>
	<?if($i < pow(strlen($signs), $array_num)):
		$pw = carthezian_set($i, $array_num);?>
		<tr>
		<td><strong><?=$pw?></strong></td>
		<?foreach($algos as $alg):?>
		<td class="hash"><code><?=hash($alg, $pw)?></code></td>
		<?endforeach?>
		</tr>
	<?endif?>
<?endfor?>
</table>

<br />
<?if(($index + $howmany) >= pow(strlen($signs), $array_num)):?>
	<a href="?i=0&n=<?=$array_num+1?>">Next &rsaquo;</a>
<?else:?>
	<a href="?i=<?=$index + $howmany?>&n=<?=$array_num?>">Next &rsaquo;</a>
<?endif?>
</div>
</body>
</html>

Hybrid Rainbow DB

Jaki艣 czas temu napisa艂em swoj膮 w艂asn膮 t臋czow膮 tablic臋 i odk膮d zainteresowa艂em si臋 tym tematem zastanawia艂em si臋 jak jeszcze bardziej usprawni膰 t臋 aplikacj臋. Testowa艂em r贸偶ne d艂ugo艣ci 艂a艅cuch贸w i zauwa偶y艂em 偶e zwi臋kszanie d艂ugo艣ci 艂a艅cucha bardzo szybko powoduje znaczne zwi臋kszenie ilo艣ci kolizji, co drastycznie obni偶a艂o wydajno艣膰 (nie wspominaj膮c o czasie potrzebnym na wygenerowanie ca艂ej tablicy). Z tego powodu ostateczna implementacja cho膰 by艂a rzeczywi艣cie t臋czow膮 tablic膮 dzia艂a艂a bardziej jak tablica hashy – bo 艂a艅cuchy by艂y bardzo kr贸tkie.聽Ponadto ze statystyk wynika艂o 偶e bardzo rzadko has艂a by艂y odzyskiwane ze 艣rodka 艂a艅cucha – zdecydowana wi臋kszo艣膰 trafie艅 pochodzi艂a z pierwszego has艂a w 艂a艅cuchu. Pierwsze has艂o by艂o przewa偶nie s艂ownikowe, plus czasem jaki艣 dodatek w postaci cyfry/zmienionej wielko艣ci liter, itp. Pozosta艂e has艂a w 艂a艅cuchu by艂y praktycznie losowe.

Na dobr膮 spraw臋 takie wyniki mo偶na wyt艂umaczy膰 od dawna znan膮 prawd膮: “ludzie nie u偶ywaj膮 skomplikowanych hase艂”.聽Pomy艣la艂em wi臋c 偶e du偶o lepiej by艂oby generowa膰 hashe ze s艂贸w, kt贸re s膮 potencjalnie prawdopodobnymi has艂ami a nie dla r贸偶nych losowych 艣mieci. Szczeg贸lnie mo偶na by wykorzysta膰 pewne z艂e nawyki powielane przez wiele os贸b, np. typowe “skomplikowane” has艂o zaczyna si臋 od du偶ej litery, p贸藕niej jest kilka ma艂ych, a na ko艅cu cyfra lub dwie – przy czym ci膮g liter jest wyrazem s艂ownikowym. Tego typu wzorc贸w jest wiele i pomy艣la艂em 偶e mo偶na by to wykorzysta膰.聽Na dobra spraw臋 je偶eli zamierzamy sprawdzi膰 jako艣膰 hase艂 z jakiej艣 aplikacji to nie potrzebujemy 100% trafie艅, wystarczy 偶e 20% to has艂a kiepskiej jako艣ci i te b臋d膮 wymaga艂y poprawienia.

Czym s膮 hybrydowe t臋czowe tablice?

Gdy zacz膮艂em dr膮偶y膰 temat trafi艂em na artyku艂 opisuj膮cy podej艣cie, o kt贸rym my艣la艂em. Klasyczne t臋czowe tablice “wychodz膮” od pewnego has艂a, z kt贸rego generujemy hash, redukujemy go do nowego losowego has艂a itd… Zapisujemy pierwsze has艂o i ostatni hash a reszt臋 da si臋 odtworzy膰 gdy b臋dzie potrzebna. Hybrydowe t臋czowe tablice maj膮 bardziej rozbudowan膮 funkcj臋 redukuj膮c膮 – nie tworzy ona ca艂kiem losowych hase艂, ale has艂a wygenerowane przez sklejenie s艂贸w kt贸re potencjalnie cz臋艣ciej powinny w has艂ach wyst臋powa膰. Czyli zamiast generowa膰 has艂a typu: L;adfa=2ja, tworzone s膮 has艂a: abc123, Qwert, Bezpieczne5, itd.

Oba podej艣cia maj膮 swoje zalety i wady: odpowiednio du偶e t臋czowe tablice mog膮 przechowa膰 wi臋kszo艣膰 hase艂 z danego zakresu – ale b臋d膮 te偶 przechowywa膰 mas臋 pseudolosowych 艣mieciowych hase艂, kt贸rych prawdopodobie艅stwo wykorzystanie jest ma艂e. Hybrydy przechowuj膮 du偶o mniejszy zakres hase艂 ale za to takich “stosunkowo prawdopodobnych”, wi臋c mniejsza tablica powinna dawa膰 r贸wnie dobre wyniki (dla prostych zestaw贸w hase艂).

Koncepcja okaza艂a si臋 znan膮 ale nie wykorzystywan膮 r贸wnie cz臋sto jak t臋czowe tablice. C贸偶… nic nowego nie wymy艣li艂em ale realizacja pomys艂u wydawa艂a mi si臋 ciekaw膮 wprawka do kilku nowych technologii, kt贸rym mia艂em zamiar si臋 przygl膮dn膮膰.

Realizacja

O ile RainbowDB dzia艂a na bazie: PHP +聽PostgreSQL + modu艂 w C do Postgresa, to w Hybrid Rainbow DB postanowi艂em wykorzysta膰 zupe艂nie nowe narz臋dzia i frameworki. Baza to MySQL, aplikacj臋 pisa艂em w Pythonie na Django.

Realizacja zaczyna艂a si臋 od wygenerowania kilku s艂ownik贸w “sk艂adowych” dla z艂ych hase艂 np.: liczby (od 0 do 100, powtarzaj膮ce si臋 cyfry do 10 znak贸w), daty (od 1950 do 2015, we wszystkich kombinacjach np.: YYMMDD, itd.), znaki (pojedyncze, jak r贸wnie偶 w przer贸偶nych kombinacjach z klawiatury, alfabetycznie, itd.). Maj膮c takie s艂owniki zamierza艂em wygenerowa膰 zbiory hashy ze sklejonych z nich s艂贸w na zasadzie: ka偶de s艂owo z jednego s艂ownika z ka偶dym z drugiego. Je艣li pojedynczy s艂ownik potraktujemy jako zbi贸r to taka operacja na dw贸ch lub wi臋cej zbiorach nazywana jest iloczynem kartezja艅skim.聽Wykonanie tego typu operacji jest stosunkowo proste ale nie zamierza艂em zapisywa膰 wyniku hashowania ka偶dego tak wygenerowanego has艂a. Idealnie by艂oby m贸c zapisa膰 wyniki w spos贸b podobny jak w t臋czowych tablicach, czyli w jednym polu zakodowa膰 wynik kilku czy nawet kilkuset hashowa艅. Do tego musia艂em opracowa膰 algorytm pozwalaj膮cy przypisa膰 danemu has艂u z iloczynu kartezja艅skiego unikatowy jednoznacznie reprezentuj膮cy go numer. Odnosz膮c to do implementacji t臋czowej tablicy, chodzi艂o o funkcje redukuj膮c膮, kt贸ra zamienia艂a hash na numer a nast臋pnie generowa艂a n-ty wynik iloczynu kartezja艅skiego bez generowania wcze艣niejszych element贸w. To podej艣cie pozwoli艂o mi przechowywa膰 nawet bardzo d艂ugie has艂a w postaci kilku bajt贸w (jako numer) a przez to bardzo efektywnie wykorzysta膰 miejsce.

By dodatkowo poprawi膰 jako艣膰 generowanej “hybrydowej t臋czowej tablicy” w czasie generowania wykorzysta艂em wektor bitowy by “odznaczy膰” ju偶 wygenerowane has艂a. Wi臋c gdy dochodzi艂o do ponownego zredukowania hasha na has艂o, kt贸re ju偶 zosta艂o wcze艣niej wykorzystane i by艂by to powodem wyst膮pienia kolizji to zapisywany zostawa艂 poprzedzaj膮cy go hash, a proces generowania 艂a艅cucha by艂 przerywany. Ten mechanizm znacznie zmniejszy艂 cz臋stotliwo艣膰 wyst臋powania kolizji (wi臋c p贸藕niejsze wykorzystanie tablic b臋dzie szybsze), a jako efekt uboczny skr贸ci艂 czas generowania tablic.

Zastosowa艂em jeszcze jedn膮 sztuczk臋 by dodatkowo zmniejszy膰 rozmiar tablic. W wi臋kszo艣ci tablic kt贸re utworzy艂em nie by艂o potrzeby przechowywa膰 pe艂nych hashy aby m贸c odtworzy膰 has艂o. W ma艂ych tablicach wystarczaj膮ce by艂y pierwsze 2~3 bajty, w wi臋kszych 4~8. Zacz膮艂em wi臋c skraca膰 d艂ugo艣膰 przechowywanych hashy tak by utrzyma膰 stosunkowo ma艂膮 ilo艣膰 kolizji. Dzi臋ki tej optymalizacji mog艂em na tej samej powierzchni dyskowej zapisa膰 nawet 10-krotnie wi臋cej danych.

Wnioski

Pobawi艂em si臋 moimi nowymi tablicami i mam kilka spostrze偶e艅. Og贸lnie koncepcja si臋 sprawdzi艂a i hybrydy “trzaskaj膮” nawet hashe, kt贸rych moje wcze艣niejsze narz臋dzie nie rusza艂o (np. kilka hashy z pierwszej strony Top uncracked poprzedniego narz臋dzia). U偶ycie tego narz臋dzia przy audytach jest o tyle bardziej zasadne 偶e z艂amie ono spor膮 cz臋艣膰 “kiepskich” hase艂, kt贸re powinny zosta膰 zmienione – a odpu艣ci pseudolosowe, kt贸rych prawdopodobie艅stwo wykorzystania a realnym ataku jest du偶o mniejsze.

Hybrydowe Tablice maj膮 te偶 wady, kt贸rych nie mia艂o wcze艣niejsze rozwi膮zanie:

  • jest du偶o wolniejsze – poniewa偶 funkcja redukuj膮ca generuje nowe has艂o w do艣膰 zawi艂y spos贸b (w przypadku du偶ych s艂ownik贸w jest to zapytanie do bazy danych) to sprawdzenie ca艂ego 艂a艅cucha trwa znacznie d艂u偶ej, ni偶 w zwyk艂ej t臋czowej tablicy,
  • by przyspieszy膰 redukcj臋 cz臋艣膰 danych s艂ownik贸w jest cache’owana – przyspieszenie jest du偶e, podobnie jak zu偶ycie pami臋ci ;-/

C贸偶… Co艣 za co艣 馃檪

P.S. Ostatnio pobawi艂em si臋 chwil臋 Web Workerami – dzi臋ki czemu wrzucenie du偶ej ilo艣ci danych spowoduje ich przetworzenie w osobnym w膮tku bez zamro偶enia okna przegl膮darki.

Narz臋dziem mo偶na pobawi膰 si臋 tutaj: Hybrid Rainbow DB

RainbowDB

Pewnego popo艂udnia przeczyta艂em artyku艂 o聽t臋czowych tabelach i聽pod jego wp艂ywem zacz膮艂em kombinowa膰 jak zrobi膰 co艣 takiego ale swojego.

Do bazy wrzuci艂em ca艂y s艂ownik z聽aspell’a dla j臋zyka polskiego (s艂owa z聽ogonkami i聽bez), angielskiego, kilka s艂ownik贸w z聽popularnymi has艂ami, d艂ug膮 list臋 hase艂 z聽yourock i聽kilka innych. Sporo si臋 nakombinowa艂em aby wygenerowa膰 du偶o kombinacji szczeg贸lnie pod k膮tem polskich hase艂 (wszystkie: misiaczki, dupeczki, itp…) razem z聽r贸偶nymi popularnymi modyfikacjami (typu: misiaczki1, DUPECZKI, etc…). Na tym etapie mia艂em ju偶 wystarczaj膮co du偶o hase艂 aby bawi膰 si臋 dalej.

Zacz膮艂em kombinowa膰 z聽r贸偶nymi d艂ugo艣ciami 艂a艅cuch贸w – niestety funkcja redukuj膮ca zmniejsza艂a nieco entropi臋 kolejnych hashy w聽艂a艅cuchu, co dla d艂ugich 艂a艅cuch贸w mocno zmniejsza艂o wydajno艣膰 przeszukiwania bazy. Ostatecznie postawi艂em na bardzo kr贸tkie 艂a艅cuchy (a nu偶 si臋 co艣 tafi a聽przynajmniej nie b臋dzie mocno opu藕nia膰 wyszukiwa艅).

Obecnie baza ma ponad聽200 milion贸w hase艂聽i聽dla nich wygenerowane 艂a艅cuchy o聽d艂ugo艣ci 10 ogniw. Co daje teoretycznie mo偶liwo艣膰 sprawdzenia ok聽2 miliard贸w hashy. Wydaje si臋 to sporo ale w聽stosunku do innych baz dost臋pnych w聽sieci jest to kropla w聽morzu. A聽co do innych baz… pomy艣la艂em, 偶e skoro kto艣 ju偶 zrobi艂 tak膮 baz臋 dobrze to mo偶na by to wykorzysta膰. I聽tak dorzuci艂em funkcj臋 “obsysania” innych bazy hashy w聽przypadku gdy moja danego hasha nie potrafi rozpozna膰. Taki zabieg (kt贸rego implementacja zaj臋艂a mi 1聽popo艂udnie) wdro偶ony dla kilku r贸偶nych wyszukiwarek znacznie poprawi艂 efektywno艣膰 rozpoznawania hase艂.

Baz臋 postanowi艂em udost臋pni膰 w聽postaci strony聽www聽– jak na razie ze stosunkowo liberalnymi zasadami korzystania (czyli bez ogranicze艅 na liczb臋 wyszukiwa艅, konieczno艣ci rejestracji itp).

Z bazy mo偶na korzysta膰 pod poni偶szym linkiem:

RainbowDB

Wy艂膮czy艂em t膮 stronk臋 po dobrych dw贸ch/trzech latach dzia艂ania – ruch jest przekierowany na nowy projekt Hybrid Rainbow DB, w kt贸rym opr贸cz t臋czowych tablic zaimplementowa艂em hybrydow膮 t臋czow膮 tablic臋 – nowa aplikacja sprawdza o wiele wi臋cej hase艂.