it-swarm-id.com

Keamanan kata sandi dalam database - hari ini masih praktik terbaik?

Kemungkinan Duplikat:
Metode hashing kata sandi mana yang harus saya gunakan?

Ada satu ton posting hebat tentang keamanan kata sandi di database pada stack overflow dan di situs lain dan karena saya benar-benar baru dalam hal ini, saya menghabiskan beberapa jam mencoba untuk mempelajari lebih lanjut tentang hal itu di hari-hari terakhir. Namun, ada begitu banyak saran dan praktik terbaik sehingga saya masih sangat bingung ...

Juga, masih ada banyak posting lama dari 2007-2010 dll saya melihat seberapa cepat hal-hal berubah saya tidak yakin apakah ini masih umum untuk menggunakannya seperti yang mereka sarankan. Jadi, saya ingin merangkum apa yang saya temukan di posting dan kemudian bertanya apakah metode ini yang saya temukan adalah praktik yang baik ...

Jadi, ini bukan panduan, tapi ringkasan, saya tahu ini sangat mendasar dan jika ada kesalahan tolong perbaiki saya!

  1. Hanya untuk menyebutkan: Anda tidak boleh menyimpan kata sandi teks biasa :)
  2. Anda kata sandi hash "satu arah", jadi tidak ada yang bisa melihat teks biasa. Ketika pengguna memasukkan kata sandi, Anda hash dengan cara yang sama dan membandingkannya dengan pass hash dalam database.
  3. Selain hash kata sandi, Anda harus menambahkannya. Anda menambahkan garam ke string kata sandi polos dan hash string baru. Jika kata sandi polos lemah, menambahkan garam membuatnya lebih lama dan lebih kuat.
  4. Garam selanjutnya harus acak (saya pernah membaca bahwa istilah "garam" berarti itu acak pula, kalau tidak disebut "kunci"?). Ini untuk mencegah serangan tabel Rainbow, karena penyerang perlu membuat satu tabel untuk setiap garam yang jauh lebih mahal dalam hal waktu dll. Juga jika dua pengguna memiliki kata sandi yang sama Anda tidak akan mengenalinya jika Anda menggunakan garam acak.
  5. Garam bukan rahasia! Itu disimpan dalam database di sebelah kata sandi hash. Namun, itu mungkin bukan ide terbaik untuk menggunakan stempel waktu, alamat email pengguna atau apa pun yang terhubung ke pengguna sebagai garam acak. Sebagai alasan, mis. menyebutkan bahwa pengguna cenderung menggunakan kata sandi yang sama di beberapa situs/layanan. Jadi, garam harus berupa string acak, saya sudah membaca yang terbaik akan menjadi 64-bit?
  6. Langkah selanjutnya adalah menambahkan iterasi ke proses hashing (1000 loop atau lebih), sehingga garam ditambahkan ke kata sandi dan mereka kemudian di hash berulang-ulang, yang berarti hanya sebagian kecil dari satu detik bagi pengguna untuk menunggu saat login masuk, tetapi jumlahkan jika Anda memiliki 10.000 entri di DB.
  7. Mungkin sedikit bermanfaat, jika Anda menambahkan kunci situs, misalnya disimpan. sebagai var global selain garam. Namun, Anda harus selalu menganggap bahwa penyerang juga memiliki akses ke sistem file Anda.
  8. Algoritma Hashing: Saya menemukan pasti tidak aman lagi untuk menggunakan MD5, SHA1 dan metode lemah lainnya ...

Jadi, ada pendapat berbeda tentang apakah menggunakan SHA256, SHA512? Haruskah Anda menggunakan hash_hmac? Ada yang bilang ya: ( http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hash-use-hmac/ ) ada yang bilang menggunakan perpustakaan adalah satu-satunya cara aman ... dan kemudian sekali atau dua kali dalam posting saya sudah baca untuk tidak menggunakan perpustakaan sebagai bcrypt atau ikan gelembung ??

Apakah benar-benar perlu menggunakan perpustakaan atau mis. metode seperti ini cukup:

function hash_password($password, $nonce) {

  for ($i = 0; $i < 5000; $i++) {
    $hashed_pass = hash_hmac('sha512', $hashed_pass . $nonce . $password, $site_key);
    }
  return $hashed_pass;
}

Banyak orang mengatakan tidak menciptakan algo Anda sendiri, jadi saya sedikit takut hanya menggunakan apa pun yang diciptakan sendiri.

Saya bisa membayangkan sulit untuk diprediksi, tetapi berapa lama metode yang digunakan saat ini dianggap cukup aman?

UPDATE: Jadi, terima kasih atas semua tanggapan Anda yang luar biasa. Ada satu poin utama yang hilang, seperti yang saya lihat dan banyak dari Anda berkata: keamanan kata sandi, yang berarti kata sandi yang kuat adalah dasarnya. Saya pikir saya mendapat pesannya, terima kasih lagi! :)

UPDATE 2: Hanya untuk penyelesaian, saya telah menemukan kode berikut pada http://www.lateralcode.com/creating-a-random-string-with-php/ yang saya gunakan untuk menghasilkan garam acak :

function Rand_string( $length ) {
    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!§$%&/().-:;_#+*[]{}="; 

    $size = strlen( $chars );
    for( $i = 0; $i < $length; $i++ ) {
        $str .= $chars[ Rand( 0, $size - 1 ) ];
    }

    return $str;
}

$random_salt= Rand_string(20);
47
Chris

Info umum:

Pertanyaan yang bagus tapi yang bisa saya katakan adalah itu sepenuhnya tergantung pada penggunaan. Jika Anda menggunakannya hanya untuk situs web kecil, ada kemungkinan besar hanya "skrip kiddies" yang akan mengunjungi Anda, dalam hal ini SHA1 sederhana dengan garam juga cukup memadai hari ini. Dalam hal ini, 5-8-10 tahun atau bahkan lebih benar-benar bagus, skrip kiddies tidak akan benar-benar membobolnya jika mereka melihat bahwa mereka tidak dapat menerobos dengan mudah. Jika situs Anda akan diserang karena alasan tertentu - situs moneter, dll. Maka Anda harus menggunakan fungsi terbaru yang tersedia. Dalam hal ini saya bahkan akan "mengambil risiko" untuk menggunakan fungsi yang tidak resmi tetapi sudah porting. Saat ini ada kompetisi SHA3, untuk websties yang akan memiliki uang tinggi di dalamnya, saya akan menggunakan salah satu dari 5 pesaing ini.

Poin yang saya katakan penting:

1. menggunakan garam acak, bahkan mungkin 20 karakter. Itu membuat jauh lebih sulit untuk memecahkan kata sandi, dan bahkan jika itu dapat dipecahkan, butuh terlalu banyak waktu untuk menjadi berharga.
2. gunakan SHA-1, SHA-2 atau WHIRLPOOL. Dengan garam yang baik, MD5 juga OK, tapi saya masih menyarankan ini.
. Anda dapat menggunakan kriptografi yang bagus jika kata sandi pengguna sepele. Anda harus memastikan mereka menggunakan non-kamus, kata sandi panjang dengan huruf besar, huruf kecil, angka dan simbol lain yang mudah dipecahkan oleh brute force. Anda mungkin mempertimbangkan bahwa mereka dapat dipaksa untuk mengubah kata sandi setiap tahun atau lebih.

Ke kode:

Looping berkali-kali bisa berguna tetapi saya tidak berpikir 5000 diperlukan. 3 untuk keamanan normal itu baik, atau 100, mungkin 1000 bisa bekerja, tapi saya pikir 5000 terlalu banyak. SHA-256 bagus, tetapi Anda bisa menggunakan algoritma yang dikembangkan khusus untuk itu, lihat komentar.

2
axiomer

Anda lupa satu hal kecil:

Kekuatan kata sandi.

Hanya 2 kata yang kelebihan seluruh topik brilian Anda.

