Krypta i DES to stare szyfry i nie powinny być używane
Zwykły stary DES to przestarzały algorytm. Nie można go naprawdę użytecznie porównać z AES128; to jak narzekanie, że hash SHA256 jest większy niż hash MD5 – tak, ale tylko jeden z nich może na chwilę spowolnić atakującego. DES był powszechnie uważany za słaby nawet w 1999 i nigdy nie powinny być używane w nowych aplikacjach. Nie używaj go.
Nie sądzę, że dobrym pomysłem jest szukanie metody szyfrowania, która „zapewnia najmniejszy możliwy rozmiar danych” - ponieważ w zasadzie jest to strata czasu na szyfrowanie danych za pomocą DES. Dlaczego nie użyć ROT13 (szyfr Cezara)? Wynik „zaszyfrowania” ma taki sam rozmiar jak dane wejściowe, szkoda, że szyfrowanie może zostać złamane przez 3-latka.
krypt jest z podobnego rocznika. Stary Algorytm haszujący krypty UNIX jest ... starszy ... i całkowicie nie nadaje się do żadnej nowej aplikacji. Hasze powinny mieć co najmniej SHA256, naprawdę.
Krypta to skrót jednokierunkowy
Jeśli chodzi o brak możliwości odszyfrowania zaszyfrowanych danych:crypt nie jest algorytmem szyfrowania, to kryptograficzna funkcja skrótu lub „hasz jednokierunkowy”. Skróty jednokierunkowe są odpowiednie do sprawdzania, czy dane są niezmodyfikowane, w porównaniu z przechowywanymi solonymi skrót do uwierzytelniania hasła, do użycia w uwierzytelnianiu w odpowiedzi na wyzwanie itp. Nie można odszyfrować zaszyfrowanych danych.
Zajmij się rozmiarem
Użyj przyzwoitej funkcji kryptograficznej i żyj ze wzrostem rozmiaru. bf lub aes128 są mniej więcej najsłabsze, których można rozsądnie użyć.
Osobiście wolę szyfrować/odszyfrowywać w aplikacji, a nie w bazie danych. Jeśli jest to zrobione w DB, klucze mogą zostać ujawnione przez pg_stat_statements , w logach przez log_statement lub błędy itp. Lepiej, aby klucz nigdy nie znajdował się w tym samym miejscu co przechowywane dane.
Większość języków programowania ma dobre procedury kryptograficzne, których możesz użyć.
Trudno jest udzielić więcej porad, ponieważ tak naprawdę nie wyjaśniłeś, co szyfrujesz, dlaczego, jakie są Twoje wymagania, jakie są zagrożenia itp.
Hasła?
Jeśli przechowujesz hasła, prawdopodobnie robisz to źle.
-
Jeśli to możliwe, pozwól komuś innemu przeprowadzić uwierzytelnienie:
-
OAuth lub OpenID dla Internetu
-
SSPI, Kerberos/GSSAPI, Active Directory, powiązanie LDAP, SASL, HTTP DIGEST itp. dla intranetu
-
-
Jeśli naprawdę musisz przeprowadzić autoryzację samodzielnie, dodaj sól do haseł i zahaszuj wynik. Przechowuj hasz i sól. Kiedy musisz porównać hasła, dodaj nowy tekst jawny od użytkownika tym samym dodatkiem, którego użyłeś do zapisanego skrótu, zahaszuj nowe hasło + sól i sprawdź, czy skrót jest taki sam, jak zapisany. Jeśli tak, podali właściwe hasło.
-
Prawie na pewno nie musisz odzyskiwać haseł w postaci zwykłego tekstu. Zamiast tego zaimplementuj bezpieczne resetowanie hasła. Jeśli naprawdę, naprawdę musisz, użyj przyzwoicie bezpiecznego algorytmu, takiego jak aes, aby je zaszyfrować i dokładnie zastanów się nad przechowywaniem i zarządzaniem kluczami. Zobacz inne posty w SO dotyczące przechowywania/zarządzania kluczami za pomocą pgcrypto.
Zobacz też:
