Pertanyaan Amankan hash dan garam untuk kata sandi PHP


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

Pertanyaan ini, Apakah "hashing ganda" password kurang aman daripada hanya hashing sekali?  menunjukkan bahwa hashing beberapa kali mungkin merupakan ide yang bagus, 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 password satu juta kali mungkin lebih aman, tetapi juga lebih lambat. Bagaimana cara mencapai keseimbangan yang baik antara kecepatan dan keamanan? Juga, saya lebih memilih hasilnya untuk memiliki sejumlah karakter konstan.

  1. Mekanisme hashing harus tersedia dalam PHP
  2. Itu harus aman
  3. Dapat 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 database (satu menggunakan MD5 dan yang lain menggunakan SHA, misalnya)? Apakah itu membuatnya lebih aman atau tidak aman?

Jika saya tidak cukup jelas, saya ingin tahu fungsi hashing mana yang digunakan dan bagaimana 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 di PHP
Enkripsi Kata Sandi Sederhana
Metode aman menyimpan kunci, kata sandi untuk asp.net
Bagaimana Anda akan mengimplementasikan kata sandi asin di Tomcat 5.5


1049
2017-12-30 22:02


asal


Jawaban:


PENOLAKAN: Jawaban ini ditulis pada tahun 2008.

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

Teori jawabannya masih bagus untuk dibaca.

TL; DR

Tidak boleh

  • Jangan batasi karakter apa yang dapat dimasukkan pengguna untuk kata sandi. Hanya orang bodoh yang melakukan ini.
  • Jangan batasi panjang kata sandi. Jika pengguna Anda menginginkan sebuah kalimat dengan supercalifragilisticexpialidocious di dalamnya, jangan mencegah mereka menggunakannya.
  • Jangan pernah menyimpan kata sandi pengguna Anda dalam teks biasa.
  • Jangan pernah mengirimkan kata sandi ke pengguna Anda kecuali ketika mereka kehilangan milik mereka, dan Anda mengirim yang sementara.
  • Jangan pernah menyimpan kata sandi dengan cara apa pun.
  • Tidak pernah hash kata sandi dengan SHA1 atau MD5 atau bahkan SHA256! Cracker modern dapat melebihi 60 dan 180 miliar hashes / detik (masing-masing).
  • Jangan campur bcrypt dan dengan mentah keluaran hash (), baik menggunakan output hex atau base64_encode itu. (Ini berlaku untuk setiap masukan yang mungkin memiliki rogue \0 di dalamnya, yang dapat secara serius melemahkan keamanan.)

Dos

  • Gunakan scrypt ketika Anda bisa; bcrypt jika Anda tidak bisa.
  • Gunakan PBKDF2 jika Anda tidak dapat menggunakan bcrypt atau scrypt, dengan SHA2 hashes.
  • Setel ulang sandi semua orang saat database disusupi.
  • 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 akan membuat lebih sulit untuk dipecahkan. (Lihat bagian "Apa yang membuat kata sandi yang baik?" Untuk beberapa perdebatan.)

Mengapa hash password?

Tujuan di balik hashing password sederhana: mencegah akses berbahaya ke akun pengguna dengan mengorbankan database. Jadi tujuan hashing password adalah untuk mencegah hacker atau cracker dengan menghabiskan terlalu banyak waktu atau uang untuk menghitung kata sandi plain-text. Dan waktu / biaya adalah penghalang terbaik dalam gudang senjata Anda.

Alasan lain mengapa Anda menginginkan hash yang baik dan kuat pada akun pengguna adalah memberi Anda cukup waktu untuk mengubah semua kata sandi dalam sistem. Jika basis data Anda dikompromikan, Anda akan membutuhkan cukup waktu untuk melakukannya paling sedikit mengunci sistem, jika tidak mengubah setiap kata sandi dalam database.

Jeremiah Grossman, CTO dari Keamanan Whitehat, tertera di blognya setelah pemulihan kata sandi baru-baru ini yang membutuhkan pemutusan kata-kata kasar dari perlindungan kata sandinya:

