Witam ponownie,

W bazie danych mam zakodowany ciag znakow za pomoca (PASSWORD('tu_ciag_znakow')),
teraz potrzebuje wyciagnac z bazy ten ciag i wyswietlic normalny text.
Czy jest to mozliwe do wykonania...
Nie uzywam tu zadnego porownania z przesylanym formularzem, po prostu to co mam zakodowane w bazie chcial bym wyswietlic na stronie w formie odkodowanej...

Za wszelka pomoc wielkie dzieki...

Pozdrawiam...

PASSWORD używa algorytmu haszującego a nie kodującego więc jawnego hasła nie odzyskasz. Poza tym dlaczego używasz PASSWORD? W wersji MySQL 3.x 4.x złamanie hasza tej funkcji brute forcem to kwestia kilku chwil.

Jest to kodowanie/szyforwanie jednostronne. Nie da się tego rozkodować, podobnie jak np. md5();

Pozdrawiam,
Łukasz

W takim razie co proponujesz, jesli nie PASSWORD? md5? Czy jeszcze co innego?


W takim razie czy istnieje jakas stala funkcja php typu kode() , dekode() , ktora bedzie wprowadzac zakodowane ciagi znakow (np .: kode(blebleble) ) do bazy a pozniej ,wyciagniete z bazy zakodowane ciagi znakow odkodowywac w php (np za pomoca funkcji dekode(#lk34nd%q), otrzymamy "blebleble" - jesli wogle cos takiego istnieje)

Dziekiza odpowiedzi...
Pozdrawiam...

moze nie bede odkrywczy, ale to chyba sie robi tak,
że jak ktoś poda hasło w formularzu
to je też haszujesz i porównujesz wynik haszowania z tym co jest w bazie,\

a jeśli koniecznie chcesz mieć dwustronne szyfrowanie,
to możesz albo sam sobie napisać na podstawie jakiegoś znanego
algorytmu np DES, ale polecam troche łatwiejszy w implementacji
FEAL lub pewnie na necie znajdziesz jakieś gotowe biblioteki do szyfrowania
może google: szyfrowanie klucz symetryczny

MD5 połączone np. z sha1



A zastanów się czy jest sens stosować takie rozwiązanie? Jak ktoś uzyska dostęp do bazy to będzie miał pewnie też dostęp to plików na serwerze. Otworzy skrypt, zobaczy czego używasz i w 10 sekund będzie miał jawne hasła. W ogole trzymanie jawnych haseł userów czy wyświetlanie ich w jakimkolwiek momencie na stronie jest złym pomysłem. Od momentu rejestracji usera i podania hasła wszystko powinno być zhaszowane i dalesze operacje wykonujesz juz tylko na haszach (przypomnienie hasła, zmiana hasła etc.)

[PHP] pobierz, plaintext 
<?php
function CodeDecode($string){
 
for($i=0;$i<strlen($string);$i++)
	$string{$i} = (byte) char(255 - ord($string{$i}));
return $string;
}
?>
[PHP] pobierz, plaintext 

czyli negacja, bitów, w żadnym razie nie jest to profesjonalne,
ale jeśli zawsze jakoś zniechęci co leniwszych "hakerów"

Pisalem wyzej - nie uzywam formularza , jesli mam byc konkretny , to chodzi o haslo do serwera ftp (ktory uzywa zwyklego textu) wiec zahaszowane haslo mi odrzuca jako nie poprawne.
Dlatego chcialem, zakodowac do bazy , a poznej odkodowac z bazy i uzyc do laczenia z serwerem ftp.


domyslam sie ze nie chodzi tu o funkcje md5() - jak w takim razie moge polaczyc ta funkcje z np. sha1, czy inna...
Jak to sie ma z formularzami, tam jest pole typu "password". Czy jak bede porownywal to pole z wpisem w bazie ktora jest zahaszowana za pomoca md5 z sha1. czy to porownanie sie powiedzie? Czy moze trzeba dokonac jakis zmian w polu formularza gdzie bedzie wpisywane haslo? Jakie to maja byc zmiany ?

Nie zgodze sie z toba ze dostep do bazy umozliwia przegladanie wszystkich plikow na serwerze. Dostep do Bazy to jest jeden user a dzialanie na plikach w systemie to calkiem inny user. Dlatego chcailem, miec zakodowane haslo do ftpa rzeby jesli nawet ktos dostanie sie do bazy to nie uzyskal odrazu dostepu do innej uslugi.

Dlatego polaczenie jest po ssl...

[PHP] pobierz, plaintext 
<?php
$sPassword = md5(sha1($sJawnyCiag)); // po prostu :-)
?>
[PHP] pobierz, plaintext 

Nie porównujesz jawnego hasła z haszem tylko hasło po raz kolejny haszaujesz i porównujesz hasze.



...tak ale chodzi mi bardziej o nieautoryzowany dostęp. Często dostęp do SQL ludzie uzyskują po przez np. zdobycie pliku konfiguracyjnego z serwera/luki w skryptach etc. co daje często też dostęp do źródeł. Wracając do tematu hasza do ftp nie wyślesz więc musisz użyć jakiejś funkcji dwustronnej.

Jedyny bag jaki w tym wszystkim znalazlem, to to ze po kliknieciu enter w formularzu nie sabmituje mi odrazu tylko musi byc albo klikniecie mysza albo focus i "enter" na przycisku "loguj". Ale to chyba da sie obejsc jakims JavaSciptem ktory bedzie lapal przerwania i po kliknieciu enter bedzie wysylal formularz....

Wielkie dzieki wszystkimza pomoc...
Pozdrawiam...

tylko trudno odhaszować hasło, by je użytkownikowi przypomnieć

Swoją drogą lepiej zahaszować md5 przez sha1, nie sha1 md5-tką, a i tak nie ma sensu aż tak kombinować, wystarczy sha1(hasło + np. username lub data rejestracji) - wtedy dwa takie same hasła dwóch różnych userów nie są takie same w formie zahaszowanej.

Sokrates - pierwszy input type="submit" powinien reagować na enter z klawiatury wciśnięty w formularzu, nieważne w której kontrolce. W moim przypadku zawsze tak robi przynajmniej IE i Fx. Ale jeśli nie, to tak jak mówisz - postawić event handler na onkeydown i mission complete.

...ehh wiadomo ze przypomnienie hasła to w gruncie rzeczy wygenerowanie nowego, myślałem, że jest to jasne skoro już z milion razy był wałkowany ten temat ale widać, że milion to za mało i trzeba powtorzyć kazdemu osobno.

EOT

i co z tego ze ktos będzie miał takie same hasło jak ja ? w czym to przeszkadza ? pozatym sha1(hasło + np. username lub data rejestracji) niepotrzebne kombinowanie ?

Dzięki piwoszeq za podbicie tematu bo dopiero teraz doczytałem jakie pierdoły On tu pisze...



1. MD5 jest algorytmem kolizyjnym - też już było o tym milion razy, więc możesz kombinować z hasłem jak chcesz a i tak może sie zdarzyć, że dwa różne ciągi dadzą taki sam hasz (SHA-1 również!).

2. Powiedz mi dlaczego lepiej "zahaszować md5 przez sha1, nie sha1 md5-tką" ? Nie ma żadnej różnicy co zrobisz w pierwszej kolejności. Podwójne haszowanie ma tylko jeden cel - nie wiesz jaki to poszukaj na forum - o tym też już kilka razy było. Swoją drogą haszowanie sha1(md5) może i ma jakąś zalete w porównaniu do md5(sha1) ale coś wątpie żebyś o niej akurat myślał.

3. md5(sha1) to jest kombinowanie? A robienie dodatkowej tabeli w SQL, trzymanie w niej śmieci takich jak data rejestracji, przy każdym logowaniu wczytywanie dwóch warotści, łączenie i haszowanie jest Twoim zdaniem bardziej optymalne? ...a co jeśli user zechce zmienić nick? To co? Już nie zaloguje się do serwisu?

#3
nie chodzilo mi to to ze md5(sha1) to kominowanie ale to ze haszuje pass+username+data imo beznadziejny pomysl

Tak, wiem Wszystko to co wystukałem było do macbirdie

Wybacz, że nie zgadzam się ślepo z Twoim jedynym słusznym zdaniem. Nie niweluję jednak znaczenia Twojej wypowiedzi nazywając ją "pierdołami".


Uff, nie zgadłbym, dzięki (sarkazm)


Dlatego właśnie warto wprowadzić dodatkowy czynnik dający różne hashe dla tego samego hasła.
A dlaczego? Ano dlatego że gdy ktoś się dobierze do bazy, to ma o wiele mniejsze szanse trafienia na dwa takie same hashe dwóch takich samych haseł, z których jedno może znać, jak się może okazać.
Prosta sytuacja - jest sobie zły admin jakiegoś portalu, zauważa że zarejestrował się u niego nielubiany administrator innego, być może konkurencyjnego. Jakimś sposobem dobija się do tamtej bazy, udaje mu się zdobyć hasze, korzysta z prostego faktu, że sporo ludzi stosuje te same hasła na różnych stronach, do tego okazuje się że systemy autoryzacji w obu portalach korzystają z podobnie prymitywnych metod i akurat ma to szczęście że hasło (hash) jest to samo i dostaje się do konsoli administracyjnej lub może się podszyć. Zaznaczam na wszelki wypadek - jest to mało prawdopodobna sytuacja, ale taki wypadek moim zdaniem i tak dobrze jest wykluczyć (jak to B. Schneier napisał, paranoja w kryptografii wskazana). Idę zmienić hasło u siebie i powiem adminowi, by jeszcze lepiej serwer SQL zabezpieczył.

Kolizja SHA-1 jest znacznie mniej prawdopodobna, niż przy MD5, ale oczywiście możliwa do wykonania w skończonym czasie. Z tego co niedawno czytałem, przy aktualnych metodach ataku kolizyjnego na MD5, wystarczy jakieś 2^33 operacji, przy SHA-1 póki co "aż" 2^69. Mimo że SHA1 jest wiele mocniejszy, w nowych projektach, w których stawia się na bezpieczeństwo, nie zaleca korzystania już z żadnej z tych funkcji. Oczywiście do trzymania hasełek w portaliku nadają się na razie świetnie. Mniejsza atrakcyjność celu, więc mniejsza szansa ataku.


Dlaczego wątpisz? Bo zakładasz że skoro jestem nowy na forum, to nie mam o niczym bladego pojęcia? Nie jestem ekspertem od kryptografii, ale MD5 jest algorytmem słabszym, od dłuższego niż SHA1 czasu atakowany, z lepszym skutkiem, więc jeśli komuś się uda zmniejszyć jeszcze jego bezpieczeństwo, szybciej uzyska SHA1. W drugą stronę będzie trudniej, a przynajmniej dłużej. Nie jest to na pewno potężna różnica, ale nie taka, byś się tak o to tak bardzo burzył, jakbym jakiegoś świętokradztwa dokonał. Przyszedł jakiś knypek z paroma postami i śmie nie zgodzić się z "guru" php?


A dlaczego jakąś dodatkową tabelę tworzyć? Ja mam w tabeli użytkowników także kolumnę daty rejestracji, widząc po tabelach wielu różnych choćby forów, tak zazwyczaj jest. A przecież nie chodziło mi koniecznie o datę rejestracji, to żeś się przyczepił i tutaj. Wyciągnięcie jednej więcej kolumny z pojedynczego rekordu w bazie i zrobienie concata jest "troszkę" szybsze, niż wykonywanie dwóch funkcji mieszających i fałszywe poczucie większego bezpieczeństwa. Obie metody są w świetle niskiego bezpieczeństwa SHA1 i MD5 i tak mało skuteczne, ale ... przypominam o kwestii wyżej - ten sam hash dwóch takich samych haseł dwóch różnych userów lub tego samego w dwóch różnych bazach. I jeszcze raz zaznaczam - nie uważam że to jest wieelka, absolutna, przełomowa poprawa bezpieczeństwa, ale zapobiega takiej, mimo że mało prawdopodobnej, to jednak możliwej sytuacji. Bo trudniej trafić na ten sam hash dla dwóch tych samych haseł + dodatkowych czynników "dosalających", niż po prostu dwóch tych samych haseł.


A zauważyłeś małe, skromne, delikatne np. (rozw. na przykład)? Nie musi to być data rejestracji, nie musi być to login - uczepiłeś się tych dwóch rzeczy, zamiast choćby spróbować zrozumieć, o co mi chodzi. Chodzi mi o dowolny czynnik pozwalający uzyskać w efekcie dwa różne hashe dla takich samych haseł. [czekam aż ktoś wyrwie moją wypowiedź z kontekstu i zapyta, jak można uzyskać dwa różne hashe dla tego samego ciągu znaków ]


Tak, wiadomo że jazda rowerem to w gruncie rzeczy szybkie bieganie. Mi niestety nie "wiadomo", bo dla mnie liczy się precyzja wypowiedzi. A tutaj uczepiłem się po prostu dla żarciku. Jednak przepraszam, skoro jesteś tak śmiertelnie poważny, że nie przeczytałem od czasu mojej rejestracji całego forum od deski do deski! Weź jakiś urlop, albo zanim odpowiadasz na forum policz do 10, weź głęboki oddech. Dopuść możliwość że ktoś oprócz Ciebie może też mieć choć trochę racji.
I pamiętaj, wdech, wydech, wdech, wydech.

Widze, że uraziłem kogoś ambicje. Piszesz jakbym niewiadomo jak straszną rzecz napisał a w swojej wypowiedzi zwracasz sie do mnie jakbyś rozmawiał z idiotą. Co do "guru" to nie mam pojęcia skad przyszedł Ci pomysł, że za takiego sie uważam, na forum jest wiele osób z duzo większą wiedzą i wiele mi do nich brakuje (jeżeli osądzasz wiedze po liczbie postów to są tu ludzie którzy mają ich kilka k). Proponuje skończyć już ten temat bo publiczne forum to nie miejsce na słowne przepychanki i zaczepki.

Wracając do tematu. Są różne wersje SHA-1 - do złamania najmocniejszej faktycznie trzeba tyle operacji ile napisałeś, jednak słabsze wersje SHA-1 łamane są w zbliżonej liczbie operacji do MD5.

Co do posostałych rzeczy. Niektóre, sprawy o ktorych piszesz po prostu nie mają dla mnie większego sensu.

Odbiegliśmy już dość znacznie od tematu pierwszego posta więc przynajmniej ja temat kończe. Mam nadzieje, ze bedziemy mieli okazje porozmawaic przy innej okazji.

Panowie, proszę wyjść sobie za róg i tam sprawę wyjaśnić. Koniec przepychanek i osobistych docinek na forum publicznym, bo posypią się warny. Możecie się spierać, ale na temat proszę.