Apa Itu Salting dalam Keamanan? Penjelasan tentang Hashing Kata Sandi

Pada Juni 2012, seorang penyerang membocorkan 117 juta catatan akun LinkedIn ke sebuah forum Rusia. Daftar tersebut berisi banyak sekali hash SHA-1 tanpa salt. SHA-1 sangat cepat. Tanpa salt untuk memisahkan kata sandi yang identik, hash yang sama akan muncul berdampingan ribuan kali. Dalam waktu sekitar tujuh puluh dua jam, peneliti keamanan telah berhasil membongkar sekitar sembilan puluh persen dari file tersebut. Ketika pelanggaran tersebut muncul kembali pada Mei 2016 sebagai bagian dari kumpulan data 167 juta catatan, kredensial tersebut menjadi bahan bakar kampanye pencurian kredensial selama bertahun-tahun.

Strategi yang dapat mengurangi dampak kebocoran data tersebut menjadi sekadar catatan kaki—yaitu menambahkan "salt" ke setiap kata sandi yang tersimpan—sebenarnya sudah ada sejak tahun 1979. Strategi ini disebut "salting". Ini bukan hal baru, tidak mahal, dan tidak terlalu cerdas. Yang membedakan kebocoran basis data dengan masalah kata sandi yang hanya terjadi sekali saja adalah masalah yang dihadapi semua orang selama setengah dekade.

Sebagian besar kegagalan penyimpanan kata sandi modern masih berasal dari akar penyebab yang sama: seseorang memutuskan bahwa "kita menggunakan SHA-256" sudah cukup baik. Artikel ini akan menjelaskan apa sebenarnya salting itu, bagaimana cara kerjanya dalam praktik, apa yang dilindungi dan tidak dilindungi, serta apa yang direkomendasikan OWASP sebagai standar tahun 2026.

Apa itu salting dalam keamanan dan hashing kata sandi?

Sederhanakan topik ini menjadi satu kalimat. Salting berarti menambahkan data acak ke kata sandi sebelum kata sandi tersebut di-hash. Nilai acak — salt — dihasilkan sekali per akun ketika salt dihasilkan bersamaan dengan hash kata sandi baru, disimpan secara terbuka di samping hash yang dihasilkan, dan dibaca kembali setiap kali login. Ini bukan kunci. Bukan rahasia. Bukan enkripsi. Sebuah pengubah publik dengan tepat satu fungsi: memastikan bahwa ketika dua pengguna memiliki kata sandi yang sama, mereka tidak pernah berbagi kata sandi hash yang tersimpan yang sama.

Hashing sendiri bersifat satu arah. Masukkan kata sandi melalui SHA-256 atau Argon2id dan Anda akan mendapatkan nilai dengan panjang tetap yang tidak dapat dibalik oleh algoritma apa pun. Masalahnya adalah "tidak ada algoritma" mengecualikan satu jalan pintas yang mudah — mencari hash dalam kamus yang telah dihitung sebelumnya. Penambahan salt menutup jalan pintas itu. Menambahkan salt ke proses hashing membuat hash unik untuk setiap pengguna, bahkan ketika teks kata sandi mereka identik kata demi kata. Kata sandi umum seperti "password" dan "qwerty" tidak lagi bertabrakan dalam basis data. Penambahan salt memastikan kebocoran satu baris tidak memberi tahu penyerang apa pun tentang orang lain.

Tiga aturan memisahkan salt yang berguna dari salt yang tidak berguna. Aturan pertama: setiap kata sandi mendapatkan salt acaknya sendiri, yang dihasilkan baru saat pengguna mendaftar atau mengatur ulang kata sandi. Kata sandi yang diberi salt dan digunakan kembali di berbagai akun hampir tidak lebih baik daripada kata sandi tanpa salt — serangan massal bekerja dengan cara yang sama. Aturan kedua: salt dapat bersifat publik. Mengetahui salt saja tidak memberi penyerang jalan pintas terhadap fungsi hash yang mendasarinya. Jadi salt berada di dalam basis data di samping hash, dan penempatan itu baik-baik saja, bahkan dianjurkan. Aturan ketiga: nilai salt berasal dari generator angka pseudorandom yang aman secara kriptografis. Linux mengeksposnya melalui `getrandom(2)`. Node menyebutnya `crypto.randomBytes`. Pustaka standar Python membungkusnya dalam `secrets.token_bytes`. `Math.random()` yang non-kriptografis tidak cocok, meskipun muncul dalam kode yang diaudit jauh lebih sering daripada seharusnya.

Dua orang yang memilih "hunter2" sebagai kata sandi mereka seharusnya memiliki dua hash yang tersimpan yang sepenuhnya berbeda. Penambahan salt adalah yang memungkinkan hal itu terjadi. Jika salt dihilangkan, basis data tidak hanya akan membocorkan hash, tetapi juga grafik sosial tentang siapa yang berbagi kata sandi mana dengan siapa.

Bagaimana cara kerja penggaraman kata sandi?

Mekanisme tersebut terbagi menjadi empat langkah, dan sepuluh tahun terakhir kasus pelanggaran penyimpanan kata sandi menunjukkan bahwa hampir setiap kegagalan terjadi karena seseorang melewatkan salah satu langkah tersebut.

Langkah pertama berjalan saat pendaftaran. Aplikasi meminta CSPRNG untuk memasukkan enam belas hingga tiga puluh dua byte acak. Itulah salt-nya. Panduan OWASP 2025 memperlakukan enam belas byte (128 bit) sebagai batas minimum; auth0 dan beberapa vendor pengelola kata sandi merekomendasikan untuk menggunakan tiga puluh dua byte. SP 800-63B-4 dari NIST menetapkan minimum empat byte tetapi memperingatkan bahwa benturan yang dibatasi oleh tanggal lahir mulai muncul sekitar enam puluh lima ribu pengguna pada ukuran tersebut, itulah sebabnya tidak ada yang benar-benar menggunakan empat byte.

Langkah kedua menggabungkan salt dengan kata sandi yang dipilih pengguna. Penggabungan (concatenation) adalah bentuk yang paling umum, dengan salt ditempatkan sebelum atau setelah string kata sandi. Beberapa sistem menggunakan HMAC sebagai gantinya, memperlakukan salt sebagai kunci HMAC, yang menghindari beberapa masalah perpanjangan panjang yang kurang jelas dengan penggabungan mentah.

Langkah ketiga menjalankan input gabungan melalui algoritma hashing kata sandi — yang dalam buku teks kriptografi disebut fungsi derivasi kunci, atau KDF. Ini adalah langkah di mana sebagian besar tim biasanya gagal, seringkali dengan menggunakan algoritma hash generik dan menganggap pekerjaan selesai. SHA-256 biasa tidak cocok sebagai cara untuk menyimpan kata sandi. GPU konsumen pada tahun 2026 memproses lebih dari seratus miliar hash SHA-256 per detik, jadi bahkan dengan salt, biaya per tebakan dalam hashing kriptografi tetap sangat kecil. Penambahan salt membunuh vektor serangan rainbow table. Ini tidak memperlambat peretasan kata sandi dengan brute force. Alat yang tepat di sini adalah fungsi yang sengaja lambat dan membutuhkan banyak memori: Argon2id adalah default yang disukai OWASP, dengan scrypt dan bcrypt dapat diterima, dan PBKDF2 dengan jumlah iterasi yang sangat tinggi diizinkan di mana kepatuhan FIPS-140 memaksa pilihan tersebut.

Langkah keempat menyimpan hash dan salt. Pustaka modern menangani format penyimpanan sehingga Anda tidak perlu mengelola salt yang tersimpan secara manual. Output bcrypt terlihat seperti `$2b$12$9f4c8a7b...kQR8YZpL9` — string tunggal tersebut membawa pengidentifikasi algoritma, faktor biaya, salt, dan nilai hash. Argon2id menggunakan format string PHC yang analog, `$argon2id$v=19$m=19456,t=2,p=1$$`. Anda menulis string tersebut ke dalam kolom basis data dan selesai. Pustaka telah melakukan semua yang diperlukan untuk menyimpan kata sandi dengan aman — menghasilkan data acak untuk salt, menjalankan kata sandi melalui algoritma hash yang lambat, dan menggabungkan hasilnya untuk pengambilan.

