it-swarm-id.com

# Putaran yang disarankan untuk bcrypt

Apa yang saat ini (Juli 2012) jumlah putaran bcrypt yang disarankan untuk hashing password untuk situs web rata-rata (hanya menyimpan nama, alamat email dan alamat rumah, tetapi tidak ada kartu kredit atau informasi medis)?

Dengan kata lain, apa kemampuan komunitas peretas kata sandi bcrypt saat ini? Beberapa perpustakaan bcrypt menggunakan 12 putaran (2 ^ 12 iterasi) sebagai pengaturan default. Apakah itu workfactor yang direkomendasikan? Apakah 6 putaran tidak cukup kuat (yang merupakan batas untuk hashing bcrypt sisi klien dalam Javascript, lihat juga Tantangan tantangan: hashing kata sandi sisi klien dan verifikasi kata sandi sisi server )?

Saya telah membaca jawaban https://security.stackexchange.com/a/3993/11197 yang memberikan diskusi mendalam bagaimana menyeimbangkan berbagai faktor (meskipun untuk PBKDF2-SHA256). Namun, saya mencari nomor yang sebenarnya. Aturan praktis.

94
Jason Smith

Saya pikir jawaban untuk semua pertanyaan Anda sudah terkandung dalam jawaban Thomas Pornin . Anda menautkannya, sehingga Anda mungkin mengetahuinya, tetapi saya sarankan Anda membacanya lagi.

Prinsip dasarnya adalah: jangan memilih sejumlah putaran; sebagai gantinya, pilih jumlah waktu yang akan dilakukan verifikasi kata sandi di server Anda, lalu hitung jumlah putaran berdasarkan itu. Anda ingin verifikasi berlangsung selama Anda bisa berdiri.

Untuk beberapa contoh angka konkret, lihat jawaban Thomas Pornin. Dia menyarankan tujuan yang masuk akal adalah untuk verifikasi/hashing kata sandi untuk mengambil 241 milidetik per kata sandi. (Catatan: Thomas awalnya menulis "8 milidetik", yang salah - ini adalah angka untuk kesabaran satu hari, bukan satu bulan.) Itu masih memungkinkan server Anda memverifikasi 4 kata sandi per detik (lebih banyak jika Anda bisa melakukannya secara paralel). Thomas memperkirakan bahwa, jika ini adalah tujuan Anda, sekitar 20.000 putaran ada di stadion baseball yang tepat.

Namun, jumlah putaran optimal akan berubah dengan prosesor Anda. Idealnya, Anda akan mengukur berapa lama prosesor Anda dan memilih nomor yang sesuai. Ini tidak butuh waktu lama; jadi untuk hasil terbaik, cukup buat skrip dan cari tahu berapa putaran yang diperlukan untuk memastikan bahwa hashing kata sandi memakan waktu sekitar 240 milidetik di server Anda (atau lebih lama, jika Anda bisa tahan).

41
D.W.

Ketika BCrypt pertama kali diterbitkan, pada tahun 1999, mereka membuat daftar faktor biaya default implementasi mereka:

  • pengguna normal: 6
  • pengguna super: 8

Mereka juga mencatat:

Tentu saja, berapa pun biaya yang orang pilih harus dievaluasi kembali dari waktu ke waktu

Biaya bcrypt dari 6 berarti 64 putaran (2 6  = 64).

Jika kita menggunakan nilai awal "pengguna normal", kami ingin mencoba menyesuaikan untuk menghitung inflasi daya ( dengan asumsi rata-rata akan berlipat ganda setiap 18 bulan ).

R = R × 2(bulan/18)
R = 64 × 2(bulan/18)

Hari ini (9 Maret 2015) adalah 171 bulan sejak 12/31/1999 (atau gunakan 1/1/2000 untuk kesederhanaan), jumlah putaran seharusnya menjadi dua kali lipat lebih dari 9 kali:

R = 64 × 2(171/18)
R = 64 × 29.5
R = 64 × 724.1
R = 46,341.0

Pada akhirnya, kami ingin mengubahnya kembali menjadi faktor biaya

biaya = ln (R)/ln (2)
biaya = ln (46,341.0)/ln (2)
biaya = 15,5

Kepraktisan faktor biaya 15 tergantung pada kekuatan komputasi server Anda. Sebagai contoh, PC desktop saya adalah Intel Core i7-2700K CPU @ 3,50 GHz. Saya awalnya membandingkan penerapan BCrypt pada 23/1/2014:

1/23/2014  Intel Core i7-2700K CPU @ 3.50 GHz

| Cost | Iterations        |    Duration |
|------|-------------------|-------------|
|  8   |    256 iterations |     38.2 ms | <-- minimum allowed by BCrypt
|  9   |    512 iterations |     74.8 ms |
| 10   |  1,024 iterations |    152.4 ms | <-- current default (BCRYPT_COST=10)
| 11   |  2,048 iterations |    296.6 ms |
| 12   |  4,096 iterations |    594.3 ms |
| 13   |  8,192 iterations |  1,169.5 ms |
| 14   | 16,384 iterations |  2,338.8 ms |
| 15   | 32,768 iterations |  4,656.0 ms |
| 16   | 65,536 iterations |  9,302.2 ms |

