Kursus MIT "Keamanan Sistem Komputer". Kuliah 17: Otentikasi Pengguna, Bagian 1

Institut Teknologi Massachusetts. Kursus Kuliah # 6.858. "Keamanan sistem komputer." Nikolai Zeldovich, James Mickens. Tahun 2014

Keamanan Sistem Komputer adalah kursus tentang pengembangan dan implementasi sistem komputer yang aman. Ceramah mencakup model ancaman, serangan yang membahayakan keamanan, dan teknik keamanan berdasarkan pada karya ilmiah baru-baru ini. Topik meliputi keamanan sistem operasi (OS), fitur, manajemen aliran informasi, keamanan bahasa, protokol jaringan, keamanan perangkat keras, dan keamanan aplikasi web.

Kuliah 1: “Pendahuluan: model ancaman” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 2: "Kontrol serangan hacker" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 3: “Buffer Overflows: Exploits and Protection” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 4: “Pemisahan Hak Istimewa” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 5: "Dari mana sistem keamanan berasal?" Bagian 1 / Bagian 2
Kuliah 6: “Peluang” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 7: “Kotak Pasir Klien Asli” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 8: “Model Keamanan Jaringan” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 9: "Keamanan Aplikasi Web" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 10: “Eksekusi simbolik” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 11: “Bahasa Pemrograman Web / Web” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 12: Keamanan Jaringan Bagian 1 / Bagian 2 / Bagian 3
Kuliah 13: "Protokol Jaringan" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 14: "SSL dan HTTPS" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 15: “Perangkat Lunak Medis” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 16: “Serangan Saluran Samping” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 17: “Otentikasi Pengguna” Bagian 1 / Bagian 2 / Bagian 3

Jadi mari kita mulai. Dengan kembalinya Anda, saya berharap liburan untuk semua telah sukses. Hari ini kita akan berbicara tentang otentikasi pengguna. Jadi, topik dari kuliah ini adalah untuk mengetahui bagaimana pengguna dapat membuktikan identitas mereka terhadap program? Secara khusus, artikel tersebut, yang dimaksudkan untuk pelajaran hari ini, menyentuh dasar-dasar keberadaan komunitas keamanan. Apakah ada yang lebih baik untuk otentikasi daripada kata sandi?



Pada level tertinggi, tampaknya kata sandi adalah ide yang buruk, karena mereka memiliki entropi yang sangat rendah dan mudah bagi penyerang untuk menyelesaikannya. Pertanyaan rahasia yang kami gunakan untuk memulihkan kata sandi yang terlupakan bahkan memiliki entropi yang lebih sedikit daripada kata sandi itu sendiri, dan ini juga tampaknya menjadi masalah.

Dan yang lebih buruk, pengguna biasanya akan menggunakan kata sandi yang sama di banyak situs berbeda. Ini berarti bahwa kerentanan dalam satu kata sandi yang mudah ditebak membahayakan pekerjaan pengguna dengan banyak situs.

Saya menyukai kutipan berikut dari sebuah artikel di kuliah hari ini: “dominasi kata sandi yang berkelanjutan di antara semua metode otentikasi pengguna lainnya adalah hambatan utama bagi penelitian keamanan.” Dengan demikian, komunitas riset keamanan ingin memiliki alternatif yang lebih baik daripada kata sandi. Namun, tidak jelas apakah memang ada skema otentikasi yang dapat sepenuhnya mengganti kata sandi, sementara lebih nyaman, lebih luas, dan lebih aman.

Hari ini kita akan membahas tiga masalah. Pertama, kita akan melihat cara kerja kata sandi yang ada. Setelah itu, kita akan berbicara tentang properti kata sandi global yang diinginkan untuk skema otentikasi apa pun. Akhirnya, kita melihat apa artikel kuliah tentang metrik, atau fitur otentikasi, melihat dan bagaimana beberapa skema otentikasi lainnya dibandingkan dalam hal efisiensi dengan kata sandi.



Jadi apa itu kata sandi? Kata sandi adalah rahasia bersama untuk pengguna dan server. Dengan demikian, implementasi primitif skema kata sandi pada dasarnya hanya harus memiliki tabel sisi server yang memetakan nama pengguna ke kata sandi mereka.