Memang ada ratusan topik di Stackoverflow yang memberitahu Anda untuk menggunakan ini atau itu algoritma hashing dan garam acak.
Dan hanya sedikit yang menjelaskan bahwa dengan kata sandi yang lemah semua perlindungan delapan-item-daftar Anda, semua hash hmac-chmak-bumblemak ekstra aman dengan 2048 byte-panjang-garam akan rusak dalam hitungan detik.

Adapun pengguna miskin yang tidak dapat mengingat $#%H4df84a$%#R kata sandi - hanya membuatnya tidak menggunakan kata sandi tetapi a frasa sandi.

Is it a good day today, Winkie? Menggunakan berbagai huruf besar dan kata sandi dengan kompleksitas yang disarankan tetapi jauh lebih mudah diingat.

Tentu saja frasa ini tidak boleh sama dengan kata sandi umum seperti "Joe" atau "123".
"Selamat pagi", "Ya Tuhan! Mereka membunuh Kenny!" frasa harus dihindari.
Tetapi dengan menambahkan beberapa kepribadian, tidak apa-apa:
Oh My God! They moved Cthulhu! terlihat cukup

Satu hal lagi adalah komunikasi yang aman antara server dan browser
Tanpa itu, kata sandi sederhana dapat dengan mudah "diendus" pada salah satu router yang terlibat dalam komunikasi.

SSH atau beberapa implementasi Otorisasi Intisari tidak kalah penting.

10

Fungsi hash tujuan umum (MD5, SHA1, SHA256) dengan hash yang baik mungkin cukup aman untuk sebagian besar situs web yang lebih kecil, mengingat daya komputasi saat ini. Namun, hukum Moore akan memastikan bahwa kata sandi yang baik pun akan terkena serangan brute force dalam waktu dekat. Masalahnya adalah bahwa fungsi hash dapat dihitung terlalu cepat. Solusi terbaik adalah menggunakan bcrypt atau PBKDF2 dengan jumlah iterasi yang tinggi. Bcrypt vs PBKDF2 dibahas di http://security.stackexchange.com .

Beberapa orang mungkin berpikir ini berlebihan untuk sebagian besar situs tetapi ingat bahwa kata sandi digunakan kembali setiap saat dan penyimpanan kata sandi biasanya adalah sesuatu yang tidak akan Anda ubah sampai ada masalah.

Rekomendasi:

  1. Gunakan bcrypt atau PBKDF2. JANGAN GUNAKAN kandidat SHA3. Mereka mungkin berisi lubang keamanan yang belum ditemukan.
  2. Gunakan garam acak untuk membantu melindungi terhadap serangan tabel Rainbow.
  3. Paksa pengguna untuk memilih frasa sandi.

Informasi lebih lanjut

5
tony

Fungsi hash_hmac() akan menjadi pilihan yang baik, bahkan dapat mengatasi masalah algoritma hash yang lebih lemah. Satu-satunya masalah adalah, itu juga cepat. Itu artinya dengan cpu-power (cloud) yang cukup, pembuatan tabel Rainbow yang berbeda menjadi mungkin, itulah alasan untuk iterasi. Jika Anda membutuhkan keamanan tinggi ini, maka Anda dapat mengukur waktu yang diperlukan iterasi Anda, dan kemudian menghitung jumlah iterasi yang diperlukan untuk waktu tertentu.

Edit:

Iterasi dapat menyelesaikan masalah ini, itu harus dilakukan dengan cara, bahwa seseorang dapat meningkatkan jumlah iterasi kemudian, tanpa membuat hash yang ada menjadi tidak valid. Ini diperlukan untuk beradaptasi dengan perangkat keras masa depan yang baru, tetapi mengharuskan untuk menyimpan parameter hashing bersama dengan hash.

Algoritma hash bcrypt dirancang untuk memenuhi permintaan ini, saya menulis sebuah contoh kecil tentang cara menggunakan bcrypt dengan PHP 5. , saya mencoba berkomentar, sehingga orang dapat berkomentar, sehingga orang dapat mengerti apa yang terjadi.

2
martinstoeckli