Yang menarik, dalam menjalani mimpi buruk ini, saya belajar BANYAK Saya tidak tahu tentang cracking kata sandi, penyimpanan, dan kerumitan. Saya mulai menghargai mengapa penyimpanan kata sandi jauh lebih penting daripada kerumitan sandi. Jika Anda tidak tahu bagaimana kata sandi Anda disimpan, maka semua yang dapat Anda andalkan adalah kompleksitas. Ini mungkin pengetahuan umum untuk kata sandi dan pro crypto, tetapi untuk para ahli InfoSec atau Web Security rata-rata, saya sangat meragukannya.

(Penekanan milikku.)

Apa yang membuat baik kata sandi?

Entropi. (Bukan berarti saya sepenuhnya berlangganan ke sudut pandang Randall.)

Singkatnya, entropi adalah seberapa banyak variasi dalam kata sandi. Ketika kata sandi hanya huruf kecil huruf latin, itu hanya 26 karakter. Itu tidak banyak variasi. Kata sandi alpha-numeric lebih baik, dengan 36 karakter. Tetapi memungkinkan huruf besar dan kecil, dengan simbol, kira-kira 96 ​​karakter. Itu jauh lebih baik daripada sekadar huruf. Salah satu masalahnya adalah, untuk membuat kata sandi kita mudah diingat kita memasukkan pola-pola yang mengurangi entropi. Ups!

Entropi kata sandi adalah didekati 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 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 lagi tentang entropi kata sandi di Crypto StackExchange situs. Pencarian Google yang baik juga akan memunculkan banyak hasil.

Dalam komentar saya berbicara dengan @popnoodles, yang menunjukkan hal itu menegakkan kebijakan kata sandi panjang X dengan banyak huruf X, angka, simbol, dll, dapat benar-benar mengurangi entropi dengan membuat skema kata sandi lebih mudah diprediksi. Saya setuju. Randomess, sebisa mungkin acak, selalu merupakan solusi yang paling aman tetapi paling tidak berkesan.

Sejauh yang saya tahu, membuat kata sandi terbaik dunia adalah Catch-22. Entah itu tidak mudah diingat, terlalu mudah diprediksi, terlalu pendek, terlalu banyak karakter unicode (sulit untuk mengetik pada perangkat Windows / Mobile), terlalu lama, dll. Tidak ada kata sandi yang benar-benar cukup baik untuk tujuan kita, jadi kita harus melindungi mereka 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 tinjauan mendalam tentang algoritmanya yang diposting. Tapi tetap, masa depan algoritma memang terlihat menjanjikan. Jika Anda bekerja dengan Ruby, ada sebuah permata skrip yang akan membantu Anda, dan Node.js sekarang memiliki milik sendiri scrypt paket. Anda dapat menggunakan Scrypt di PHP melalui Scrypt ekstensi atau Libsodium ekstensi (keduanya tersedia di PECL).

Saya sangat menyarankan membaca dokumentasi untuk fungsi crypt jika Anda ingin memahami cara menggunakan bcrypt, atau menemukan diri Anda baik  pembungkus atau gunakan sesuatu seperti PHPASS untuk implementasi 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 ini memungkinkan Anda meningkatkan biaya untuk brute-force password dengan meningkatkan jadwal kunci yang sudah mahal dari blowfish.

Praktik 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 menggunakannya 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 bahwa lingkungan / aplikasi / persepsi pengguna Anda dapat mentoleransi. Jumlah terendah yang saya sarankan adalah 2500 putaran. Juga, pastikan untuk menggunakannya hash_hmac () jika tersedia untuk membuat operasi lebih sulit untuk mereproduksi.

Praktek Masa Depan

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

Rekap Kriptografi & Penafian

Daya komputasi yang dibutuhkan untuk benar-benar retak kata sandi yang di-hash tidak ada. Satu-satunya cara bagi komputer untuk "meretas" kata sandi adalah dengan membuat ulang dan mensimulasikan algoritma hashing yang digunakan untuk mengamankannya. Kecepatan hash secara linier terkait dengan kemampuannya untuk dipaksa 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 dapat memperkirakan semua ancaman atau serangan, dan Anda harus berusaha sebaik-baiknya untuk melindungi pengguna Anda di muka. Jika Anda tidak melakukannya, maka Anda mungkin bahkan melewatkan fakta bahwa Anda diserang sampai terlambat ... dan kamu bertanggung jawab. Untuk menghindari situasi itu, mulailah bertindak paranoid. Serang perangkat lunak Anda sendiri (internal) dan coba mencuri kredensial pengguna, atau ubah akun pengguna lain atau akses datanya. Jika Anda tidak menguji keamanan sistem Anda, maka Anda tidak dapat menyalahkan siapa pun kecuali diri Anda sendiri.

