Seberapa unik id sesi php


90

Seberapa unik id sesi php? Saya mendapat kesan dari berbagai hal yang saya baca bahwa saya seharusnya tidak mengandalkan dua pengguna yang tidak pernah mendapatkan sessionid yang sama. Bukankah itu GUID?

Jawaban:


39

Session_id memang bisa diduplikasi, tapi kemungkinannya sangat rendah. Jika Anda memiliki situs web dengan lalu lintas yang adil, itu mungkin terjadi sekali dalam kehidupan situs web Anda, dan hanya akan mengganggu satu pengguna untuk satu sesi.

Hal ini tidak perlu diperhatikan kecuali jika Anda berharap untuk membangun situs web dengan lalu lintas yang sangat tinggi atau layanan untuk industri bank.


4
Saya telah mendengar laporan tentang situs yang memiliki banyak kasus tabrakan.
ColinM

20
Pertanyaan itu telah ditanyakan hampir 4 tahun yang lalu. Akan menarik untuk mengetahui apakah algoritma id sesi telah berimprovisasi sejak saat itu ...
Sliq

@ColinM: dan situs tersebut memiliki 1 juta pengunjung unik / hari.
e-satis

1
Secara terpisah saat ini berbasis (MD5 / SHA1 hash) pada alamat jarak jauh pengguna, waktu lokal dan beberapa nomor acak (LCG) .
Caramiriel

2
Saya tidak perlu merusak perangkat seluler, perangkat seluler terus-menerus rusak. :)
hakre

67

Ini tidak terlalu unik saat dikirim. Dalam konfigurasi default, ini adalah hasil dari hash dari berbagai hal termasuk hasil gettimeofday (yang tidak terlalu unik), tetapi jika Anda khawatir, Anda harus mengkonfigurasinya untuk menarik beberapa entropi dari / dev / urandom, seperti itu

ini_set("session.entropy_file", "/dev/urandom");
ini_set("session.entropy_length", "512");

cari "php_session_create_id" di kode untuk algoritma sebenarnya yang mereka gunakan.

Diedit untuk menambahkan: Ada generator nomor acak DFA yang diunggulkan oleh pid, dicampur dengan waktu di usec. Ini bukan kondisi keunikan yang tegas terutama dari segi keamanan . Gunakan konfigurasi entropi di atas.

Memperbarui:

Pada PHP 5.4.0 session.entropy_file default ke / dev / urandom atau / dev / arandom jika tersedia. Di PHP 5.3.0 petunjuk ini dibiarkan kosong secara default. Manual PHP


1
Ya, ketika saya adalah kontrak untuk situs web yang harus sangat aman terhadap kombatan musuh dan semacamnya, saya benar-benar membuat penangan sesi saya sendiri dan memberinya data entropi langsung dari random.org. Tetapi persyaratan dari sistem itu jauh melampaui apa yang kebanyakan manusia biasa hadapi w / ;-)
Theodore R. Smith

1
@ thomas-jensen, gettimeofday adalah stempel waktu unix, kecuali dinyatakan dalam μsec (terkadang). Baca metode php_session_create_id yang ditautkan di atas.
djsadinoff

4
Mengubah panjang entropi meningkatkan keacakan tetapi tidak secara signifikan memengaruhi kemungkinan tabrakan karena panjang hash masih sama. Namun, mengubah session.hash_function memungkinkan Anda menggunakan hash yang lebih panjang seperti sha512 misalnya.
ColinM

2
Saya merasa aneh jika ada tabrakan. Tentunya PHP harus dibuat untuk memeriksa apakah ada sesi yang valid di bawah id itu dan kemudian menghasilkan ID yang berbeda ..
Luke

1
@ theodore-r-smith, mengambil entropi dari sumber yang tersedia untuk umum adalah praktik yang buruk. Anda harus menganggap Anda "Musuh kombatan" juga memiliki akses ke random.org ...
Avri

12

