Hash dan garam aman untuk kata sandi PHP

Saat ini dikatakan bahwa MD5 tidak aman sebagian. Mempertimbangkan hal ini, saya ingin tahu mekanisme mana yang digunakan untuk perlindungan kata sandi.

Pertanyaan ini, Apakah "hashing ganda" kata sandi kurang aman daripada hanya hashing sekali saja? menunjukkan bahwa hashing beberapa kali mungkin merupakan ide yang baik, sedangkan Bagaimana menerapkan perlindungan kata sandi untuk file individual? menyarankan menggunakan garam.

Saya menggunakan PHP. Saya ingin sistem enkripsi kata sandi yang aman dan cepat. Hashing kata sandi sejuta kali mungkin lebih aman, tetapi juga lebih lambat. Bagaimana cara mencapai keseimbangan yang baik antara kecepatan dan keamanan? Juga, saya lebih suka hasilnya memiliki jumlah karakter yang konstan.

1. Mekanisme hashing harus tersedia dalam PHP
2. Itu harus aman
3. Itu bisa menggunakan garam (dalam hal ini, apakah semua garam sama baiknya? Apakah ada cara untuk menghasilkan garam yang baik?)

Juga, haruskah saya menyimpan dua bidang dalam basis data (satu menggunakan MD5 dan satu lagi menggunakan SHA, misalnya)? Apakah itu membuatnya lebih aman atau tidak aman?

Jika saya tidak cukup jelas, saya ingin tahu fungsi hashing mana yang harus digunakan dan cara memilih garam yang baik agar memiliki mekanisme perlindungan kata sandi yang aman dan cepat.

Pertanyaan terkait yang tidak cukup mencakup pertanyaan saya:

Apa perbedaan antara SHA dan MD5 dalam PHP
Simple Password Enkripsi
Metode aman menyimpan kunci, kata sandi untuk asp.net
Bagaimana Anda menerapkan kata sandi asin di Tomcat 5.5

PENOLAKAN : Jawaban ini ditulis pada tahun 2008.

Sejak itu, PHP telah memberi kami password_hashdan password_verify, dan sejak diperkenalkan, mereka adalah metode hashing & checking kata sandi yang direkomendasikan.

Teori jawabannya masih bagus untuk dibaca.

TL; DR

Larangan

• Jangan batasi karakter apa yang dapat dimasukkan oleh pengguna untuk kata sandi. Hanya orang idiot yang melakukan ini.
• Jangan batasi panjang kata sandi. Jika pengguna Anda menginginkan kalimat dengan supercalifragilisticexpialidocious di dalamnya, jangan mencegah mereka menggunakannya.
• Jangan menghapus atau melepaskan HTML dan karakter khusus dalam kata sandi.
• Jangan pernah menyimpan kata sandi pengguna Anda dalam teks biasa.
• Jangan pernah mengirim email kata sandi kepada pengguna Anda kecuali jika kata sandi itu hilang, dan Anda mengirimnya sementara.
• Tidak pernah, pernah login kata sandi dengan cara apa pun.
• Kata sandi hash dengan SHA1 atau MD5 atau bahkan SHA256! Kerupuk modern dapat melebihi 60 dan 180 miliar hash / detik (masing-masing).
• Jangan mencampur bcrypt dan dengan output mentah dari hash () , baik gunakan output hex atau base64_encode itu. (Ini berlaku untuk input apa pun yang mungkin memiliki gangguan \0di dalamnya, yang dapat melemahkan keamanan dengan serius.)

Dos

• Gunakan scrypt ketika Anda bisa; bcrypt jika Anda tidak bisa.
• Gunakan PBKDF2 jika Anda tidak dapat menggunakan bcrypt atau scrypt, dengan hash SHA2.
• Setel ulang kata sandi semua orang ketika basis data dikompromikan.
• Menerapkan panjang minimum 8-10 karakter yang wajar, ditambah membutuhkan setidaknya 1 huruf besar, 1 huruf kecil, angka, dan simbol. Ini akan meningkatkan entropi kata sandi, yang pada gilirannya membuatnya lebih sulit untuk dipecahkan. (Lihat bagian "Apa yang membuat kata sandi yang baik?" Untuk beberapa perdebatan.)

Kenapa sih kata sandi hash?

Tujuan di balik hashing passwords sederhana: mencegah akses berbahaya ke akun pengguna dengan membahayakan basis data. Jadi tujuan dari hashing kata sandi adalah untuk mencegah seorang hacker atau cracker dengan biaya terlalu banyak waktu atau uang untuk menghitung kata sandi teks biasa. Dan waktu / biaya adalah pencegah terbaik dalam gudang senjata Anda.

