If-Koubou

Mengapa Anda Harus Khawatir Setiap Kali Basis Data Kata Sandi Layanan Dibocorkan

Mengapa Anda Harus Khawatir Setiap Kali Basis Data Kata Sandi Layanan Dibocorkan (Bagaimana caranya)

“Database kata sandi kami dicuri kemarin. Tetapi jangan khawatir: kata sandi Anda dienkripsi. ”Kami secara teratur melihat pernyataan seperti ini secara online, termasuk kemarin, dari Yahoo. Tetapi haruskah kita benar-benar mengambil jaminan ini pada nilai nominalnya?

Kenyataannya adalah kompromi basis data kata sandi adalah kekhawatiran, tidak peduli bagaimana perusahaan dapat mencoba untuk memutarnya. Tetapi ada beberapa hal yang dapat Anda lakukan untuk melindungi diri sendiri, tidak peduli seberapa buruk praktik keamanan perusahaan.

Bagaimana Kata Sandi Harus Disimpan

Inilah cara perusahaan menyimpan kata sandi di dunia yang ideal: Anda membuat akun dan memberikan kata sandi. Alih-alih menyimpan kata sandi itu sendiri, layanan menghasilkan "hash" dari kata sandi. Ini adalah sidik jari unik yang tidak dapat dibalik. Misalnya, kata sandi "kata sandi" dapat berubah menjadi sesuatu yang lebih mirip "4jfh75to4sud7gh93247g…". Ketika Anda memasukkan kata sandi untuk masuk, layanan menghasilkan hash dari itu dan memeriksa apakah nilai hash sesuai dengan nilai yang disimpan dalam database. Tidak pernah ada layanan yang menyimpan kata sandi Anda sendiri ke disk.

Untuk menentukan kata sandi Anda yang sebenarnya, penyerang yang memiliki akses ke database harus melakukan pra-komputasi hash untuk kata sandi umum dan kemudian memeriksa apakah ada dalam database. Penyerang melakukan ini dengan mencari daftar besar hash yang cocok dengan kata sandi. Hash kemudian dapat dibandingkan dengan database. Sebagai contoh, seorang penyerang akan tahu hash untuk “kata sandi1” dan kemudian melihat apakah ada akun dalam database yang menggunakan hash itu. Jika ya, penyerang tahu kata sandinya adalah “kata sandi1”.

Untuk mencegah hal ini, layanan harus "mengeringkan" hash mereka. Alih-alih membuat hash dari kata sandi itu sendiri, mereka menambahkan string acak ke depan atau akhir kata sandi sebelum hashing itu. Dengan kata lain, pengguna akan memasukkan kata sandi “kata sandi” dan layanan akan menambahkan garam dan hash kata sandi yang lebih mirip “password35s2dg.” Setiap akun pengguna harus memiliki garam unik mereka sendiri, dan ini akan memastikan bahwa setiap akun pengguna akan memiliki nilai hash yang berbeda untuk kata sandi mereka dalam database. Bahkan jika beberapa akun menggunakan kata sandi “kata sandi1”, mereka akan memiliki hash yang berbeda karena nilai-nilai garam yang berbeda. Ini akan mengalahkan penyerang yang mencoba hash pra-komputasi untuk kata sandi. Alih-alih mampu menghasilkan hash yang diterapkan ke setiap akun pengguna di seluruh basis data sekaligus, mereka harus menghasilkan hash unik untuk setiap akun pengguna dan garam uniknya. Ini akan membutuhkan lebih banyak waktu dan memori perhitungan.

Inilah sebabnya layanan sering mengatakan tidak perlu khawatir. Layanan yang menggunakan prosedur keamanan yang tepat harus mengatakan mereka menggunakan hash sandi yang diasinkan. Jika mereka hanya mengatakan kata sandi adalah "hash," itu lebih mengkhawatirkan. LinkedIn mencirikan kata sandinya, misalnya, tetapi mereka tidak mencemari mereka-jadi itu adalah masalah besar ketika LinkedIn kehilangan 6,5 juta kata sandi di tahun 2012.

Praktek Kata Sandi Buruk