Proses login mengikuti alur yang sama secara terbalik. Aplikasi mencari salt pengguna dan hash yang tersimpan, menjalankan kata sandi yang dikirimkan melalui algoritma yang sama dengan salt yang sama, dan membandingkan hasilnya dengan hash yang tersimpan menggunakan perbandingan waktu konstan. Waktu konstan itu penting: operator `==` yang sederhana membocorkan informasi tentang berapa banyak byte yang cocok, yang telah menghasilkan kerentanan serangan waktu yang nyata. Gunakan `hmac.compare_digest`, `crypto.timingSafeEqual`, atau yang setara di framework Anda.

Mengapa penambahan garam itu penting: masalah meja pelangi

Rainbow table adalah serangan spesifik yang ingin diatasi dengan penambahan salt. Bayangkan sebuah tabel pencarian yang telah dihitung sebelumnya yang memetakan setiap kata sandi yang masuk akal — setiap kata dalam kamus, variasi umum, entri daftar yang bocor — ke hash SHA-256-nya. Tabel-tabel ini ada, dijual di forum peretasan, dan ukurannya mencapai terabyte. Setelah penyerang memiliki dump basis data berisi hash tanpa salt, mencari hash dalam rainbow table hanyalah sebuah kueri basis data, bukan pekerjaan peretasan. LinkedIn 2012 berjalan persis seperti ini: 117 juta hash SHA-1 tanpa salt diuji terhadap rainbow table, sembilan puluh persen berhasil diretas dalam waktu sekitar tiga hari.

Tambahkan salt per pengguna dan rainbow table akan berhenti berfungsi. Penyerang akan membutuhkan tabel pra-komputasi terpisah untuk setiap nilai salt unik. Dengan salt acak enam belas byte, itu berarti 117 juta tabel berbeda untuk 117 juta pengguna — dan setiap tabel masih akan berukuran terabyte. Biaya penyimpanan saja sudah membuat ini tidak layak. Serangan ini pun hilang dari model ancaman.

Itulah fungsi utama dari salt. Fungsinya memang sengaja dibuat terbatas. Penggunaan salt tidak memperlambat upaya brute-force yang dilakukan terhadap satu pengguna tertentu. Penggunaan salt tidak menghentikan serangan credential-stuffing dari kebocoran sebelumnya. Penggunaan salt tidak membantu jika kata sandinya sendiri adalah "123456" — penyerang akan mencoba kamus yang jelas, dan salt akan dihitung ulang untuk setiap tebakan tetapi tidak mengubah biaya per tebakan secara signifikan.

Apa yang dapat diatasi dengan penambahan garam (salting) secara andal: tabel pelangi (rainbow table), dan kebocoran informasi penggunaan ulang kata sandi antar pengguna dalam basis data yang sama. Apa yang dapat diatasi dengan hashing lambat: biaya per tebakan. Apa yang dapat diatasi dengan pepper: pencurian hanya basis data. Apa yang dapat diatasi dengan MFA (Multi-Factor Authentication): credential stuffing. Penambahan garam adalah satu lapisan keamanan dalam tumpukan keamanan — menambahkan garam untuk mempersulit peretasan kata sandi tidak sama dengan membuat setiap kata sandi sulit ditebak secara individual. Tujuan penambahan garam adalah menghasilkan hash yang berbeda untuk setiap pengguna; membuat setiap tebakan mahal adalah masalah yang terpisah.

Hashing vs enkripsi vs salting

Tiga istilah yang sering membingungkan, terutama dalam tulisan yang ditulis oleh non-spesialis. Ketiganya tidak dapat saling menggantikan.

Enkripsi melindungi data yang ingin Anda ambil kembali nanti. Penerima memegang kunci, menerapkannya, dan membaca data aslinya. Hashing bersifat satu arah: begitu kata sandi menjadi hash, tidak ada algoritma yang dapat membalikkannya. Salting adalah pengubah yang Anda terapkan pada input fungsi hash — ia tidak memiliki arti sendiri.