Tapi itu 2014

Pengaturan waktu tersebut awalnya dihitung pada awal 2014. Hanya 156 bulan (bukan 171) bulan yang seharusnya digunakan dalam perhitungan saya:

R = 64 × 2(156/18)
R = 64 × 28.66
R = 64 × 406.8
R = 26.035.2

biaya = ln (R)/ln (2)
biaya = ln (26.035.2)/ln (2)
biaya = 14,7

Tapi i7-2700K sudah dihentikan

I7-2700K sudah dihentikan (Q1 2013) saat saya menjalankan tolok ukur saya. Itu dirilis, dan canggih, pada Q4 2011. Jika saya menjalankan angka untuk Q4 2011:

R = 64 × 2(129/18)
R = 64 × 27.16
R = 64 × 143.7
R = 9,196.8

biaya = ln (R)/ln (2)
biaya = ln (9,196.8)/ln (2)
biaya = 13.2

Biaya 13 adalah, di desktop saya, hampir 2 detik lebih dari sedetik.

Berapa lama Anda tahan?

Itu memberi Anda rasa keterlambatan yang sedang dipertimbangkan oleh pelaksana awal ketika mereka menulisnya: ~ 0,5-1 detik.

Tapi, tentu saja, semakin lama Anda berdiri, semakin baik. Setiap implementasi BCrypt yang saya lihat digunakan 10 sebagai biaya default. Dan implementasi saya menggunakannya. Saya percaya ini saatnya bagi saya untuk meningkatkan biaya standar menjadi 12.

Pemeriksaan Masa Depan

Saya mungkin juga mengubah fungsi hash:

hash = HashPassword("correct battery horse stapler");

yaitu yang bergantung pada biaya default, alih-alih menggunakan biaya geser otomatis. Dengan cara ini biaya meningkat seiring waktu. Mengubah:

String HashPassword(String password)
{
   return BCrypt.HashPassword(password, BCRYPT_DEFAULT_COST);
}

untuk sesuatu seperti:

String HashPassword(String password)
{  
   /*
     Rather than using a fixed default cost, run a micro-benchmark
     to figure out how fast the CPU is.
     Use that to make sure that it takes **at least** 250ms to calculate
     the hash
   */
   Int32 costFactor = this.CalculateIdealCost();
   //Never use a cost lower than the default hard-coded cost
   if (costFactor < BCRYPT_DEFAULT_COST) 
      costFactor = BCRYPT_DEFAULT_COST;

   return BCrypt.HashPassword(password, costFactor);
}

Int32 CalculateIdealCost()
{
    //Benchmark using a cost of 5 (the second-lowest allowed)
    Int32 cost = 5;

    var sw = new Stopwatch();
    sw.Start();
    this.HashPassword("microbenchmark", cost);
    sw.Stop();

    Double durationMS = sw.Elapsed.TotalMilliseconds;

    //Increasing cost by 1 would double the run time.
    //Keep increasing cost until the estimated duration is over 250 ms
    while (durationMS < 250)
    {
       cost += 1;
       durationMS *= 2;
    }

    return cost;
}

Edit 3/12/2015 : Angka kecepatan yang diperbarui. Delphi XE6 32-bit compiler (c.2013) menghasilkan kode yang besarnya lebih cepat dari Delphi 5 (c.1999) lakukan untuk prosesor yang sama. Delphi XE6 64-bit compiler menghasilkan kode 20% lebih lambat dari compiler 32-bit.

61
Ian Boyd

Penurunan Kunci Lebih Kuat melalui Fungsi Memori-Keras Berurutan adalah makalah yang sangat bagus tentang topik peregangan kunci. Pada halaman 14 membandingkan berbagai algoritma hashing dengan berapa banyak uang yang dibutuhkan untuk memecahkan hash, yang merupakan cara yang berguna untuk memikirkan hal-hal ini. (Di samping catatan ChromeOS menggunakan Scrypt jika TPM tidak tersedia.)

Idenya adalah bahwa Anda ingin agar kata sandi ini tidak terputus selama mungkin. Dengan hukum Moore, ini adalah target yang bergerak cepat secara eksponensial. Scrypt menggunakan jumlah variabel memori dan cpu, variabel ini bisa menjadi lebih berat sebagai fungsi waktu. Dalam setiap kali klien login Anda dapat memperbarui hash kata sandi agar lebih aman. Dalam kasus PBKDF2 ini bisa terlihat seperti rounds=2^(current_year-2000) atau sesuatu seperti itu.

Penting untuk dicatat bahwa Anda tidak bisa hanya membongkar pemrosesan ini ke klien dan mengharapkan protokol Anda aman. Semua protokol otentikasi hashing sisi klien yang saya tahu mengharuskan server untuk membuat perhitungan yang identik untuk memverifikasi kredensial otentikasi (NTLM, NTLMv2, SRP, WPA-PSK ...).

3
rook