Terakhir: Saya bukan seorang cryptographer. Apa pun yang saya katakan adalah pendapat saya, tetapi saya pikir itu didasarkan pada akal sehat ... dan banyak membaca. Ingatlah, sedapat mungkin paranoid, buat segala sesuatunya sulit untuk diganggu, dan kemudian, jika Anda masih khawatir, hubungi peretas topi putih atau cryptographer untuk melihat apa yang mereka katakan tentang kode / sistem Anda.


892
2017-12-30 22:15



Jawaban yang jauh lebih pendek dan lebih aman - jangan menulis mekanisme kata sandi Anda sama sekali, gunakan mekanisme yang sudah dicoba dan teruji.

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

Kebanyakan programmer tidak memiliki keahlian untuk menulis kode yang berkaitan dengan crypto dengan aman tanpa memperkenalkan kerentanan.

Tes-diri cepat: apa kata sandi peregangan dan berapa banyak iterasi yang harus Anda gunakan? Jika Anda tidak tahu jawabannya, Anda harus menggunakannya password_hash(), karena peregangan sandi sekarang menjadi fitur penting dari mekanisme kata sandi karena CPU lebih cepat dan penggunaan GPU dan FPGA untuk meretas kata sandi dengan tarif miliaran tebakan per detik (dengan GPU).

Misalnya, Anda bisa crack semua password Windows 8-karakter dalam 6 jam menggunakan 25 GPU yang dipasang di 5 PC desktop. Ini adalah brute-forcing yaitu enumerasi dan pengecekan setiap password Windows 8-karakter, termasuk karakter khusus, dan bukan serangan kamus. Itu pada tahun 2012, pada 2018 Anda dapat menggunakan lebih sedikit GPU, atau memecahkan 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 garam atau peregangan kata sandinya, bahkan di Windows 10 - jangan membuat kesalahan yang sama seperti yang dilakukan Microsoft!

Lihat juga: 

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

120
2017-11-08 12:02



Saya tidak akan menyimpan kata sandi dalam dua cara berbeda, karena kemudian sistem setidaknya sama lemahnya dengan algoritma hash terlemah yang digunakan.


40
2017-12-30 22:18



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 sandi digarami secara acak   bit lebih aman daripada yang asin dengan dapat ditebak atau diketahui   garam. Mari kita lihat: Jika sistem menyimpan sandi dikompromikan sebagai   serta sistem yang menyimpan garam acak, penyerang akan   memiliki akses ke hash serta garam, jadi apakah garam itu acak atau   tidak, tidak masalah. Penyerang akan dapat menghasilkan pra-dihitung   tabel pelangi untuk memecahkan hash. Inilah bagian yang menarik   tidak begitu sepele untuk menghasilkan tabel pra-dihitung. Mari kita ambil contoh   model keamanan WPA. Kata sandi WPA Anda sebenarnya tidak pernah dikirim   Titik Akses Nirkabel. Sebaliknya, itu hash dengan SSID Anda (the   nama jaringan - seperti Linksys, Dlink, dll.). Penjelasan yang sangat bagus tentang bagaimana caranya   ini berfungsi di sini. Untuk mengambil kata sandi dari hash, Anda akan   perlu mengetahui kata sandi serta garam (nama jaringan). Gereja   Wifi telah memiliki tabel hash pra-komputasi yang memiliki 1.000 SSID teratas dan   sekitar 1 juta kata sandi. Ukurannya adalah semua tabel sekitar 40 GB.   Seperti yang Anda baca di situs mereka, seseorang menggunakan 15 FGPA array selama 3 hari   untuk menghasilkan tabel ini. Dengan asumsi korban menggunakan SSID sebagai   "A387csf3 ″ dan kata sandi sebagai" 123456 ″, apakah akan dipecahkan oleh mereka   tabel? Tidak! .. itu tidak bisa. Bahkan jika kata sandi lemah, tabel   tidak memiliki hash untuk SSID a387csf3. Inilah keindahan memiliki   garam acak. Ini akan mencegah kerupuk yang berkembang pada pra-dihitung   tabel. Bisakah itu menghentikan peretas yang ditentukan? Mungkin tidak. Tetapi menggunakan   garam acak memang menyediakan lapisan tambahan pertahanan. Selagi kita aktif   topik ini, mari kita bahas keuntungan tambahan dari menyimpan acak   garam pada sistem yang terpisah. Skenario # 1: Pencirian kata sandi disimpan   pada sistem X dan nilai-nilai garam yang digunakan untuk hashing disimpan pada sistem Y.   Nilai-nilai garam ini dapat diduga atau dikenal (misalnya nama pengguna) Skenario # 2:   Hash sandi disimpan di sistem X dan nilai garam digunakan untuk   hashing disimpan pada sistem Y. Nilai-nilai garam ini acak. Dalam hal   sistem X telah dikompromikan, seperti yang bisa Anda tebak, ada yang besar   keuntungan menggunakan garam acak pada sistem yang terpisah (Skenario # 2).   Penyerang akan perlu menebak nilai tambah agar dapat retak   hash. Jika 32 bit garam digunakan, 2 ^ 32 = 4,294,967,296 (sekitar 4,2   miliar) iterasi akan diperlukan untuk setiap kata sandi yang ditebak.


30
2018-02-12 00:52



Pada PHP 5.5, PHP memiliki fungsi yang sederhana dan aman untuk hashing dan verifikasi kata sandi, password_hash () dan kata sandi_verifikasikan ()

$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

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

Menyediakan PASSWORD_DEFAULT memerintahkan PHP untuk menggunakan algoritma hashing default dari versi PHP yang terinstal. Tepatnya, algoritme yang dimaksudkan dimaksudkan untuk berubah seiring waktu di versi mendatang, sehingga selalu menjadi salah satu algoritme terkuat yang tersedia.

Meningkatnya biaya (yang defaultnya menjadi 10) membuat hash menjadi lebih keras terhadap kekuatan brute tetapi juga berarti membuat hash dan memverifikasi kata sandi terhadap mereka akan lebih banyak bekerja untuk CPU server Anda.

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


30
2017-09-21 21:33



Saya hanya ingin menunjukkan bahwa PHP 5.5 termasuk a hashing kata sandi API yang menyediakan pembungkus crypt(). API ini secara signifikan menyederhanakan tugas hashing, verifikasi dan pengulangan hash kata sandi. Penulis juga telah merilis sebuah paket kompatibilitas (dalam bentuk file password.php tunggal yang Anda sederhanakan require untuk digunakan), bagi mereka yang menggunakan PHP 5.3.7 dan yang lebih baru dan ingin menggunakan ini sekarang.

Hanya mendukung BCRYPT untuk saat ini, tetapi bertujuan untuk dengan mudah diperluas untuk menyertakan teknik hashing kata sandi lainnya dan karena teknik dan biaya disimpan sebagai bagian dari hash, perubahan teknik hashing / biaya yang Anda inginkan tidak akan membatalkan hash saat ini, kerangka akan secara otomatis, gunakan teknik / biaya yang benar ketika memvalidasi. Ini juga menangani menghasilkan garam "aman" jika Anda tidak secara eksplisit mendefinisikan garam Anda 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 sesuai dengan opsi yang diberikan. Berguna untuk memeriksa apakah hash sesuai dengan skema teknik / biaya Anda saat ini yang memungkinkan Anda untuk mengulang kembali jika perlu
  • password_verify() - memverifikasi bahwa kata sandi cocok dengan hash

Saat ini fungsi-fungsi ini menerima konstanta kata PASSWORD_BCRYPT dan PASSWORD_DEFAULT, yang sinonim pada saat ini, perbedaannya adalah bahwa PASSWORD_DEFAULT "dapat berubah dalam rilis PHP yang lebih baru ketika yang lebih baru, algoritma hashing yang lebih kuat didukung." Menggunakan PASSWORD_DEFAULT dan password_needs_rehash () saat login (dan mengulangi jika perlu) harus memastikan bahwa hash Anda cukup tahan terhadap serangan brute-force dengan sedikit atau tidak ada pekerjaan 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 lebih banyak informasi tentang cara kerjanya dan kemudahan penggunaannya menyediakan bagi mereka yang tidak tahu keamanan.