Ini adalah cara termudah untuk membayangkan implementasi salah satu skema otentikasi - pengguna memasukkan nama dan kata sandi, server mencari mereka dalam tabel ini, membandingkan kata sandi dengan nama, dan jika semuanya cocok, pengguna diautentikasi. Jelas, masalahnya adalah jika seorang penyerang membobol server, maka dia bisa melihat tabel ini dan mengambil alih semua kata sandi. Jadi ini jelas hal yang buruk.

Mungkin solusi untuk masalah ini adalah dengan menyimpan tabel di server, yang terlihat seperti ini: nama pengguna tidak sesuai dengan kata sandi itu sendiri, tetapi hash-nya. Dalam hal ini, pengguna memasukkan kata sandi dalam teks biasa, server memeriksa kode hash dan membandingkannya dengan nilai dalam tabel. Keuntungan dari skema ini adalah bahwa fungsi hash ini dirancang sedemikian rupa sehingga hash sulit untuk dibalik dengan kata sandi. Jika tabel ini hilang, ada kebocoran data, atau penyerang meretas server dan mengambilnya, maka ia akan melihat string karakter alfanumerik acak bukan kata sandi teks, dan akan sulit baginya untuk mengembalikan gambar aslinya.

Setidaknya secara teori, menggunakan hash adalah hal yang cukup bagus. Tetapi sekarang dalam praktiknya, penyerang tidak harus menggunakan serangan brute-force untuk menentukan gambar terbalik dari nilai hash.



Penyerang benar-benar dapat mengambil keuntungan dari kenyataan bahwa dalam praktiknya kata sandi memiliki distribusi yang tidak merata. Dan dengan distribusi yang tidak merata, maksud saya ... katakanlah kita tahu bahwa semua kata sandi memiliki panjang hingga 20 karakter. Dalam praktiknya, pengguna tidak menggunakan seluruh rentang ini, lebih suka kata sandi seperti 123, todd, atau yang serupa. Namun, studi empiris telah menunjukkan cara kerja kata sandi tersebut, dan ditemukan bahwa sekitar 20% pengguna menggunakan 5.000 kata sandi paling populer. Dengan kata lain, ini berarti bahwa jika seorang penyerang memiliki database 5.000 kata sandi ini, ia dapat dengan mudah melakukan hash dan kemudian, ketika melihat tabel kata sandi yang dicuri, cukup cocok dengan hash. Jadi secara empiris, seorang hacker akan dapat memulihkan sekitar 20% dari kata sandi yang ada di tabel server.

Pakar Yahoo menemukan bahwa kata sandi mengandung dari 10 hingga 20 bit entropi, 10-20 bit keacakan. Sebenarnya, ini tidak terlalu banyak. Mempertimbangkan kompleksitas menciptakan fungsi hash, mesin modern menghitung jutaan hash tersebut setiap detik. Dengan demikian, fungsi hash harus mudah dihitung dalam desain sehingga komputer dapat dengan mudah kata sandi hash. Namun, kombinasi fakta ini dengan keacakan kata sandi yang tidak cukup berarti bahwa, pada prinsipnya, skema ini tidak seaman kelihatannya.

Ada hal yang dapat Anda coba untuk mempersulit kehidupan seorang hacker - ini adalah fungsi kompleks dari formasi kunci. Dalam hal ini, maksud saya bahwa hash kata sandi digunakan sebagai sumber data, berdasarkan pada server yang menghasilkan kunci yang disimpan di server.



Apa yang baik tentang fungsi-fungsi pembuatan kunci ini adalah bahwa mereka memiliki kompleksitas yang dapat disesuaikan, yaitu, Anda dapat memutar kenop tertentu dan membuat fungsi ini bekerja lebih lambat atau lebih cepat tergantung pada seberapa banyak Anda ingin menghemat kinerja proses.

Misalkan Anda ingin membuat kunci. Contohnya adalah standar generasi kunci PBKDF2 atau, mungkin, BCrypt, Anda dapat mempelajari lebih lanjut tentang mereka dari Internet. Mari kita bayangkan bahwa salah satu fungsi pembangkitan kunci ini membutuhkan satu detik, bukan beberapa milidetik, untuk dihitung. Bahkan, ini akan membuat pekerjaan penyerang jauh lebih sulit, karena upaya untuk menghasilkan nilai untuk 5.000 kata sandi "atas" akan memakan waktu lebih lama.