Alasan lain Anda menginginkan hash yang baik dan kuat di akun pengguna adalah memberi Anda cukup waktu untuk mengubah semua kata sandi dalam sistem. Jika database Anda dikompromikan, Anda akan memerlukan waktu yang cukup untuk setidaknya mengunci sistem, jika tidak mengubah setiap kata sandi dalam database.

Jeremiah Grossman, CTO dari Whitehat Security, menyatakan di blog White Hat Security setelah pemulihan kata sandi baru-baru ini yang membutuhkan kekerasan terhadap proteksi kata sandi:

Menariknya, dalam menjalani mimpi buruk ini, saya belajar BANYAK yang tidak saya ketahui tentang pemecahan kata sandi, penyimpanan, dan kompleksitas. Saya menghargai mengapa penyimpanan kata sandi jauh lebih penting daripada kompleksitas kata sandi. Jika Anda tidak tahu bagaimana kata sandi Anda disimpan, maka yang benar-benar dapat Anda andalkan adalah kompleksitas. Ini mungkin pengetahuan umum untuk kata sandi dan pro kripto, tetapi untuk rata-rata InfoSec atau pakar Keamanan Web, saya sangat meragukannya.

(Penekanan milikku.)

Apa yang membuat kata sandi yang baik ?

Entropi . (Bukannya aku sepenuhnya berlangganan sudut pandang Randall.)

Singkatnya, entropi adalah seberapa banyak variasi dalam kata sandi. Ketika kata sandi hanya huruf kecil roman, itu hanya 26 karakter. Itu tidak banyak variasi. Kata sandi alfa-numerik lebih baik, dengan 36 karakter. Tetapi memungkinkan huruf besar dan kecil, dengan simbol, kira-kira 96 ​​karakter. Itu jauh lebih baik dari sekedar surat. Satu masalah adalah, untuk membuat kata sandi kita mudah diingat, kita memasukkan pola — yang mengurangi entropi. Ups!

Entropi kata sandi diperkirakan dengan mudah. Menggunakan berbagai karakter ascii (kira-kira 96 ​​karakter yang dapat diketik) menghasilkan entropi 6,6 per karakter, yang pada 8 karakter untuk kata sandi masih terlalu rendah (52,679 bit entropi) untuk keamanan di masa depan. Tetapi kabar baiknya adalah: kata sandi yang lebih panjang, dan kata sandi dengan karakter unicode, benar-benar meningkatkan entropi kata sandi dan membuatnya lebih sulit untuk dipecahkan.

Ada diskusi yang lebih panjang tentang entropi kata sandi di situs Crypto StackExchange . Pencarian Google yang baik juga akan menghasilkan banyak hasil.

Dalam komentar saya berbicara dengan @popnoodles, yang menunjukkan bahwa menegakkan kebijakan kata sandi dengan panjang X dengan X banyak huruf, angka, simbol, dll, sebenarnya dapat mengurangi entropi dengan membuat skema kata sandi lebih dapat diprediksi. Saya setuju. Randomess, senyata mungkin, selalu merupakan solusi teraman tetapi paling tidak diingat.

Sejauh yang saya tahu, membuat kata sandi terbaik di dunia adalah Catch-22. Entah itu tidak berkesan, terlalu dapat diprediksi, terlalu pendek, terlalu banyak karakter unicode (sulit untuk mengetik pada perangkat Windows / Mobile), terlalu lama, dll. Tidak ada kata sandi yang cukup baik untuk tujuan kita, jadi kita harus melindunginya seolah-olah mereka berada di Fort Knox.

Praktik terbaik

Bcrypt dan scrypt adalah praktik terbaik saat ini. Scrypt akan lebih baik daripada bcrypt dalam waktu, tetapi belum melihat adopsi sebagai standar oleh Linux / Unix atau oleh webservers, dan belum memiliki ulasan mendalam tentang algoritma yang diposting. Tapi tetap saja, masa depan algoritma memang terlihat menjanjikan. Jika Anda bekerja dengan Ruby ada permata scrypt yang akan membantu Anda, dan Node.js sekarang memiliki paket scrypt sendiri . Anda dapat menggunakan Scrypt dalam PHP baik melalui ekstensi Scrypt atau ekstensi Libsodium (keduanya tersedia dalam PECL).

Saya sangat menyarankan membaca dokumentasi untuk fungsi crypt jika Anda ingin memahami cara menggunakan bcrypt, atau menemukan diri Anda pembungkus yang baik atau menggunakan sesuatu seperti PHPASS untuk implementasi yang lebih lama. Saya merekomendasikan minimal 12 putaran bcrypt, jika tidak 15 hingga 18.

Saya berubah pikiran tentang menggunakan bcrypt ketika saya mengetahui bahwa bcrypt hanya menggunakan jadwal kunci blowfish, dengan mekanisme biaya variabel. Yang terakhir memungkinkan Anda meningkatkan biaya untuk memaksa kata sandi dengan meningkatkan jadwal kunci blowfish yang sudah mahal.

Praktek rata-rata

Saya hampir tidak bisa membayangkan situasi ini lagi. PHPASS mendukung PHP 3.0.18 hingga 5.3, sehingga dapat digunakan di hampir setiap instalasi yang dapat dibayangkan — dan harus digunakan jika Anda tidak tahu pasti bahwa lingkungan Anda mendukung bcrypt.

Tetapi misalkan Anda tidak dapat menggunakan bcrypt atau PHPASS sama sekali. Lalu bagaimana?

Coba implementasi PDKBF2 dengan jumlah putaran maksimum yang dapat ditoleransi oleh lingkungan / aplikasi / persepsi pengguna Anda. Angka terendah yang saya sarankan adalah 2500 putaran. Juga, pastikan untuk menggunakan hash_hmac () jika tersedia untuk membuat operasi lebih sulit untuk direproduksi.

Praktek Masa Depan

Datang dalam PHP 5.5 adalah pustaka perlindungan kata sandi lengkap yang menghilangkan segala kesulitan bekerja dengan bcrypt. Sementara sebagian besar dari kita terjebak dengan PHP 5.2 dan 5.3 di lingkungan yang paling umum, terutama host bersama, @ircmaxell telah membangun lapisan kompatibilitas untuk API yang akan datang yang kompatibel dengan PHP 5.3.7.

Rekap Kriptografi & Penafian

Kekuatan komputasi yang diperlukan untuk benar-benar memecahkan kata sandi hash tidak ada. Satu-satunya cara bagi komputer untuk "memecahkan" kata sandi adalah membuatnya kembali dan mensimulasikan algoritma hashing yang digunakan untuk mengamankannya. Kecepatan hash secara linear terkait dengan kemampuannya untuk menjadi kasar. Lebih buruk lagi, sebagian besar algoritma hash dapat dengan mudah diparalelkan untuk melakukan lebih cepat. Inilah sebabnya mengapa skema mahal seperti bcrypt dan scrypt sangat penting.

Anda tidak mungkin dapat melihat semua ancaman atau jalan serangan, dan karenanya Anda harus melakukan upaya terbaik untuk melindungi pengguna Anda di muka . Jika tidak, maka Anda bahkan mungkin kehilangan fakta bahwa Anda diserang sampai terlambat ... dan Anda bertanggung jawab . Untuk menghindari situasi itu, mulailah bertindak paranoid. Serang perangkat lunak Anda sendiri (secara internal) dan berupaya mencuri kredensial pengguna, atau memodifikasi akun pengguna lain atau mengakses data mereka. Jika Anda tidak menguji keamanan sistem Anda, maka Anda tidak dapat menyalahkan siapa pun selain diri Anda sendiri.

Terakhir: Saya bukan seorang cryptographer. Apa pun yang saya katakan adalah pendapat saya, tetapi kebetulan saya pikir itu didasarkan pada akal sehat ... dan banyak membaca. Ingat, jadilah paranoid mungkin, buat hal-hal sesulit mungkin untuk mengganggu, dan kemudian, jika Anda masih khawatir, hubungi peretas topi putih atau kriptografi untuk melihat apa yang mereka katakan tentang kode / sistem Anda.

Jawaban yang jauh lebih singkat dan lebih aman - jangan menulis mekanisme kata sandi Anda sendiri , gunakan mekanisme yang sudah dicoba dan diuji.

• PHP 5.5 atau lebih tinggi: password_hash () berkualitas baik dan merupakan bagian dari inti PHP.
• Versi PHP yang lebih lama: Pustaka phpass OpenWall jauh lebih baik daripada kebanyakan kode khusus - digunakan di WordPress, Drupal, dll.

Sebagian besar programmer tidak memiliki keahlian untuk menulis kode terkait crypto dengan aman tanpa memperkenalkan kerentanan.

Tes mandiri cepat: apa itu peregangan kata sandi dan berapa banyak iterasi yang harus Anda gunakan? Jika Anda tidak tahu jawabannya, Anda harus menggunakan password_hash(), karena peregangan kata sandi sekarang merupakan fitur penting dari mekanisme kata sandi karena CPU yang lebih cepat dan penggunaan GPU dan FPGA untuk memecahkan kata sandi dengan kecepatan milyaran tebakan per detik (dengan GPUs ).

Misalnya, Anda dapat memecahkan semua kata sandi Windows 8-karakter dalam 6 jam menggunakan 25 GPU yang dipasang di 5 PC desktop. Ini brute-forcing yaitu enumerasi dan pengecekan setiap kata sandi Windows 8-karakter , termasuk karakter khusus, dan bukan serangan kamus. Itu pada 2012, pada 2018 Anda bisa menggunakan GPU lebih sedikit, atau lebih cepat dengan 25 GPU.

Ada juga banyak serangan tabel pelangi pada kata sandi Windows yang berjalan pada CPU biasa dan sangat cepat. Semua ini karena Windows masih tidak memberi garam atau meregangkan kata sandinya, bahkan di Windows 10 - jangan membuat kesalahan yang sama seperti Microsoft!

Lihat juga:

• jawaban yang sangat baik dengan lebih banyak tentang mengapa password_hash()atau phpasscara terbaik untuk pergi.
• artikel blog yang bagus memberikan 'faktor kerja' yang direkomendasikan (jumlah iterasi) untuk algoritma utama termasuk bcrypt, scrypt dan PBKDF2.

Saya tidak akan menyimpan kata sandi hash dalam dua cara yang berbeda, karena dengan demikian sistem setidaknya selemah yang terlemah dari algoritma hash yang digunakan.

Pada PHP 5.5, PHP memiliki fungsi sederhana dan aman untuk hashing dan memverifikasi kata sandi, password_hash () dan password_verify ()

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

Ketika password_hash()digunakan, itu menghasilkan garam acak dan memasukkannya ke dalam hash yang dikeluarkan (bersama dengan biaya dan algoritma yang digunakan.) password_verify()Kemudian membaca hash itu dan menentukan garam dan metode enkripsi yang digunakan, dan memverifikasinya terhadap kata sandi plaintext yang disediakan.

Memberikan PASSWORD_DEFAULTinstruksi PHP untuk menggunakan algoritma hashing default dari versi PHP yang diinstal. Algoritma mana yang dimaksudkan dimaksudkan untuk berubah seiring waktu di versi mendatang, sehingga akan selalu menjadi salah satu algoritma terkuat yang ada.

Meningkatnya biaya (yang defaultnya 10) membuat hash lebih sulit untuk di-brute-force tetapi juga berarti menghasilkan hash dan memverifikasi kata sandi yang menentangnya akan lebih berfungsi untuk CPU server Anda.

Perhatikan bahwa meskipun algoritma hashing default dapat berubah, hash lama akan terus memverifikasi dengan baik karena algoritma yang digunakan disimpan dalam hash dan password_verify()mengambilnya.

Meskipun pertanyaan telah dijawab, saya hanya ingin menegaskan kembali bahwa garam yang digunakan untuk hashing harus acak dan tidak seperti alamat email seperti yang disarankan dalam jawaban pertama.

Penjelasan lebih lanjut tersedia di- http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Baru-baru ini saya berdiskusi apakah hash password yang diasinkan dengan bit acak lebih aman daripada yang diasinkan dengan garam yang dapat ditebak atau diketahui. Mari kita lihat: Jika sistem penyimpanan kata sandi terganggu serta sistem yang menyimpan garam acak, penyerang akan memiliki akses ke hash dan juga garam, jadi apakah garam itu acak atau tidak, tidak masalah. Penyerang akan dapat menghasilkan tabel pelangi yang sudah dihitung sebelumnya untuk memecahkan hash. Inilah bagian yang menarik - tidak sepele untuk menghasilkan tabel pra-komputasi. Mari kita ambil contoh model keamanan WPA. Kata sandi WPA Anda sebenarnya tidak pernah dikirim ke Wireless Access Point. Alih-alih, itu di-hash dengan SSID Anda (nama jaringan- seperti Linksys, Dlink, dll). Penjelasan yang sangat bagus tentang bagaimana ini bekerja ada di sini. Untuk mengambil kata sandi dari hash, Anda harus mengetahui kata sandi serta garam (nama jaringan). Church of Wifi telah memiliki tabel hash yang sudah dihitung sebelumnya yang memiliki 1000 SSID teratas dan sekitar 1 juta kata sandi. Ukuran semua tabel adalah sekitar 40 GB. Seperti yang dapat Anda baca di situsnya, seseorang menggunakan 15 array FGPA selama 3 hari untuk menghasilkan tabel ini. Dengan asumsi korban menggunakan SSID sebagai “a387csf3 ″ dan kata sandi sebagai“ 123456 ″, apakah akan diretas oleh tabel tersebut? Tidak! .. itu tidak bisa. Bahkan jika kata sandi lemah, tabel tidak memiliki hash untuk SSID a387csf3. Inilah keindahan memiliki garam acak. Ini akan mencegah cracker yang berkembang di atas meja yang sudah dihitung sebelumnya. Bisakah itu menghentikan hacker yang gigih? Mungkin tidak. Tetapi menggunakan garam acak memang memberikan lapisan pertahanan tambahan. Sementara kita berada di topik ini, mari kita bahas keuntungan tambahan menyimpan garam acak pada sistem yang terpisah. Skenario # 1: Kata sandi disimpan di sistem X dan nilai garam yang digunakan untuk hashing disimpan di sistem Y. Nilai garam ini dapat ditebak atau diketahui (misalnya nama pengguna) Skenario # 2: Kata sandi disimpan di sistem X dan nilai garam yang digunakan untuk hashing hashing disimpan pada sistem Y. Nilai garam ini acak. Jika sistem X telah dikompromikan, seperti yang dapat Anda tebak, ada keuntungan besar menggunakan garam acak pada sistem yang terpisah (Skenario # 2). Penyerang perlu menebak nilai tambahan untuk dapat memecahkan hash. Jika garam 32 bit digunakan, 2 ^ 32 = 4.294.967.296 (sekitar 4,2 miliar) iterasi akan diperlukan untuk setiap kata sandi yang ditebak. Kata sandi disimpan di sistem X dan nilai garam yang digunakan untuk hashing disimpan di sistem Y. Nilai garam ini dapat ditebak atau diketahui (misalnya nama pengguna) Skenario # 2: Kata sandi disimpan di sistem X dan nilai garam yang digunakan untuk hashing disimpan di sistem Y. Nilai garam ini acak. Jika sistem X telah dikompromikan, seperti yang dapat Anda tebak, ada keuntungan besar menggunakan garam acak pada sistem yang terpisah (Skenario # 2). Penyerang perlu menebak nilai tambahan untuk dapat memecahkan hash. Jika garam 32 bit digunakan, 2 ^ 32 = 4.294.967.296 (sekitar 4,2 miliar) iterasi akan diperlukan untuk setiap kata sandi yang ditebak. Kata sandi disimpan di sistem X dan nilai garam yang digunakan untuk hashing disimpan di sistem Y. Nilai garam ini dapat ditebak atau diketahui (misalnya nama pengguna) Skenario # 2: Kata sandi disimpan di sistem X dan nilai garam yang digunakan untuk hashing disimpan di sistem Y. Nilai garam ini acak. Jika sistem X telah dikompromikan, seperti yang dapat Anda tebak, ada keuntungan besar menggunakan garam acak pada sistem yang terpisah (Skenario # 2). Penyerang perlu menebak nilai tambahan untuk dapat memecahkan hash. Jika garam 32 bit digunakan, 2 ^ 32 = 4.294.967.296 (sekitar 4,2 miliar) iterasi akan diperlukan untuk setiap kata sandi yang ditebak. Nilai garam ini acak. Jika sistem X telah dikompromikan, seperti yang dapat Anda tebak, ada keuntungan besar menggunakan garam acak pada sistem yang terpisah (Skenario # 2). Penyerang perlu menebak nilai tambahan untuk dapat memecahkan hash. Jika garam 32 bit digunakan, 2 ^ 32 = 4.294.967.296 (sekitar 4,2 miliar) iterasi akan diperlukan untuk setiap kata sandi yang ditebak. Nilai garam ini acak. Jika sistem X telah dikompromikan, seperti yang dapat Anda tebak, ada keuntungan besar menggunakan garam acak pada sistem yang terpisah (Skenario # 2). Penyerang perlu menebak nilai tambahan untuk dapat memecahkan hash. Jika garam 32 bit digunakan, 2 ^ 32 = 4.294.967.296 (sekitar 4,2 miliar) iterasi akan diperlukan untuk setiap kata sandi yang ditebak.

Saya hanya ingin menunjukkan bahwa PHP 5.5 menyertakan API hashing kata sandi yang menyediakan pembungkus crypt(). API ini secara signifikan menyederhanakan tugas hashing, memverifikasi, dan mengulangi hash kata sandi. Penulis juga telah merilis paket kompatibilitas (dalam bentuk file password.php tunggal yang hanya Anda requiregunakan), bagi mereka yang menggunakan PHP 5.3.7 dan yang lebih baru dan ingin menggunakan ini sekarang.

Ini hanya mendukung BCRYPT untuk saat ini, tetapi bertujuan untuk dengan mudah diperluas untuk memasukkan teknik hashing kata sandi lainnya dan karena teknik dan biaya disimpan sebagai bagian dari hash, perubahan pada teknik hashing yang Anda inginkan / biaya tidak akan membatalkan hash saat ini, kerangka kerja secara otomatis, gunakan teknik / biaya yang benar saat memvalidasi. Itu juga menangani menghasilkan garam "aman" jika Anda tidak secara eksplisit menentukan sendiri.

API memaparkan empat fungsi:

• password_get_info() - mengembalikan informasi tentang hash yang diberikan
• password_hash() - membuat hash kata sandi
• password_needs_rehash()- memeriksa apakah hash yang diberikan cocok dengan opsi yang diberikan. Berguna untuk memeriksa apakah hash sesuai dengan skema teknik / biaya Anda saat ini yang memungkinkan Anda untuk mengulangi jika perlu
• password_verify() - memverifikasi bahwa kata sandi cocok dengan hash

Saat ini fungsi-fungsi ini menerima konstanta kata sandi PASSWORD_BCRYPT dan PASSWORD_DEFAULT, yang saat ini sama artinya, perbedaannya adalah bahwa PASSWORD_DEFAULT "dapat berubah dalam rilis PHP yang lebih baru ketika algoritma hashing yang lebih baru dan lebih kuat didukung." Menggunakan PASSWORD_DEFAULT dan password_needs_rehash () saat login (dan mengulangi jika perlu) harus memastikan bahwa hash Anda cukup tangguh terhadap serangan brute force dengan sedikit atau tanpa kerja untuk Anda.

EDIT: Saya baru menyadari bahwa ini disebutkan secara singkat dalam jawaban Robert K. Saya akan meninggalkan jawaban ini di sini karena saya pikir ini memberikan sedikit informasi lebih lanjut tentang cara kerjanya dan kemudahan penggunaannya bagi mereka yang tidak tahu keamanan.

Saya menggunakan Phpass yang merupakan kelas PHP satu file sederhana yang dapat diimplementasikan dengan sangat mudah di hampir setiap proyek PHP. Lihat juga H The .

Secara default menggunakan enkripsi terkuat yang ada yang diterapkan di Phpass, yang bcryptdan kembali ke enkripsi lain ke MD5 untuk memberikan kompatibilitas ke belakang untuk kerangka kerja seperti Wordpress.

Hash yang dikembalikan dapat disimpan dalam database apa adanya. Penggunaan sampel untuk menghasilkan hash adalah:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

Untuk memverifikasi kata sandi, seseorang dapat menggunakan:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

HAL-HAL UNTUK DIINGAT

Banyak yang telah dikatakan tentang enkripsi kata sandi untuk PHP, yang sebagian besar merupakan saran yang sangat baik, tetapi sebelum Anda bahkan memulai proses menggunakan PHP untuk enkripsi kata sandi, pastikan Anda telah menerapkan atau siap menerapkan yang berikut.

SERVER

PELABUHAN

Tidak peduli seberapa bagus enkripsi Anda jika Anda tidak benar mengamankan server yang menjalankan PHP dan DB, semua upaya Anda tidak ada artinya. Sebagian besar server berfungsi dengan cara yang relatif sama, mereka memiliki port yang ditugaskan untuk memungkinkan Anda mengaksesnya dari jarak jauh baik melalui ftp atau shell. Pastikan Anda mengubah port default yang koneksi aktifnya pernah Anda miliki. Dengan tidak melakukan ini, Anda sebenarnya telah membuat penyerang melakukan satu langkah lebih sedikit dalam mengakses sistem Anda.

NAMA PENGGUNA

Untuk semua yang baik di dunia jangan gunakan admin nama pengguna, root atau yang serupa. Juga jika Anda menggunakan sistem berbasis unix JANGAN membuat login akun root dapat diakses, itu harus selalu berupa sudo saja.

KATA SANDI

Anda memberi tahu pengguna Anda untuk membuat kata sandi yang baik agar tidak diretas, lakukan hal yang sama. Apa gunanya melalui semua upaya mengunci pintu depan Anda ketika Anda memiliki pintu belakang terbuka lebar.

DATABASE

SERVER

Idealnya Anda ingin DB dan APLIKASI Anda di server terpisah. Ini tidak selalu mungkin karena biaya, tetapi memungkinkan untuk keselamatan karena penyerang harus melalui dua langkah untuk sepenuhnya mengakses sistem.

PENGGUNA

Selalu minta aplikasi Anda memiliki akun sendiri untuk mengakses DB, dan berikan saja hak istimewa yang diperlukan.

Kemudian miliki akun pengguna terpisah untuk Anda yang tidak disimpan di mana pun di server, bahkan dalam aplikasi.

Seperti selalu, JANGAN membuat root ini atau yang serupa.

KATA SANDI

Ikuti panduan yang sama dengan semua kata sandi yang baik. Juga jangan menggunakan kembali kata sandi yang sama pada sembarang SERVER atau akun DB pada sistem yang sama.

PHP

KATA SANDI

JANGAN PERNAH menyimpan kata sandi di DB Anda, alih-alih menyimpan hash dan garam unik, saya akan menjelaskan alasannya nanti.

HASHING

ONE WAY HASHING !!! dengan cara yang sama dan bandingkan dua hash. Ini berarti bahwa bahkan jika seorang penyerang mendapatkan akses ke DB dia tidak tahu apa kata sandi yang sebenarnya, hanya hash yang dihasilkan. Yang berarti lebih banyak keamanan untuk pengguna Anda dalam skenario terburuk yang mungkin terjadi.

Ada banyak fungsi hashing yang bagus di luar sana ( password_hash,, hashdll ...) tetapi Anda harus memilih algoritma yang baik agar hash menjadi efektif. (bcrypt dan yang mirip dengan itu adalah algoritma yang layak.)

Ketika hashing speed adalah kuncinya, semakin lambat semakin tahan terhadap serangan Brute Force.

Salah satu kesalahan paling umum dalam hashing adalah hash tidak unik bagi pengguna. Ini terutama karena garam tidak dihasilkan secara unik.

SALTING

Kata sandi harus selalu diasinkan sebelum hash. Pengasinan menambahkan string acak ke kata sandi sehingga kata sandi yang serupa tidak tampak sama di DB. Namun, jika garam tersebut tidak unik untuk setiap pengguna (yaitu: Anda menggunakan garam berkode keras), maka Anda telah membuat garam Anda tidak berharga. Karena begitu seorang penyerang menemukan satu kata sandi, ia memiliki garam untuk semuanya.

Saat Anda membuat garam, pastikan garam itu unik untuk kata sandi penggaraman, kemudian simpan hash dan garam yang sudah lengkap di DB. Apa yang akan dilakukan adalah membuatnya sehingga penyerang harus secara individual memecahkan setiap garam dan hash sebelum mereka dapat memperoleh akses. Ini berarti lebih banyak pekerjaan dan waktu bagi penyerang.

PENGGUNA MENCIPTAKAN PASSWORDS

