Crypt dan DES adalah sandi lama dan tidak boleh digunakan
DES tua biasa adalah algoritma usang. Anda tidak dapat benar-benar membandingkannya dengan AES128; itu seperti mengeluh bahwa hash SHA256 lebih besar dari hash MD5 - ya, memang, tetapi hanya satu dari mereka yang dapat memperlambat penyerang untuk sementara waktu. DES secara luas dianggap lemah bahkan pada tahun 1999 dan tidak boleh digunakan dalam aplikasi baru. Jangan gunakan.
Saya tidak berpikir itu ide yang baik untuk mencari metode enkripsi yang "menyediakan ukuran data sekecil mungkin" - karena pada dasarnya membuang-buang waktu untuk mengenkripsi data menggunakan DES. Mengapa tidak menggunakan ROT13 (caesar cypher)? Hasil "terenkripsi" berukuran sama dengan input, sayang enkripsinya bisa dibobol oleh anak berusia 3 tahun.
crypto adalah dari vintage yang serupa. Algoritme hashing crypt UNIX yang lama adalah ... tua ... dan sama sekali tidak cocok untuk aplikasi baru apa pun. Hash harus minimal SHA256.
Crypt adalah hash satu arah
Adapun tidak dapat mengetahui cara mendekripsi data terenkripsi:crypt bukan algoritma enkripsi, ini adalah fungsi hash kriptografi atau "hash satu arah". Hash satu arah cocok untuk memverifikasi bahwa data tidak dimodifikasi, dibandingkan dengan salin hash untuk autentikasi sandi, untuk digunakan dalam otentikasi tantangan-respons , dll. Anda tidak dapat mendekripsi data terenkripsi.
Berurusan dengan ukuran
Gunakan fungsi kriptografi yang layak dan hidup dengan peningkatan ukuran. bf atau aes128 adalah yang terlemah yang dapat Anda gunakan secara wajar.
Secara pribadi saya lebih suka melakukan enkripsi/dekripsi di aplikasi, bukan di DB. Jika sudah selesai di DB, kuncinya dapat diungkapkan oleh pg_stat_statements , di log dengan log_statement atau kesalahan, dll. Sebaiknya kunci tidak pernah berada di tempat yang sama dengan data yang disimpan sama sekali.
Sebagian besar bahasa pemrograman memiliki rutinitas kriptografi yang baik yang dapat Anda gunakan.
Sulit untuk memberikan saran lagi karena Anda belum benar-benar menjelaskan apa yang Anda enkripsi, mengapa, apa persyaratan Anda, apa ancamannya, dll.
Sandi?
Jika Anda menyimpan sandi, Anda mungkin salah melakukannya.
-
Jika memungkinkan, biarkan orang lain melakukan otentikasi:
-
OAuth atau OpenID untuk Internet
-
SSPI, Kerberos/GSSAPI, Active Directory, LDAP bind, SASL, HTTP DIGEST, dll untuk intranet
-
-
Jika Anda benar-benar harus melakukan autentikasi sendiri, tambahkan garam ke kata sandi dan hash hasilnya. Simpan hash dan garamnya. Ketika Anda harus membandingkan kata sandi, beri garam pada plaintext baru dari pengguna dengan garam yang sama yang Anda gunakan untuk hash yang disimpan, hash kata sandi baru+garam, dan lihat apakah hashnya sama dengan yang Anda simpan. Jika ya, mereka memberikan kata sandi yang benar.
-
Anda hampir pasti tidak perlu memulihkan kata sandi cleartext. Terapkan pengaturan ulang kata sandi yang aman sebagai gantinya. Jika Anda benar-benar harus, gunakan algoritme yang cukup aman seperti aes untuk mengenkripsinya dan pikirkan baik-baik tentang penyimpanan dan pengelolaan kunci. Lihat postingan lain di SO tentang penyimpanan/pengelolaan kunci dengan pgcrypto.
Lihat juga:
