it-swarm-id.com

Apakah AES mengenkripsi kata sandi dengan dirinya sendiri lebih aman daripada SHA1?

Ini sebenarnya bukan pertanyaan praktis, tetapi lebih keingintahuan. Saya mendengar seorang profesor CS merekomendasikan untuk beralih dari md5ing kata sandi bukan ke SHA1, tetapi ke AES yang mengenkripsi kata sandi menggunakan dirinya sebagai kuncinya. Apakah ada yang punya wawasan tentang apakah ini sebenarnya lebih atau kurang aman?

Beberapa pemikiran tentang masalah ini:

  • SHA1 adalah satu arah, yang membuatnya lebih aman daripada fungsi yang melindungi data.
  • Di sisi lain, peretas tidak mungkin mengambil keuntungan dari sifat yang dapat diuraikan AES karena dia belum tahu kata sandinya.
  • Kecuali dia menebaknya. Tapi kemudian dia tidak peduli bagaimana saya mengenkripsi itu.
  • Karena Anda tahu kata sandi AES didekripsi ketika kunci dekripsi cocok dengan output, kata sandi tersebut dapat di-brute paksa di komputer peretas.
  • Tetapi si hacker tidak tahu bagaimana itu dienkripsi, jadi dia tidak akan mencobanya.
  • Tetapi si peretas bisa mendapatkan kode enkripsi juga, dalam hal ini hanya soal data mana yang perlu waktu lebih lama.
  • Sebagian besar situs web menggunakan md5 atau sha1 (kanan?), Jadi tabel pencarian untuk hash ini akan jauh lebih luas daripada metode AES. Sehingga membuat metode AES lebih aman.
  • Tetapi jika kita garam kedua metode, mereka akan menjadi sama kebal terhadap tabel pencarian.

Beberapa poin umum dalam jawaban, dan poin tandingan:

Enkripsi AES tidak dirancang untuk tahan benturan, dan karenanya mungkin akan memiliki lebih banyak tabrakan untuk panjang string hash yang sama.

Jika kita menggunakan garam yang lebih panjang, maka kata sandi terenkripsi akan lebih panjang dari hash SHA1. Ini mungkin cukup untuk membawa tabrakan ke tingkat yang sebanding - atau mungkin tidak.

Enkripsi AES memberi tahu Anda berapa lama kata sandi itu, dalam 16 byte.

Kita dapat menambahkan ke metode AES: setelah mengenkripsi itu, kita pad atau memangkas dengan panjang yang wajar (yang lebih panjang dari SHA1 untuk menghindari tabrakan).

30
skier88

Jawaban singkat: ide yang buruk, jangan lakukan itu.


Jawaban yang lebih panjang: tujuan dari latihan ini adalah untuk menyimpan sesuatu yang memungkinkan server untuk verifikasi kata sandi yang diberikan, tetapi tidak mengizinkannya untuk membangun kembali kata sandi; properti terakhir diinginkan, sehingga konsekuensi dari akses baca tidak sah ke database server oleh penyerang tetap terbatas.

Jadi kami menginginkan transformasi deterministik satu arah yang mengubah kata sandi yang diberikan menjadi nilai verifikasi. Transformasinya adalah:

  • dapat dikonfigurasi dengan lambat, sehingga dapat menggagalkan serangan kamus;
  • berbeda untuk setiap instance, untuk mencegah serangan kamus paralel, termasuk tabel prakomputasi (itulah arti garam).

Doa tunggal MD5 atau SHA-1 gagal pada kedua akun, karena fungsi-fungsi ini sangat cepat, dan tidak asin. Kelambatan dapat dilakukan melalui banyak pemanggilan bersarang (ribuan, mungkin jutaan), dan garam dapat disuntikkan "di suatu tempat", meskipun ada cara yang baik dan buruk untuk melakukannya. PBKDF2 adalah transformasi standar yang melakukan hal itu, dan itu tidak buruk (walaupun bcrypt agak lebih disukai ).

Namun, MD5 dan SHA-1 melakukan setidaknya satu hal dengan benar: mereka dirancang menjadi satu arah. Itu sulit dilakukan; bahkan tidak terbukti secara teoritis bahwa fungsi satu arah benar-benar ada. Cryptographers di seluruh dunia saat ini terlibat dalam kompetisi untuk merancang fungsi hash baru satu arah yang lebih baik.