Kasus pelanggaran data Adobe tahun 2013 adalah contoh peringatan di sini. Adobe menyimpan 153 juta catatan pengguna dengan mengenkripsi kata sandi menggunakan 3DES dalam mode ECB di bawah satu kunci tunggal di seluruh situs. Pilihan itu merupakan kegagalan ganda. Enkripsi adalah metode yang salah untuk penyimpanan kata sandi. Mode ECB membocorkan input yang identik sebagai output yang identik. Menggunakan kembali satu kunci di seluruh basis data berarti bahwa mendekode kunci tersebut sekali saja akan mendekode semua 153 juta catatan. Schneier menyebutnya sebagai salah satu pelanggaran kata sandi terburuk dalam sejarah. Perbaikan di setiap lapisan adalah beralih ke hashing lambat yang diberi salt.

Garam vs merica: pertahanan dua lapis

Pepper adalah sepupu salt yang kurang dikenal. Konsepnya: nilai rahasia tambahan, yang diterapkan pada setiap kata sandi yang diproses aplikasi, tetapi disimpan di luar basis data. Bisa berupa variabel lingkungan, entri layanan manajemen kunci, atau kunci yang berada di HSM. Salt berada di samping hash dalam bentuk teks biasa. Pepper tidak.

Model ancamannya adalah pencurian basis data saja. Jika penyerang hanya mencuri basis data — melalui injeksi SQL, cadangan yang salah konfigurasi, atau kebocoran data — mereka memiliki salt dan hash tetapi tidak memiliki pepper. Tanpa pepper, mereka bahkan tidak dapat memulai serangan brute-force karena setiap tebakan yang mereka buat tidak menyertakan pengubah rahasia global.

Implementasi tipikal menjalankan `argon2id(salt + password + pepper)` atau, lebih hati-hati, menghitung `HMAC(pepper, password + salt)` terlebih dahulu dan memasukkan hasilnya ke Argon2id. OWASP merekomendasikan pepper untuk sistem bernilai tinggi tetapi mengakui adanya konsekuensi: rotasi pepper secara operasional sangat merepotkan. Merotasinya berarti melakukan hashing ulang setiap kata sandi pengguna pada saat login berikutnya, dan jika pepper hilang tanpa cadangan, setiap akun menjadi tidak dapat diperiksa. Sebagian besar aplikasi konsumen melewatkan pepper. Beban kerja perbankan, pemerintah, dan layanan kesehatan biasanya tidak.

Hashing kata sandi modern di tahun 2026

Panduan penyimpanan kata sandi OWASP 2025 memberi peringkat empat algoritma berdasarkan urutan preferensi. Salt sudah terintegrasi di semua algoritma tersebut — Anda tidak perlu membuatnya secara manual.

Argon2id membutuhkan banyak memori, artinya setiap tebakan tidak hanya membutuhkan siklus CPU tetapi juga sejumlah RAM tertentu. Persyaratan minimum OWASP sebesar 19 MiB per hash berarti bahwa penyerang yang membangun ASIC khusus juga harus membangun banyak memori cepat, dan memori adalah bagian termahal dari setiap perangkat. Varian "id" menggabungkan Argon2i (tahan terhadap serangan side-channel) dan Argon2d (tahan terhadap GPU) dengan menjalankan Argon2i untuk bagian pertama dan Argon2d untuk bagian kedua.

scrypt mendahului Argon2id dan bekerja berdasarkan prinsip yang sama yang membutuhkan banyak memori. bcrypt bahkan lebih tua, lebih sederhana, dan memiliki batasan input 72 byte yang terkadang menyulitkan aplikasi yang menggunakan frasa sandi panjang — lakukan pre-hash dengan SHA-256 dan encode base64 jika Anda membutuhkan input yang lebih panjang. PBKDF2 adalah pilihan yang lambat tetapi sesuai dengan FIPS; OWASP meningkatkan jumlah iterasinya menjadi 600.000 untuk SHA-256 pada tahun 2023, naik dari 310.000.

