Bagaimana Kami Melindungi Kata Sandi Anda

Dalam artikel sebelumnya, kami membahas bagaimana HTTPS melindungi jalur antara aplikasi Anda dan server kami, serta bagaimana SSH mengamankan server itu sendiri. Sekarang, mari kita lihat ke dalam server — bagaimana Splync menjaga keamanan kata sandi Anda setelah tiba di sana. Jika seseorang mendapatkan kata sandi Anda, orang tersebut dapat masuk ke akun Anda dan mengakses informasi sensitif, termasuk catatan pengeluaran Anda. Itulah mengapa Splync tidak pernah menyimpan kata sandi dalam teks biasa. Sebagai gantinya, setiap kata sandi diubah menjadi versi hash sebelum disimpan di database. Apa artinya ini? Hashing adalah konversi satu arah — setelah diubah, tidak dapat dikembalikan ke kata sandi asli. Metode ini adalah standar di seluruh internet, dari bank hingga layanan cloud besar, namun banyak orang tidak tahu bagaimana cara kerjanya. Mari kita jelajahi melalui analogi sehari-hari yang sederhana.

Untuk memahami bagaimana perlindungan kata sandi bekerja, mari kita mulai dengan metode hashing sederhana yang disebut SHA-256. Anggaplah sebagai blender yang selalu mencampur bahan dengan cara yang sama. Jika Anda memasukkan kata sandi yang sama ke dalam blender dan menekan tombol, Anda akan selalu mendapatkan "smoothie" unik — campuran acak huruf dan angka. Ide utamanya adalah bahwa proses ini tidak dapat dibalik. Sama seperti Anda tidak bisa mengambil smoothie dan memisahkannya kembali menjadi pisang dan susu asli, Anda tidak bisa mengambil hash acak dan mendapatkan kembali kata sandi asli.

SHA-256 adalah salah satu algoritma hashing yang paling umum. Misalnya, ia mem-hash kata sandi "splync1234" menjadi "9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41". Dalam hitungan milidetik, setiap kali pengguna yang sudah ada memasukkan kata sandi, SHA-256 selalu menghasilkan kata sandi hash yang sama. Aplikasi cukup mem-hash kembali kata sandi yang dimasukkan dan memeriksa apakah cocok dengan hash yang disimpan. Sistem tidak pernah mengetahui kata sandi asli pengguna. Namun, bagaimana jika seorang penyerang telah menghitung sebelumnya daftar kata sandi umum dan hash-nya (dikenal sebagai serangan tabel pelangi) untuk menebak kata sandi pengguna dengan cepat? Kekhawatiran ini sangat nyata. Inilah mengapa sistem modern, termasuk Splync, tidak mengandalkan SHA-256 biasa.

Bcrypt menggunakan salt acak per pengguna dan menyandikan salt tersebut (dan faktor biaya) langsung ke dalam string hash yang disimpan. Anggap bcrypt sebagai blender dengan bumbu rahasia (salt) dan motor lambat (faktor kerja) — membuat setiap campuran unik dan sulit untuk disalin. Karena salt adalah 128 bit (≈3×10³⁸ kemungkinan), kata sandi yang sama dapat dipetakan ke sejumlah besar hash yang berbeda. Ini membuat tabel pelangi yang telah dihitung sebelumnya tidak berguna dalam skala besar. Saat login, Splync membaca salt dan biaya dari string bcrypt yang disimpan, menjalankan kembali bcrypt pada kata sandi yang dimasukkan dengan parameter tersebut, dan membandingkan hasilnya dengan hash yang disimpan. Jika cocok, maka kata sandi benar — tetapi karena bcrypt sengaja lambat dan salt unik, serangan brute-force menjadi jauh lebih mahal bagi penyerang.

Mari kita lihat bagaimana ini terlihat dalam praktik. Jika Anda meng-hash kata sandi "splync1234" dengan bcrypt (menggunakan biaya 12), Anda mungkin mendapatkan string seperti ini: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. Dalam string bcrypt ini, `$2b` menandai versi algoritma, `$12` menunjukkan faktor biaya (berapa kali kata sandi diproses), `gBeouKYdue9uvvuV0HtGgeV` adalah salt acak unik, dan `PymnrojMqP/wcRw28HFlGEGIQbyw7O` adalah kata sandi hash akhir. Karena hash itu sendiri mengandung salt dan biaya, Splync dapat mereproduksi proses hashing yang sama untuk verifikasi dengan mengekstrak nilai tersebut dari string yang disimpan dan membandingkan hasilnya. Di sisi lain, jika penyerang tidak mengetahui salt dan biaya, mereka tidak dapat membangun satu tabel pelangi yang berfungsi untuk setiap pengguna.

Pendekatan ini memiliki keuntungan penting lainnya. Karena Splync tidak pernah menyimpan kata sandi secara langsung, bahkan jika database bocor atau dicuri, pengguna tidak segera berisiko. Penyerang tidak dapat langsung masuk dengan data yang dicuri, karena yang mereka miliki hanyalah string acak. Desain ini memberikan pengguna lapisan perlindungan ekstra, di atas perlindungan yang sudah ada di sekitar server itu sendiri. Hashing kata sandi bukanlah hal yang unik bagi Splync; ini adalah standar di seluruh industri teknologi, digunakan oleh perusahaan besar seperti Google, Apple, dan Amazon. Splync dibangun dengan sangat aman, dan akan semakin aman seiring peningkatan keamanan dengan fitur seperti verifikasi email, perlindungan brute-force, dan pemantauan berkelanjutan.