Jadi apa yang profesor Anda sarankan adalah mengganti fungsi yang dirancang untuk satu arah, dengan fungsi yang bukan dirancang untuk satu arah. Itu tidak memperbaiki apa pun tentang kelambatan dan pengasinan, tetapi menghapus satu hal yang baik tentang MD5 dan SHA-1. Selain itu, AES dikenal sebagai relatif lemah sehubungan dengan serangan terkait kunci - itu bukan masalah selama AES digunakan untuk apa artinya, yaitu enkripsi, tetapi menjadi penting masalah ketika itu ditumbangkan menjadi blok penyusun untuk fungsi hash satu arah. Tampaknya mungkin untuk membangun fungsi hash yang aman dengan menggunakan kembali bagian dari desain AES, tetapi membutuhkan pengerjaan ulang yang substansial (lihat misalnya Whirlpool dan [~ # ~] echo [~ # ~]] ).

Jadi jangan gunakan skema hashing kata sandi berbasis AES buatan sendiri; dalam hal ini, jangan gunakan apa pun yang merupakan "buatan sendiri": itu adalah resep untuk bencana. Keamanan tidak dapat diuji; satu-satunya cara yang diketahui untuk membuat algoritma yang aman adalah dengan meminta ratusan ahli kriptografi terlatih melihatnya dengan cermat selama beberapa tahun. Anda tidak dapat melakukannya sendiri. Bahkan seorang cryptographer yang sendirian tidak akan mengambil risiko itu.

Sebagai gantinya, gunakan bcrypt. PBKDF2 juga tidak buruk.

32
Thomas Pornin

Sebagian besar situs web menggunakan md5 atau sha1 (kan?), Jadi ini yang diharapkan oleh peretas. Sehingga membuat metode AES lebih aman.

Bahkan jika sebagian besar situs web menggunakan MD5 atau SHA1, beralih ke AES hanya karena alasan itu biasanya tidak digunakan di sana tidak akan membuatnya lebih aman - itu just security by obscurity , yang biasanya tidak berkontribusi secara efektif untuk meningkatkan keamanan; akan jauh lebih aman untuk menggunakan algoritma yang baik (yang telah teruji dengan baik untuk tujuan yang diberikan) dan mendokumentasikannya secara publik, daripada menggunakan algoritma yang Anda tidak bisa memastikan apakah itu baik, dan tidak mengatakan bahwa Anda menggunakannya.

Saat ini saya dapat memikirkan kemungkinan kerugian berikut ketika menggunakan AES atau algoritma enkripsi lainnya seperti ini:

  1. Algoritma enkripsi biasanya tidak dirancang untuk menghindari tabrakan: Seperti yang ditunjukkan dalam komentar di bawah, itu mungkin tidak menjadi masalah karena perilaku pseudo-acak yang diharapkan dari block cipher. Tapi tetap saja, Anda menggunakan algoritma enkripsi untuk sesuatu yang tidak dirancang untuknya.
  2. Dapat dibayangkan bahwa ada serangan pada algoritma enkripsi yang jauh lebih mudah dilakukan jika orang tahu bahwa teks dan kata sandi yang jelas sebenarnya adalah satu dan sama (seandainya fakta tentang algoritma yang Anda gunakan entah bagaimana bocor, yang bukan tidak mungkin diberikan bahwa itu misalnya dibahas di sini).
  3. Algoritma enkripsi menghasilkan data yang dalam banyak kasus bervariasi dengan panjang cleartext. Itu berarti, ciphertext menyimpan informasi tentang berapa lama kata sandi itu. Dalam kasus AES ini adalah kelipatan 16 byte sejauh yang saya tah ; nilai hash, di sisi lain, memiliki ukuran tetap (mis. 160 bit/20 byte untuk SHA1); artinya seorang peretas potensial memiliki peluang mendapatkan lebih banyak informasi dari teks yang dienkripsi daripada dari nilai hash.
  4. Dalam kriptografi biasanya selalu kurang aman juga memasak sesuatu sendiri (yang kemudian mungkin juga hanya digunakan oleh Anda) daripada menggunakan sesuatu yang sudah teruji dengan baik di komunitas untuk waktu yang lama (artinya sudah waktunya untuk diperiksa secara menyeluruh. oleh sejumlah cryptanalysts).
  5. Anda ingin memastikan algoritma hashing kata sandi Anda lambat, sehingga penyerang potensial terhambat untuk memaksa masuk ke sistem Anda. Salah satu cara untuk mencapai hal ini adalah misalnya untuk secara iteratif melakukan hashing dalam beberapa putaran, seperti yang dilakukan PKBDF2. Untuk detail lebih lanjut, lihat http://security.blogoverflow.com/2013/09/about-secure-password-hashing/
17
codeling

Satu masalah langsung yang saya lihat dengan pendekatan ini adalah panjang kunci tetap AES. Menggunakan AES-128, seseorang akan dibatasi hingga 16 byte kata sandi. Bagaimana dengan kata sandi yang lebih panjang, atau, frasa sandi yang panjang?

Untuk mengakomodasi panjang kata sandi apa pun Anda membutuhkan fungsi hash, jadi kembali ke titik awal.

Perhatikan bahwa ada cara * yang dipelajari dan aman untuk mengubah blok-sandi menjadi fungsi hash, yang disebut mode PGV seperti Davies-Meyer, Matyas-Meyer-Oseas atau Miyaguchi-Preneel.

(*) Untuk definisi yang tepat "aman".

7
Krystian

Namun, pertimbangkan ini:

Saya membobol situs Anda dan mendapatkan akses yang cukup untuk mengetahui bahwa Anda memiliki kunci AES yang dikonfigurasi untuk sistem Anda, satu-satunya hal yang terlihat "terenkripsi" adalah kata sandi Anda ... tebak apa yang akan saya lakukan.

Saya akan membuat mereka diacak, menyisakan jauh lebih sedikit ruang untuk dengan mudah menggores seluruh basis data kata sandi Anda.

Selain itu, sebagai pemilik situs, saya TIDAK ingin kemampuan untuk mendekripsi kata sandi pengguna saya, jika tidak, opsi untuk "memulihkan kata sandi" menjadi fitur yang mungkin diminta oleh atasan, dan secara teknis, kami dapat melakukannya karena sistem yang mendasarinya dibangun menggunakan sistem enkripsi alih-alih sistem hashing (alasan lemah tetapi pengembang perangkat lunak menangani permintaan seperti ini).

Terutama: Ketika masalah keamanan, jangan mencoba untuk melakukan sesuatu yang aneh dan keluar dari kotak, Anda mungkin akan menulis sendiri lubang keamanan besar karena Anda tidak akan dapat menempatkan jumlah penelitian tim orang yang bekerja pada suatu algoritma untuk tujuan tertentu harus.

5
StrangeWill

Jawaban yang benar adalah: Tidak masalah sama sekali.

Dalam hal kata sandi, satu-satunya serangan praktis adalah mencoba daftar kata sandi sampai Anda menemukan yang tepat dengan kekerasan. Tidak ada yang akan mencoba menyerang SHA1 atau AES secara langsung untuk melakukan itu. Bahkan pada titik penelitian saat ini, menyerang SHA1 akan sepuluh ribu kali lebih mudah daripada AES, keduanya masih sangat mustahil (untuk membalikkan hash kata sandi karena tabrakan tidak penting di sini). Dan ketika seorang peneliti menemukan cara lain untuk menyerang algoritma lainnya, peluangnya mungkin terbalik tahun depan.

Yang penting adalah seberapa cepat Anda mendapatkan hash/mengenkripsi kata sandi Anda. Tetapi jika mis. SHA1 lebih cepat dan Anda menginginkannya lebih lambat (untuk menangkis serangan brute-force), Anda bisa hash beberapa kali.

Apa yang "diharapkan" oleh peretas tidak relevan, membuat sesuatu yang "tidak terduga" hanyalah ketidakjelasan. Ini seperti mengatakan "Saya membalikkan semua kata sandi, sekarang lebih aman". Tidak akan. Jika peretas dapat mengakses basis data kata sandi Anda, bagaimana Anda bisa yakin dia tidak memiliki akses ke fungsi penurunan hash kata sandi Anda?

Satu cacat ketika "mengenkripsi kata sandi dengan dirinya sendiri": Panjang ciphertext mungkin memberi penyerang petunjuk tentang panjang kata sandi. Itu sangat buruk.

Bagaimanapun, Anda harus memberi garam sandi, lebih disukai dengan sesuatu yang unik bagi pengguna.

4
Kosta

Ada MAC (Kode Otentikasi Pesan) yang dibuat dari cipher blok; yang paling dikenal mungkin CBC-MAC . Ini memiliki masalah dibandingkan dengan hash-mac, terutama:

Diberi cipher blok aman, CBC-MAC aman untuk pesan dengan panjang tetap. Namun, dengan sendirinya, itu tidak aman untuk pesan panjang variabel. Penyerang yang mengetahui tag pesan yang benar (mis. CBC-MAC) berpasangan (m, t) dan (m ', t') dapat menghasilkan pesan ketiga m '' yang CBC-MAC juga akan t '.

[...]

Masalah ini tidak dapat diselesaikan dengan menambahkan blok ukuran pesan (mis., Dengan penguatan Merkle-Damgård) dan karenanya disarankan untuk menggunakan mode operasi yang berbeda, misalnya, CMAC untuk melindungi integritas pesan panjang variabel.

Jawaban yang lebih pendek: Keamanan MAC yang dibangun dari block cipher tergantung pada bagaimana Anda membangunnya. Konstruksi naif hampir pasti akan memiliki kekurangan yang signifikan.

4
Nick Johnson

Fakta bahwa Anda telah merancang algoritma yang tidak biasa tidak membuatnya aman. Algoritma "buatan sendiri" berbahaya, karena tidak ada yang melakukan analisis kriptografi.

Seperti @Thomas Pornin menulis di atas, AES tidak dirancang untuk tahan benturan. Selain itu, AES relatif cepat, yang menyederhanakan serangan.

SHA1 dirancang tahan benturan, tetapi SHA1 juga dirancang sangat cepat, karena tujuannya adalah untuk menghasilkan hash volume besar data atau file dalam waktu singkat. Tujuannya bukan untuk mencegah serangan terhadap kata sandi hash.

Jika Anda ingin membuat hash kata sandi yang tahan terhadap berbagai jenis serangan, pertimbangkan peregangan kata sandi. Tergantung pada tumpukan teknologi Anda dan perpustakaan yang tersedia pertimbangkan bcrypt, scrypt, argon2.

1
mentallurg