Pada level internal, fungsi-fungsi generasi kunci ini sering bekerja dengan berulang kali memanggil hash, mengaksesnya berkali-kali, jadi semuanya sangat sederhana. Tetapi apakah penggunaan proses pembuatan kunci yang menghabiskan waktu menyelesaikan masalah keamanan yang kita hadapi? Jawabannya adalah tidak, karena salah satu masalahnya adalah bahwa musuh dapat membangun sesuatu yang disebut Rainbow tables, atau "rainbow tables". Tabel pelangi hanyalah peta tentang bagaimana kata sandi cocok dengan nilai hash. Jadi, bahkan jika sistem menggunakan salah satu fungsi pembangkitan kunci yang mahal ini, penyerang dapat menghitung satu dari tabel ini satu kali. Ini bisa sedikit rumit, karena pemrosesan setiap fungsi pembuatan kunci adalah hal yang agak lambat, tetapi penyerang dapat membuat tabel ini sekali dan kemudian menggunakannya untuk memecahkan semua sistem berikutnya berdasarkan pada algoritma fungsi pembuatan kunci yang sama. Inilah cara kerja tabel pelangi ini.

Saya ulangi sekali lagi - untuk memaksimalkan manfaat ekonomi dari membuat tabel Rainbow, seorang penyerang dapat mengambil keuntungan dari distribusi kata sandi yang tidak merata, yang saya bicarakan sebelumnya. Dengan demikian, penyerang dapat membuat tabel seperti itu hanya untuk beberapa set kecil dari semua kata sandi yang mungkin.

Siswa: mungkin "pengasinan" membuatnya jauh lebih sulit?

Profesor: ya, ya, tepatnya. Kami akan pergi ke "pengasinan" dalam beberapa detik. Secara umum, jika Anda tidak menggunakan penggaraman, tabel pelangi memungkinkan penyerang, dengan beberapa upaya dalam mode offline, untuk menghitung tabel ini, dan kemudian mendapat manfaat dari kemampuan untuk menghitung kata sandi dasar berdasarkan pekerjaan yang dilakukan.

Hal berikutnya yang mungkin Anda pikirkan untuk memperbaiki situasi adalah pengasinan. Bagaimana cara kerjanya? Prinsip dasarnya adalah untuk memperkenalkan beberapa keacakan tambahan ke dalam metode pembuatan kata sandi. Anda mengambil fungsi hash ini, memasukkan "garam" di dalamnya, dan kemudian kata sandi, dan semua ini disimpan dalam tabel di server.



Apa itu garam? Ini hanya string panjang yang mewakili bagian pertama dari fungsi hash ini. Jadi mengapa lebih baik menggunakan skema ini? Perhatikan bahwa "garam" sebenarnya disimpan dalam teks yang jelas di sisi server. Anda mungkin berpikir: Ya, jika "garam" ini disimpan dalam teks yang jelas di sisi server dan penyerang dapat mencuri tabel nama pengguna untuk kata sandi, jadi mengapa dia tidak bisa juga mencuri "garam" ini? Apa gunanya solusi seperti itu?

Siswa: karena jika Anda memilih kata sandi yang paling umum, Anda tidak bisa hanya menggunakannya sekali dan menemukan pengguna baru.
Profesor: benar sekali. Pada dasarnya, apa yang dilakukan garam adalah untuk mencegah penyerang membuat meja pelangi tunggal yang dapat digunakan terhadap semua hash. Pada prinsipnya, Anda dapat mempertimbangkan "garam" cara untuk membuat kata sandi yang sama menjadi unik. Dalam praktiknya, banyak sistem menggunakan konsep "pengasinan."

Faktanya, "salt" memungkinkan untuk menambahkan bit sebanyak mungkin pada pseudo-password ini, karena semakin banyak bit, semakin baik. Apa lagi yang perlu dilakukan adalah memperhitungkan bahwa setiap kali pengguna mengubah kata sandi, "garam" juga harus diubah. Karena salah satu alasan untuk keputusan ini adalah kemalasan pengguna yang ingin menggunakan kata sandi yang sama beberapa kali. Mengubah "garam" akan memastikan bahwa benda yang disimpan dalam basis data kata sandi akan benar-benar berbeda walaupun satu kata sandi diganti dengan kata sandi yang persis sama.

Hadirin: mengapa ini disebut "garam"?

Profesor: Ini pertanyaan yang bagus, dan saya tidak bisa menjawabnya dengan pasti. Namun, saya yakin ada beberapa pembenaran untuk ini. Mengapa cookie disebut cookie? Internet mungkin tahu mengapa, tetapi saya tidak tahu.