Yang tidak termasuk dalam daftar ini: SHA-256 biasa, SHA-512 biasa, MD5, SHA-1, dan fungsi khusus apa pun yang diakhiri dengan "+ salt". Kecepatan adalah faktor yang mendiskualifikasi. SHA-256 dirancang agar cepat pada perangkat keras standar. Itu adalah kebalikan dari apa yang dibutuhkan penyimpanan kata sandi.

Kesalahan umum dalam pemberian garam yang muncul dalam audit sebenarnya

Laporan pelanggaran data di dunia nyata terus menunjukkan sejumlah kesalahan yang sama.

Menggunakan satu salt yang sama untuk setiap pengguna akan menggagalkan seluruh mekanisme — masalah rainbow table kembali muncul, hanya dengan satu langkah tambahan. Menggunakan nama pengguna sebagai salt lebih buruk, karena nama pengguna berulang di berbagai sistem dan rainbow table dapat dihitung sebelumnya untuk nama pengguna yang populer. Panjang salt di bawah enam belas byte mulai menimbulkan benturan pada skala basis pengguna yang besar. Menghasilkan salt dengan fungsi acak non-kriptografis — `Math.random()`, `time(0)` mod sesuatu, RNG default bahasa pemrograman — menghasilkan nilai yang dapat diprediksi yang menghilangkan manfaat dari penggunaan salt.

Kesalahan yang lebih halus adalah menyimpan salt di server yang berbeda "untuk alasan keamanan." Salt bukanlah rahasia. Memisahkannya di beberapa sistem menambah kompleksitas operasional tanpa menambah kekuatan kriptografi apa pun. Simpanlah di baris yang sama dengan hash. String PHC modern melakukan ini untuk Anda.

Masalah terbesar, dalam audit tahun 2026, adalah hashing dengan SHA-256 biasa ditambah salt dan pengiriman. Salt mencegah rainbow table. Ini tidak berpengaruh pada farm GPU yang menjalankan sepuluh miliar tebakan per detik terhadap satu akun. Solusinya bukanlah menambahkan salt kedua; melainkan beralih ke KDF yang lambat seperti Argon2id.

Terakhir: hash lama yang tidak diberi salt. Migrasi bukan pilihan. Pola standarnya adalah memverifikasi hash lama pada login berikutnya, melakukan rehash dengan algoritma modern, dan menimpa. Untuk pengguna yang tidak pernah login lagi, paksa pengaturan ulang kata sandi pada jangka waktu tetap.

Mengapa penggaraman saja tidak cukup

Penggunaan salt hanyalah lapisan pelindung, bukan benteng. Ia hanya mampu mengatasi satu serangan spesifik—tabel pra-komputasi—dan tidak mengungkapkan apa pun tentang kekuatan kata sandi yang mendasarinya. Serangan brute force masih efektif terhadap kata sandi yang lemah. Serangan credential stuffing masih efektif terhadap kata sandi yang digunakan kembali. Serangan phishing masih efektif terhadap kata sandi apa pun.

Keamanan kata sandi yang sesungguhnya di tahun 2026 menggabungkan empat pertahanan. Argon2id dengan salt 16 byte per pengguna menangani penyimpanan. Pepper, opsional tetapi bermanfaat untuk sistem sensitif, memblokir pencurian hanya melalui basis data. Otentikasi multi-faktor memblokir credential stuffing dan sebagian besar phishing. Pemantauan pelanggaran berkelanjutan — layanan seperti Have I Been Pwned dan API-nya — menangkap momen ketika kredensial pengguna muncul dalam kebocoran sehingga mereka dapat dipaksa untuk mengatur ulang.

Jika salah satu lapisan tersebut dilewati, penyerang pada akhirnya akan menemukan celah. Penggunaan salting saja, atau satu pertahanan saja, persis seperti yang diidentifikasi oleh setiap analisis pasca-pelanggaran dalam dekade terakhir sebagai titik kegagalan.

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.