Ini bukan hal yang paling sulit untuk diterapkan, tetapi banyak situs masih bisa mengacaukannya dalam berbagai cara:

  • Menyimpan Sandi dalam Teks Biasa: Daripada repot dengan hashing, beberapa pelanggar terburuk mungkin hanya membuang kata sandi dalam bentuk teks biasa ke dalam database. Jika database semacam itu disusupi, kata sandi Anda jelas-jelas dikompromikan. Tidak masalah seberapa kuat mereka.
  • Mencambuk Kata Sandi Tanpa Mengikatnya: Beberapa layanan mungkin memiliki kata sandi dan menyerah di sana, memilih untuk tidak menggunakan garam. Database kata sandi semacam itu akan sangat rentan terhadap tabel pencarian. Seorang penyerang dapat menghasilkan hash untuk banyak kata sandi dan kemudian memeriksa apakah ada dalam database - mereka dapat melakukan ini untuk setiap akun sekaligus jika tidak ada garam yang digunakan.
  • Menggunakan kembali garam: Beberapa layanan mungkin menggunakan garam, tetapi mereka dapat menggunakan kembali garam yang sama untuk setiap kata sandi akun pengguna. Ini tidak ada gunanya — jika garam yang sama digunakan untuk setiap pengguna, dua pengguna dengan kata sandi yang sama akan memiliki hash yang sama.
  • Menggunakan Garam Pendek: Jika garam hanya beberapa digit digunakan, adalah mungkin untuk menghasilkan tabel pencarian yang menggabungkan setiap garam yang mungkin. Misalnya, jika satu digit digunakan sebagai garam, penyerang dapat dengan mudah menghasilkan daftar hash yang menggabungkan setiap garam yang mungkin.

Perusahaan tidak akan selalu memberi tahu Anda keseluruhan ceritanya, sehingga bahkan jika mereka mengatakan kata sandi di-hash (atau dicirikan dan diasinkan), mereka mungkin tidak menggunakan praktik terbaik. Selalu keliru di sisi hati-hati.

Kekhawatiran Lainnya

Kemungkinan nilai garam juga ada dalam basis data kata sandi. Ini tidak terlalu buruk - jika nilai garam unik digunakan untuk setiap pengguna, penyerang harus menghabiskan sejumlah besar daya CPU untuk memecahkan semua kata sandi tersebut.

Dalam praktiknya, begitu banyak orang menggunakan kata sandi yang jelas sehingga akan mudah untuk menentukan banyak kata sandi akun pengguna. Misalnya, jika penyerang tahu hash Anda dan mereka tahu garam Anda, mereka dapat dengan mudah memeriksa untuk melihat apakah Anda menggunakan beberapa kata sandi yang paling umum.

Jika seorang penyerang mengeluarkannya untuk Anda dan ingin memecahkan kata sandi Anda, mereka dapat melakukannya dengan kekerasan selama mereka mengetahui nilai garam yang mungkin mereka lakukan. Dengan akses offline lokal ke basis data kata sandi, penyerang dapat menggunakan semua serangan brute force yang mereka inginkan.

Data pribadi lainnya juga kemungkinan bocor ketika database kata sandi dicuri: Nama pengguna, alamat email, dan banyak lagi. Dalam kasus kebocoran Yahoo, pertanyaan dan jawaban keamanan juga bocor — yang, seperti kita ketahui, mempermudah pencurian akses ke akun seseorang.

Bantuan, Apa yang Harus Saya Lakukan?

Apa pun layanan yang dikatakan ketika basis data kata sandinya dicuri, yang terbaik adalah menganggap bahwa setiap layanan benar-benar tidak kompeten dan bertindak sesuai dengan itu.

Pertama, jangan gunakan kembali kata sandi di beberapa situs web. Gunakan pengelola kata sandi yang menghasilkan kata sandi unik untuk setiap situs web. Jika seorang penyerang berhasil menemukan bahwa kata sandi Anda untuk sebuah layanan adalah "43 ^ tSd% 7uho2 # 3" dan Anda hanya menggunakan kata sandi itu di satu situs web tertentu, mereka telah belajar tidak ada gunanya. Jika Anda menggunakan kata sandi yang sama di mana-mana, mereka dapat mengakses akun Anda yang lain. Ini adalah berapa banyak akun orang yang menjadi "diretas."

Jika suatu layanan menjadi terganggu, pastikan untuk mengubah kata sandi yang Anda gunakan di sana. Anda juga harus mengubah kata sandi di situs lain jika Anda menggunakannya kembali di sana - tetapi Anda seharusnya tidak melakukan itu di tempat pertama.

Anda juga harus mempertimbangkan untuk menggunakan otentikasi dua faktor, yang akan melindungi Anda bahkan jika penyerang belajar kata sandi Anda.

Yang paling penting adalah tidak menggunakan kembali kata sandi. Database kata sandi yang dikompromikan tidak dapat melukai Anda jika Anda menggunakan kata sandi yang unik di mana-mana - kecuali mereka menyimpan sesuatu yang penting dalam database, seperti nomor kartu kredit Anda.

Kredit Gambar: Marc Falardeau di Flickr, Wikimedia Commons