Jika Anda ingin tahu bagaimana PHP menghasilkan ID sesi secara default, periksa kode sumber di Github . Ini tentu saja tidak acak dan didasarkan pada hash (default: md5) dari bahan-bahan ini (lihat baris 310 potongan kode):

  1. alamat IP klien
  2. Waktu saat ini
  3. PHP Linear Congruence Generator - generator bilangan acak semu (PRNG)
  4. Sumber acak khusus OS - jika OS memiliki sumber acak yang tersedia (mis. / Dev / urandom)

Jika OS memiliki sumber acak, maka kekuatan ID yang dihasilkan untuk tujuan menjadi ID sesi tinggi ( / dev / urandom dan sumber acak OS lainnya (biasanya) PRNG yang aman secara kriptografis ). Namun jika tidak, maka itu memuaskan.

Tujuan dengan pembuatan identifikasi sesi adalah untuk:

  1. meminimalkan kemungkinan menghasilkan dua ID sesi dengan nilai yang sama
  2. membuatnya sangat menantang secara komputasi untuk menghasilkan kunci acak dan menekan tombol yang sedang digunakan .

Ini dicapai dengan pendekatan PHP untuk pembuatan sesi.

Anda tidak dapat benar-benar menjamin keunikan , tetapi probabilitasnya sangat rendah untuk mencapai hash yang sama dua kali sehingga, secara umum, tidak perlu dikhawatirkan.


11

Anda dapat menginstal fungsi pembuatan hash alternatif jika Anda ingin menyesuaikan cara ID dibuat (ini adalah angka 128bit yang dihasilkan melalui MD5 secara default). Lihat http://www.php.net/manual/en/session.configuration.php#ini.session.hash-function

Untuk informasi lebih lanjut tentang sesi PHP, coba artikel luar biasa ini http://shiflett.org/articles/the-truth-about-sessions yang juga menautkan ke artikel lain tentang fiksasi dan pembajakan sesi.


2
Tepatnya, setel "session.hash_function = sha512" untuk PHP 5.3 dan selanjutnya ke hash 512bit. Ini seharusnya berhasil. Dengan default, tabrakan terjadi di situs dengan lalu lintas tinggi adalah hal yang umum.
ColinM

5

Size of session_id
Asumsikan seeion_id didistribusikan secara seragam dan memiliki size = 128 bits. Asumsikan bahwa setiap orang di planet ini log in sekali sehari dengan sesi baru yang terus-menerus selama 1000 tahun.

num_sesion_ids  = 1000*365.25 *7*10**9 < 2**36
collission_prob < 1 - (1-1/2**82)**(2**36)  ≈ 1 - e**-(1/2**46) 
                ≈ 1/2**46 

Jadi kemungkinan satu atau lebih tabrakan kurang dari satu dalam 70 ribu miliar. Karenanya ukuran 128-bit dari session_id harus cukup besar. Seperti yang disebutkan di komentar lain, session_manager mungkin juga memeriksa bahwa session_id baru belum ada.

Keacakan
Oleh karena itu, pertanyaan besar yang saya pikirkan adalah apakah session_id: s dihasilkan dengan keacakan semu yang baik. Tentang itu Anda tidak pernah bisa yakin, tetapi saya akan merekomendasikan menggunakan solusi standar yang terkenal, dan sering digunakan untuk tujuan ini (seperti yang mungkin sudah Anda lakukan).

Meskipun tabrakan dihindari karena pemeriksaan, keacakan dan ukuran session_id adalah penting, sehingga peretas tidak dapat, entah bagaimana, melakukan tebakan yang memenuhi syarat dan menemukan session_id: s aktif dengan probabilitas besar.


3
Saya bukan ahli matematika, tapi saya pikir Anda lupa soal Ulang Tahun jadi kemungkinan tabrakan saat masih kecil jauh lebih besar dari yang Anda sarankan. Juga, seperti yang disarankan djsadinoff, PHP tidak selalu menggunakan metode yang baik untuk menghasilkan bilangan acak secara default.
ColinM

Sebenarnya tidak ada perkiraan yang berlaku. Perhitungan di atas adalah estimasi yang disederhanakan, di mana kami memperkirakan bahwa probabilitas tabrakan untuk session_id nr i, adalah = 1/2 82 (harusnya 1/2 92 di atas meskipun = salah ketik). Pada kenyataannya probabilitasnya adalah (i-1) / 2 128 selama tidak ada tabrakan sebelumnya yang terjadi. 1/2 92 hanya bertahan untuk session_id terakhir.
MrJ

