it-swarm-id.com

Apakah ada keuntungan memisahkan kata sandi?

Saya telah membaca tentang hash LANMAN (LM) dan saya ingin tahu tentang bagian tertentu dari algoritma.

Hash LM dihitung sebagai berikut:

  1. Pengguna ASCII kata sandi dikonversi menjadi huruf besar.
  2. Kata sandi ini diisi dengan nol hingga 14 byte.
  3. Kata sandi 14-byte dibagi menjadi dua bagian 7-byte.
  4. Nilai-nilai ini digunakan untuk membuat dua DES kunci, satu dari masing-masing setengah 7-byte.
  5. Masing-masing dari dua kunci digunakan untuk DES-mengenkripsi konstanta ASCII string "KGS! @ # $%" , menghasilkan dua nilai cipher-text 8 byte.
  6. Kedua nilai teks-sandi ini digabungkan untuk membentuk nilai 16-byte, yang merupakan hash LM.

Ada banyak kelemahan keamanan yang diuraikan dalam artikel Wikipedia yang ditautkan dan dibicarakan di tempat lain, tetapi saya terutama tertarik pada langkah 3 hingga 6. Saya ingin tahu tentang apa yang menyebabkan desain ini. Apakah ada keuntungan keamanan nyata untuk memisahkan kata sandi, mengenkripsi dua bagian secara terpisah, kemudian menggabungkan kedua bagian untuk membentuk satu hash lagi? Atau apakah ini hanya contoh "keamanan melalui ketidakjelasan" ?

45
Bill the Lizard

Membagi kata sandi menjadi hash adalah bukan keuntungan. Itu dilakukan karena alasan yang tidak jelas yang tidak lagi relevan saat ini.

Alasan bahwa hash LanMan bekerja dengan cara ini adalah karena hash LanMan dibangun di atas DES. DES menerima kunci 56-bit. Oleh karena itu, wajar untuk memperlakukan potongan 7 byte sebagai membentuk kunci DES. Tidak ada cara yang baik untuk menggunakan DES untuk hash lebih dari 7 byte pada satu waktu, dan kami membutuhkan beberapa cara untuk membangun hash untuk kata sandi yang lebih panjang dari DES, sehingga desainer hash LanMan memutuskan untuk membagi kata sandi menjadi dua bagian.

Hari ini, kami tidak akan pernah membuat hash kata sandi dengan cara ini. Kami hanya menggunakan Bcrypt, Scrypt, PBKDF2, atau yang sejenis - atau kami akan membangun yang serupa berdasarkan primitif yang ada, seperti SHA256. Tetapi pada saat itu, Bcrypt, Scrypt, SHA256, dll., Tidak ada, membuka peluang bagi para desainer LanMan untuk membuat kesalahan yang menghancurkan ini.

Dengan standar modern, hash LanMan adalah desain yang payah. Ada banyakbanyakserangan di atasnya. Sangat lemah. Tidak ada yang harus menggunakan hash LanMan hari ini jika mereka bisa menghindarinya. (Seperti yang telah ditunjukkan orang lain, keamanannya payah bahkan oleh standar waktu itu. Poin yang adil.)

38
D.W.

Memisahkan kata sandi adalah kelemahan, bukan keuntungan. Ini memungkinkan pemecahan setiap kata sandi secara independen. Dimulai dengan ASCII karakter (kode dari 32 hingga 126, inklusif)), kemudian menghapus huruf kecil, Anda berakhir dengan 127-32-26 = 69 karakter yang mungkin ada dalam alfabet kata sandi. Ini mengarah ke 697 kemungkinan separuh, yang agak di bawah 243. Dengan kata lain, ini sangat mudah dikerjakan melalui brute force. Anda bahkan tidak perlu kamus.

Ini bukan keamanan melalui ketidakjelasan. Ini adalah rasa tidak aman melalui ketidakmampuan.

Edit: "sangat mudah ditelusur dengan brute force" juga membuka jalan untuk berbagai optimasi. Perhatikan bahwa LanMan tidak asin, sehingga tabel yang dikomputasi dapat menjadi efisien (Anda membayar biaya membangun tabel sekali, lalu Anda menyerang beberapa setengah-sandi - itu benar-benar layak bahkan untuk satu kata sandi, karena satu kata sandi dua setengah-kata sandi). Pada tahun 2003, Philippe Oechslin menerbitkan peningkatan trade-off waktu-memori (ini adalah artikel di mana ia menciptakan istilah "Rainbow table") dan menghitung tabel untuk memecahkan kata sandi LanMan. Dia membatasi dirinya pada kata sandi alfanumerik (huruf dan angka, tetapi tidak ada tanda-tanda khusus), dengan demikian ruang 237. Ukuran kumulatif dari tabel kemudian akan menjadi 1,4 GB, dengan efisiensi retak 99,9%, dan waktu serangan di bawah satu menit.

Dengan 243 space, mis. 64 kali lebih besar, ukuran tabel dan waktu serangan keduanya meningkat dengan faktor 16 (itu 642/3), jadi kita berbicara tentang 23 GB atau lebih (itu tidak banyak untuk disk hari ini) dan serangan 15 menit. Sebenarnya, serangan akan lebih cepat dari itu, karena bottleneck adalah pencarian pada hard-disk, dan penyerang pintar akan menggunakan SSD yang dapat melakukan pencarian 50 kali lebih cepat daripada hard-disk mekanik (SSD 32 GB harganya lebih murah dari $ 70 ...). Upaya membangun-tabel (pengeluaran satu kali) dapat memakan waktu beberapa minggu pada satu PC, atau beberapa hari pada cloud yang layak, sehingga agak murah.

Rupanya , tabel seperti itu sudah ada ...

54
Thomas Pornin

Hanya karena ada sesuatu yang lebih kompleks tidak perlu membuatnya lebih aman. Saya menjalankan cracker kata sandi pada kotak windows saya dan tampaknya memecah password menjadi 8 karakter string, dan itu memecahkan setiap string secara independen dari string lain, membuat proses berjalan sangat cepat.

Jadi dari sudut pandang praktis, membagi kata sandi tidak bermanfaat, dan @Thomas sudah membahas mengapa itu tidak menguntungkan secara matematis.

3
MasterZ