Beranda » bagaimana » Mengapa Anda Harus Khawatir Setiap Kali Basis Data Kata Sandi Layanan Kebocoran

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

    “Basis data kata sandi kami dicuri kemarin. Tapi 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 nominal?

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

    Bagaimana Kata Sandi Harus Disimpan

    Inilah cara perusahaan harus 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 login, layanan menghasilkan hash dari itu dan memeriksa apakah nilai hash cocok dengan nilai yang disimpan dalam database. Tidak ada titik apakah layanan pernah menyimpan kata sandi Anda sendiri ke disk.

    Untuk menentukan kata sandi Anda yang sebenarnya, penyerang dengan akses ke basis data harus melakukan pra-komputasi hash untuk kata sandi yang umum dan kemudian memeriksa apakah ada di dalam basis data. Penyerang melakukan ini dengan tabel pencarian - daftar besar hash yang cocok dengan kata sandi. Hash kemudian dapat dibandingkan dengan database. Sebagai contoh, seorang penyerang akan mengetahui hash untuk "password1" dan kemudian melihat apakah ada akun dalam database yang menggunakan hash itu. Jika ya, penyerang tahu kata sandi mereka adalah "kata sandi1".

    Untuk mencegah hal ini, layanan harus "memberi garam" hash mereka. Alih-alih membuat hash dari kata sandi itu sendiri, mereka menambahkan string acak ke bagian depan atau akhir kata sandi sebelum hashing. Dengan kata lain, pengguna akan memasukkan kata sandi "kata sandi" dan layanan akan menambahkan garam dan hash kata sandi yang lebih mirip "kata sandi 35s2dg." 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 banyak akun menggunakan kata sandi “kata sandi1”, mereka akan memiliki hash yang berbeda karena nilai garam yang berbeda. Ini akan mengalahkan penyerang yang mencoba melakukan pre-compute hash untuk kata sandi. Alih-alih dapat menghasilkan hash yang diterapkan ke setiap akun pengguna di seluruh database sekaligus, mereka harus menghasilkan hash unik untuk setiap akun pengguna dan garam uniknya. Ini akan membutuhkan lebih banyak waktu dan memori komputasi.

    Inilah sebabnya mengapa layanan sering mengatakan tidak perlu khawatir. Layanan yang menggunakan prosedur keamanan yang benar harus mengatakan bahwa mereka menggunakan hash kata sandi asin. Jika mereka hanya mengatakan kata sandi "hash," itu lebih mengkhawatirkan. LinkedIn telah mengacak kata sandi mereka, misalnya, tetapi mereka tidak memberi mereka garam - jadi itu adalah masalah besar ketika LinkedIn kehilangan 6,5 juta kata sandi hash pada 2012.

    Praktek Kata Sandi Buruk

    Ini bukan hal tersulit untuk diterapkan, tetapi banyak situs web yang masih mengacaukannya dengan berbagai cara:

    • Menyimpan Kata Sandi dalam Teks Biasa: Daripada repot dengan hashing, beberapa pelanggar terburuk mungkin hanya membuang kata sandi dalam bentuk teks biasa ke dalam basis data. Jika database seperti itu dikompromikan, kata sandi Anda jelas terganggu. Tidak masalah seberapa kuat mereka.
    • Hashing Passwords Tanpa Mengasinkan Mereka: Beberapa layanan mungkin meng-hash kata sandi dan menyerah di sana, memilih untuk tidak menggunakan garam. Database kata sandi seperti itu akan sangat rentan terhadap tabel pencarian. Seorang penyerang dapat menghasilkan hash untuk banyak kata sandi dan kemudian memeriksa apakah ada di 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, akan mungkin untuk menghasilkan tabel pencarian yang memasukkan setiap garam yang mungkin. Misalnya, jika satu digit digunakan sebagai garam, penyerang dapat dengan mudah membuat daftar hash yang memasukkan setiap garam yang mungkin.

    Perusahaan tidak akan selalu menceritakan keseluruhan cerita kepada Anda, jadi bahkan jika mereka mengatakan kata sandi di-hash (atau hash dan salin), mereka mungkin tidak menggunakan praktik terbaik. Selalu berbuat salah di sisi hati-hati.

    Kekhawatiran lainnya

    Kemungkinan nilai garam juga ada di basis data kata sandi. Ini tidak seburuk itu - 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 mudah untuk menentukan kata sandi banyak akun pengguna. Misalnya, jika penyerang mengetahui hash Anda dan mereka tahu garam Anda, mereka dapat dengan mudah memeriksa untuk melihat apakah Anda menggunakan beberapa kata sandi yang paling umum.

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

    Data pribadi lainnya juga kemungkinan bocor ketika basis data kata sandi dicuri: Nama pengguna, alamat email, dan banyak lagi. Dalam kasus kebocoran Yahoo, pertanyaan dan jawaban keamanan juga bocor - yang, seperti kita semua tahu, membuatnya lebih mudah untuk mencuri akses ke akun seseorang.

    Bantuan, Apa yang Harus Saya Lakukan?

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

    Pertama, jangan menggunakan kembali kata sandi di banyak 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 suatu layanan adalah "43 ^ tSd% 7uho2 # 3" dan Anda hanya menggunakan kata sandi itu di satu situs web tertentu, mereka tidak mempelajari apa pun yang berguna. 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 dikompromikan, 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 melakukannya sejak awal.

    Anda juga harus mempertimbangkan untuk menggunakan otentikasi dua faktor, yang akan melindungi Anda meskipun penyerang mempelajari kata sandi Anda.

    Yang paling penting adalah tidak menggunakan kembali kata sandi. Basis data kata sandi yang dikompromikan tidak dapat menyakiti Anda jika Anda menggunakan kata sandi unik di mana-mana - kecuali mereka menyimpan hal lain yang penting dalam basis data, seperti nomor kartu kredit Anda.

    Kredit Gambar: Marc Falardeau di Flickr, Wikimedia Commons