Siswa: mungkin karena "garam" menambahkan sedikit "rasa" pada hash?

Profesor: well, saya senang kami merekam ini karena kami jelas memiliki kesempatan untuk mendapatkan penghargaan film. Saya yakin ada semacam jawaban di Internet, jadi saya akan mencarinya nanti.
Jadi, pendekatan di atas cukup sederhana. Saya berasumsi bahwa pengguna entah bagaimana mengirim kata sandi ke server, tetapi tidak menentukan bagaimana ini terjadi. Jadi, bagaimana kita memberikan kata sandi ini?

Pertama, Anda cukup mengirim kata sandi melalui jaringan dalam bentuk teks yang jelas. Ini buruk karena mungkin ada penyusup di jaringan yang memonitor lalu lintas yang Anda kirim. Dia hanya dapat menetapkan kata sandi dan menyamar sebagai Anda.

Karena itu, kami selalu mulai dengan satu pria jerami, sebelum saya tunjukkan kepada Anda pria-pria jerami lainnya, yang, tentu saja, juga cacat fatal. Jadi, hal pertama yang mungkin Anda pikirkan adalah mengirim kata sandi dalam teks yang jelas. Dari sudut pandang keamanan, jauh lebih baik untuk mengirim kata sandi melalui koneksi terenkripsi, jadi kami menggunakan kriptografi. Mungkin saja kami memiliki semacam kunci rahasia yang digunakan untuk mengonversi kata sandi sebelum mengirimkannya melalui jaringan. Jadi pada level tertinggi, tampaknya enkripsi selalu melakukan hal-hal yang lebih baik, seperti merek dagang yang menjamin kualitas produk.

Tetapi masalahnya adalah jika Anda tidak berpikir dengan hati-hati tentang cara menggunakan enkripsi dan hashing, Anda tidak dapat memanfaatkan manfaat keamanan yang Anda andalkan. Misalnya, jika ada seseorang yang duduk di antara Anda - pengguna dan server, penyerang terkenal ini, "man in the middle" yang sebenarnya memonitor lalu lintas Anda, sementara berpura-pura menjadi server.

Jika Anda mengirim data terenkripsi tanpa mengautentikasi pihak lain, Anda mungkin mengalami masalah. Karena klien hanya memilih kunci acak dan mengirimkannya ke tujuan di sisi lain, yang mungkin atau mungkin bukan server.

Bahkan, Anda mengirim sesuatu kepada beberapa orang yang setelah itu akan mendapatkan kesempatan untuk menguasai semua rahasia Anda.

Mengingat hal ini, orang mungkin berpikir bahwa lebih baik mengirim bukan kata sandi itu sendiri, tetapi hash-nya. Sebenarnya, ini saja tidak memberi Anda apa-apa, karena apakah Anda mengirim kata sandi atau hash kata sandi, hash kata sandi ini memiliki kekuatan semantik yang sama dengan kata sandi asli, dan itu tidak akan membantu jika Anda belum mengotentikasi server.

Jadi intinya adalah menambahkan enkripsi atau menambahkan hashing tidak selalu memberi Anda manfaat keamanan tambahan. Jika klien tidak dapat mengautentikasi kepada siapa ia mengirimkan kata sandi, maka klien dapat secara keliru mengungkapkan kata sandi kepada seseorang yang tidak bermaksud mengungkapkannya.

Oleh karena itu, mungkin ide yang lebih baik daripada dua yang sebelumnya adalah dengan menggunakan protokol tantangan / respons, atau protokol tantangan / respons. Berikut adalah contoh protokol panggilan / respons yang sangat sederhana. Di sini kami memiliki klien, dan di sini kami memiliki server. Klien memberi tahu server: "Hai, saya Alice," setelah itu server menjawabnya dengan beberapa panggilan C. Kemudian klien akan menjawab dengan hash panggilan ini yang dikirim oleh server, menggabungkannya dengan kata sandi.



Server mengetahui jawabannya, sehingga saat ini server dapat menerima urutan ini - respons klien. Server juga mengetahui tantangan yang dikirimnya, dan mungkin tahu kata sandinya, sehingga server dapat menghitung nilai hash yang diterima dan melihat bahwa itu benar-benar cocok dengan yang dikirim oleh pengguna.