25
2018-04-27 21:41



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

Secara default, ia menggunakan enkripsi terkuat yang tersedia di Phpass, yaitu bcrypt dan kembali ke enkripsi lain ke MD5 untuk menyediakan kompatibilitas ke framework seperti Wordpress.

Hash yang dikembalikan dapat disimpan dalam basis data sebagaimana adanya. Contoh penggunaan 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);

17
2018-06-26 08:05



HAL-HAL UNTUK DIINGAT

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

SERVER

PORTS

Tidak peduli seberapa bagus enkripsi Anda jika Anda tidak benar-benar mengamankan server yang menjalankan PHP dan DB, semua usaha Anda tidak berharga. Sebagian besar server berfungsi relatif sama, mereka memiliki port yang ditugaskan untuk memungkinkan Anda mengaksesnya dari jarak jauh baik melalui ftp atau shell. Pastikan bahwa Anda mengubah port default dari sambungan remote yang 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 menggunakan username admin, root atau yang serupa. Juga jika Anda berada pada sistem berbasis unix JANGAN membuat login akun root dapat diakses, itu harus selalu sudo saja.

KATA SANDI

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

DATABASE

SERVER

Idealnya Anda ingin DB dan APLIKASI Anda pada server terpisah. Ini tidak selalu mungkin karena biaya, tetapi itu memungkinkan untuk beberapa keamanan sebagai penyerang harus melalui dua langkah untuk sepenuhnya mengakses sistem.

PENGGUNA

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

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

Seperti biasanya JANGAN membuat akar ini atau sesuatu yang serupa.

KATA SANDI

Ikuti panduan yang sama seperti dengan semua kata sandi yang bagus. Juga jangan menggunakan kembali kata sandi yang sama pada akun SERVER atau 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 mengapa nanti.

HASHING

ONE WAY HASHING !!!!!!!, Jangan pernah memasukkan kata sandi dengan cara yang dapat dibalik, Hash harus satu arah, artinya Anda tidak membalikkannya dan membandingkannya dengan kata sandi, Anda malah memasukkan kata sandi yang dimasukkan dengan cara yang sama dan membandingkan dua hash. Ini berarti bahwa bahkan jika penyerang mendapat akses ke DB dia tidak tahu apa sebenarnya kata sandi itu, hanya hash yang dihasilkannya. Yang berarti keamanan lebih bagi pengguna Anda dalam skenario terburuk yang mungkin terjadi.

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

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

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

SALTING

Kata sandi harus selalu digaruk sebelum dipotong. Salting menambahkan string acak ke kata sandi sehingga kata sandi yang serupa tidak muncul sama di DB. Namun jika garam itu tidak unik untuk setiap pengguna (yaitu: Anda menggunakan garam berkode keras) dari Anda cukup banyak telah membuat garam Anda tidak berharga. Karena sekali seorang penyerang menghitung satu kata sandi, dia memiliki garam untuk mereka semua.

Saat Anda membuat garam, pastikan itu unik untuk kata sandi yang diasinkan, lalu simpan baik hash dan garam yang sudah selesai di DB Anda. 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 berarti itu harus dikirim ke server. Ini membuka masalah keamanan karena itu berarti kata sandi yang tidak terenkripsi sedang dikirim ke server dan jika penyerang dapat mendengarkan dan mengakses bahwa semua keamanan Anda dalam PHP tidak berharga. SELALU mengirimkan data SECURELY, ini dilakukan melalui SSL, tetapi menjadi lelah bahkan SSL tidak sempurna (kelemahan Heartbleed OpenSSL adalah contoh dari ini).

Juga membuat pengguna membuat kata sandi yang aman, itu sederhana dan harus selalu dilakukan, pengguna akan berterima kasih untuk itu pada akhirnya.

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

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

http://git.io/mSJqpw


13
2018-04-09 15:01



Google mengatakan SHA256 tersedia untuk PHP.

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


12
2017-12-30 22:20