3

Saya belum menemukan konfirmasi tentang ini tetapi saya percaya php memeriksa apakah id sesi sudah ada sebelum membuatnya dengan id itu.

Masalah pembajakan sesi yang dikhawatirkan orang adalah ketika seseorang mengetahui id sesi dari pengguna aktif. Hal ini dapat dicegah dengan berbagai cara, untuk info lebih lanjut Anda dapat melihat halaman ini di php.net dan makalah tentang fiksasi sesi ini.


2
... tetapi jika Anda hanya satu server php di bank yang terdiri dari beberapa, tidak ada jaminan bahwa server memiliki pengetahuan yang cukup untuk mengetahui apakah sesssionID telah digunakan.
djsadinoff

Mengapa penting jika saya mendapatkan session id yang sama di 2 server php yang berbeda? Dengan asumsi 2 domain berbeda, cookie sesi hanya dapat diakses dari setiap domain ...?
daremon

3
Cara termudah untuk mencegah dupes pada lingkungan multi-server adalah dengan menyimpan sesi dalam memcache melalui penangan sesi memcache. masalah terpecahkan dan pengguna Anda dapat memantul di sekitar server berbeda tanpa kehilangan barang-barang mereka.
Theodore R. Smith

@daremon dia berbicara tentang beberapa server untuk satu domain.
gtd

Ini tidak benar. PHP tidak memeriksa id sesi yang ada saat membuat yang baru. Lihat kode penangan sesi PHP dan tidak ada metode yang diterapkan untuk tujuan ini.
ColinM

2

Tidak, id sesi bukan GUID, tetapi dua pengguna tidak boleh mendapatkan id sesi yang sama karena mereka disimpan di sisi server.


2
Mungkin karena penyimpanan sisi server tidak menjamin keunikan dengan cara apa pun. Keunikan adalah satu hal - jika ada tabrakan, itu akan bertabrakan di mana pun sesi disimpan.

Bukan oleh saya, saya menghargai tanggapan Anda (dan juga yang lainnya). - Jalov
Jalov

2
ID sesi disimpan di sisi server dan klien. Konten sesi disimpan di sisi server. Dan faktanya cukup banyak tidak terkait dengan keunikan id sesi.
YudhiWidyatama

0

Anda dapat memilih untuk menyimpan berbagai sesi pada DB bersama dengan aa DB generate unique field; gabungkan keduanya dan simpan dalam variabel sesi, lalu periksa yang itu sebagai gantinya id sesi.


Selamat datang di stackoverflow. Sayangnya, jawaban Anda tidak mencoba menjawab pertanyaan itu. OP bertanya seberapa unik ID sesi itu. Menyimpan data pada database dan kemudian menggunakan variabel sesi untuk mengambilnya hanya menambah kompleksitas masalah bukan?
Noah Boegli

@NoahBoegli solusi lain menyarankan metode yang jauh lebih rumit.
Pernicious

-4
<?php
session_start();
$_SESSION['username']="username";
?>

<!DOCTYPE html>
<html>
<head>
    <title>Update</title>
</head>
<body>

<table border="2">
    <tr>
        <th>Username</th>
        <th>Email</th>
        <th>Edit</th>
    </tr>
<?php
     $conn=mysqli_connect("localhost","root","","telephasic");
     $q2="select * from register where username = '".$_SESSION['username']."'";
     $run=mysqli_query($conn, $q2);
     while($row=mysqli_fetch_array($run))
     {
         $name=$row[1];
         $email=$row[2];
     ?>

    <tr>
        <td><?php echo $name; ?></td>
        <td><?php echo $email; ?></td>
        <td><a href="edit.php"> Edit </a></td>
    </tr>
 <?php } ?>
 </table> 
 </body>

jika nama pengguna Anda berbeda atau unik, Anda dapat menggunakan kode ini untuk sesi

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.