Jika pengguna membuat kata sandi melalui frontend, itu artinya harus dikirim ke server. Ini membuka masalah keamanan karena itu berarti kata sandi yang tidak terenkripsi sedang dikirim ke server dan jika seorang penyerang dapat mendengarkan dan mengakses bahwa semua keamanan Anda di PHP tidak berharga. SELALU mentransmisikan data SECURELY, ini dilakukan melalui SSL, tetapi menjadi lelah bahkan SSL tidak sempurna (OpenSSL's Heartbleed cacat adalah contoh dari ini).

Juga membuat pengguna membuat kata sandi aman, itu sederhana dan harus selalu dilakukan, pengguna akan berterima kasih karenanya.

Akhirnya, tidak peduli langkah-langkah keamanan yang Anda ambil tidak ada yang 100% aman, semakin canggih teknologi untuk melindungi menjadi semakin canggih serangan itu. Tetapi mengikuti langkah-langkah ini akan membuat situs Anda lebih aman dan jauh lebih tidak diinginkan bagi penyerang untuk mengejar.

Ini adalah kelas PHP yang membuat hash dan garam untuk kata sandi dengan mudah

http://git.io/mSJqpw

Google mengatakan SHA256 tersedia untuk PHP.

Anda pasti harus menggunakan garam. Saya akan merekomendasikan menggunakan byte acak (dan tidak membatasi diri Anda dengan karakter dan angka). Seperti biasanya, semakin lama Anda memilih, semakin aman, semakin lambat. 64 byte seharusnya baik-baik saja, kurasa.

Pada akhirnya, hashing ganda, secara matematis, tidak memberikan manfaat. Namun dalam praktiknya, ini berguna untuk mencegah serangan berbasis tabel pelangi. Dengan kata lain, itu tidak lebih bermanfaat daripada hashing dengan garam, yang memakan waktu prosesor jauh lebih sedikit di aplikasi Anda atau di server Anda.

Saya menemukan topik yang sempurna tentang masalah ini di sini: https://crackstation.net/hashing-security.htm , saya ingin Anda mendapatkan manfaat darinya, di sini adalah kode sumber juga yang memberikan pencegahan terhadap serangan berbasis waktu juga.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

Saya biasanya menggunakan SHA1 dan garam dengan ID pengguna (atau informasi khusus pengguna lainnya), dan kadang-kadang saya juga menggunakan garam konstan (jadi saya punya 2 bagian garam).

SHA1 sekarang juga dianggap agak dikompromikan, tetapi pada tingkat yang jauh lebih rendah daripada MD5. Dengan menggunakan garam (garam apa saja), Anda mencegah penggunaan tabel pelangi umum untuk menyerang hash Anda (beberapa orang bahkan telah berhasil menggunakan Google sebagai semacam tabel pelangi dengan mencari hash). Seorang penyerang bisa membuat tabel pelangi menggunakan garam Anda, jadi itu sebabnya Anda harus memasukkan garam khusus pengguna. Dengan begitu, mereka harus membuat tabel pelangi untuk masing-masing dan setiap catatan di sistem Anda, bukan hanya satu untuk seluruh sistem Anda! Dengan jenis pengasinan seperti itu, MD5 pun aman.

SHA1 dan garam harus mencukupi (tergantung, tentu saja, pada apakah Anda mengkodekan sesuatu untuk Fort Knox atau sistem login untuk daftar belanja Anda) untuk masa yang akan datang. Jika SHA1 tidak cukup baik untuk Anda, gunakan SHA256 .

Gagasan garam adalah untuk membuang hasil hashing tidak seimbang, bisa dikatakan. Diketahui, misalnya, bahwa hash MD5 dari string kosong adalah d41d8cd98f00b204e9800998ecf8427e. Jadi, jika seseorang dengan memori yang cukup baik akan melihat hash itu dan tahu bahwa itu adalah hash dari string kosong. Tetapi jika string diasinkan (katakanlah, dengan string " MY_PERSONAL_SALT"), hash untuk 'string kosong' (yaitu " MY_PERSONAL_SALT") menjadi aeac2612626724592271634fb14d3ea6, maka tidak jelas untuk ditelusuri kembali. Apa yang saya coba katakan, bahwa lebih baik menggunakan garam apa pun , daripada tidak. Oleh karena itu, tidak terlalu penting untuk mengetahui garam mana yang digunakan.

Sebenarnya ada situs web yang melakukan hal ini - Anda dapat memberinya hash (md5), dan memuntahkan teks yang dikenal yang menghasilkan hash tertentu. Jika Anda mendapatkan akses ke database yang menyimpan hash md5-hash, akan sepele bagi Anda untuk memasukkan hash untuk admin ke layanan seperti itu, dan masuk. Tetapi, jika kata sandi digaramkan, layanan seperti itu akan menjadi tidak efektif.

Juga, hashing ganda umumnya dianggap sebagai metode yang buruk, karena mengurangi ruang hasil. Semua hash populer adalah fixed-length. Dengan demikian, Anda hanya dapat memiliki nilai hingga dari panjang tetap ini, dan hasilnya menjadi kurang bervariasi. Ini bisa dianggap sebagai bentuk pengasinan lainnya, tetapi saya tidak akan merekomendasikannya.

ok pada saat kita membutuhkan garam garam harus unik jadi mari kita hasilkan

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

juga kita perlu hash I`m menggunakan sha512 itu adalah yang terbaik dan di php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

jadi sekarang kita bisa menggunakan fungsi ini untuk menghasilkan kata sandi yang aman

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

sekarang kita perlu menyimpan dalam database nilai variabel $ hash_psw dan variabel $ salt

dan untuk otorisasi kami akan menggunakan langkah yang sama ...

itu adalah cara terbaik untuk mengamankan kata sandi klien kami ...

Ps untuk 2 langkah terakhir Anda dapat menggunakan algoritme Anda sendiri ... tetapi pastikan bahwa Anda dapat membuat kata sandi hash ini di masa mendatang ketika Anda perlu mengotorisasi pengguna ...