Fitur positif dari protokol ini, jika kita mengabaikan keberadaan "man in the middle" untuk sesaat, adalah bahwa server akan memastikan bahwa pengguna benar-benar Alice, karena hanya Alice yang tahu kata sandi ini. Pada saat yang sama, jika Alice mengirim barang ini bukan ke server, tetapi ke orang yang berpura-pura menjadi server, maka dia tidak akan tahu kata sandinya. Karena penyerang dapat menggunakan C, tetapi dia masih tidak tahu kata sandi, dan untuk mengetahui kata sandinya, dia perlu membalikkan fungsi hash ini lagi. Anda punya pertanyaan?

Siswa: dapatkah klien alih-alih mengirim kata sandi ke server dan menerima panggilan server hash dengan hanya mengirim kata sandi hash ke server?

Profesor: yaitu, Anda bertanya mengapa klien tidak mengirim kata sandi hash ke server? Ada 2 alasan untuk ini. Kita akan membahasnya nanti, ini disebut perlindungan Antihammering dan dibuat untuk mempertahankan diri terhadap klien "jahat", terus-menerus bertanya: "apakah ini kata sandi, atau ini kata sandi, mungkin ini kata sandi?" Mekanisme otentikasi ini menyederhanakan proses untuk server dan klien, tetapi Anda pada dasarnya dapat membuat hash di sisi klien, menggunakan JavaScript atau sesuatu seperti ini. Tetapi ide dasarnya adalah bahwa Anda harus memastikan kompleksitas autentikasi maksimum untuk mencegah penyerang menebak kata sandi dengan cepat. Ada pertanyaan lagi?



Mahasiswa: Saya hanya ingin mencatat bahwa meskipun klien melakukan hashing, maka dalam kasus ketika seseorang mengambil kendali atas tabel server dan menggunakannya untuk hashing, ia akan dapat memasuki jaringan.

Profesor: benar sekali. Ya, itu menjadi sedikit berbahaya tergantung pada siapa yang dapat memiliki panggilan ini C. Karena jika klien dan server dapat memilih nilai-nilai C ini, ini mempersulit kemampuan klien untuk mengatur serangan tersebut. Salah satu masalah dengan menggunakan protokol ini adalah bahwa klien tidak dapat mengacak nilai HCC ini. Orang dapat membayangkan bahwa Anda dapat membuat protokol ini lebih rumit untuk inversi server jika klien dapat memilih beberapa panggilan C di bagian HCC, tetapi dalam hal ini akan ada penjajaran panggilan klien dan server.
Jika tidak ada pertanyaan lagi, kami akan menganggap bahwa kami telah menyelesaikan diskusi tentang mekanisme transfer kata sandi dari klien ke server. , , brute-force, -, .

, , , HCC. , «». « ».

, , , , « ». «» , « » .

Antihammer – , , . , , brute-force , . , Antihammer – , , : « ».



-, . , 10 , : « 10 , ». . «» , TPN . ? – , , , .
, , , - . , , - , , . – . , , .

, — , , — . , , . , . , , .

, , , Dictionary attack, « ». , , Microsoft Telepathwords. . , , , Telepathwords , . , , , , .



«», , , , , «».



«» , . Telepathwords? , , . , .



, . , , . , .

, Telepathwords , , , , , . .
, — , , , .

: , , IP- , Antihammer .

: , . Antihammer IP-, , . , Antihammer , – . , Antihammer , , , , , , .

, . , . , .

: Antihammer? , , ? , , SRP Zero Knowledge Protocol, ZKP, …

: , ?

: ?

:ya, digunakan. Protokol-protokol ini memberikan jaminan enkripsi yang lebih kuat. Dalam kebanyakan kasus, mereka tidak kompatibel dengan sistem saat ini, jadi dalam praktiknya Anda tidak memperhatikan seberapa sering mereka digunakan. Tetapi ada beberapa protokol yang memungkinkan server untuk tidak tahu sama sekali apa kata sandinya, seperti ZKP, yang benar-benar digunakan dalam praktiknya.

27.20 menit

Kursus MIT "Keamanan Sistem Komputer". Kuliah 17: Otentikasi Pengguna, Bagian 2


Versi lengkap dari kursus ini tersedia di sini .

Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikannya kepada teman-teman Anda, diskon 30% untuk pengguna Habr pada analog unik dari server entry-level yang kami temukan untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps dari $ 20 atau bagaimana membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps hingga Desember secara gratis ketika membayar untuk jangka waktu enam bulan, Anda dapat memesan di sini .

Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV dari $ 249 di Belanda dan Amerika Serikat! Baca tentang Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?