Quelle est la durée d'une session PHP id de chaîne?

Je suis en train de faire une table dans une base de données MySQL pour enregistrer certaines données de session, y compris session_id. Quelle devrait être la longueur de la VARCHAR pour stocker les session_id chaîne?

InformationsquelleAutor Gustavo | 2012-09-03
  1. 33

    Dépend session.hash_function et session.hash_bits_per_character.

    Découvrez la session_id page pour plus d'info.

    Plus la valeur est élevée session.hash_bits_per_character la plus courte de votre
    session_id deviendra en utilisant plus de bits par caractère. Le possible
    les valeurs sont 4, 5, ou 6.

    Lors de l'utilisation de sha-1 pour le hachage (par la mise en
    la fonction ini_set('session.hash_function', 1) de la session suivante de la chaîne
    les longueurs sont produites par les trois session.hash_bits_per_character
    paramètres:

    4 - 40 chaîne de caractères

    5 - 32 caractères chaîne de

    6 - 27 chaîne de caractères

    • Donc 40 caractères à la sécurité de l'ensemble, et si je veux économiser quelques octets, je doit vérifier la config php, non?
    • Vérifier php.ini pour voir ce que les paramètres sont. 40 caractères est le résultat de hachage SHA-1 de la fonction et de 4 bits par caractère. Vous pouvez faire echo strlen(session_id()); pour voir la longueur et faire de votre champ de base de données en conséquence.
    • Pour référence, le session_id longueur sera également 32 si vous utilisez la fonction de hashage MD5 et 4 de hachage bits par caractère. Qui m'a fait m'arracher les cheveux pendant quelques heures aujourd'hui.
    • Le nombre de caractères n'a pas d'implications en matière de sécurité, seule la fonction de hachage grâce à son potentiel de hachage de taille. Comment vous encodez que de hachage est juste une question de ce que serializations le transport ou les systèmes de stockage exiger. Théoriquement, vous pouvez encoder un SHA1 en seulement 20 octets avec un simple champ de bits. Malheureusement, les cookies et les Uri (commune des transports) prennent en charge uniquement les caractères, et selon le jeu de caractères et encodage de caractères que vous pouvez utiliser, vous aurez la sérialisation frais généraux, double avec 4 bits/char (implicite est ici que les caractères de 8 bits -- les 4 autres bits sont gaspillés).
    InformationsquelleAutor sachleen
  2. 29

    @sachleen réponse n'est pas complète.

    Des informations plus détaillées au sujet de l'id de session longueur est décrit ici.

    Résumé: 

    128-bit digest (MD5)  
4 bits/char: 32 char SID    
5 bits/char: 26 char SID    
6 bits/char: 22 char SID

160-bit digest (SHA-1)
4 bits/char: 40 char SID    
5 bits/char: 32 char SID    
6 bits/char: 27 char SID

    Et de l'échantillon de regex pour vérifier l'id de session: 

    preg_match('/^[a-zA-Z0-9,-]{22,40}$/', $sessionId)
    • cela a été très utile pour moi!!!
    • Excellente réponse, la pièce manquante d'un puzzle pour moi.
    InformationsquelleAutor Andron
  3. 4

    Cela dépend de ces paramètres de configuration:
    session.hash_function et session.hash_bits_per_character

    Plus court d'ID de session longueurs ont le plus de chance de collision, mais cela dépend aussi beaucoup sur l'ID de l'algorithme de génération. Étant donné les paramètres par défaut, la longueur de l'ID de session doit être approprié pour la plupart des applications. Pour des implémentations de sécurité, vous pouvez envisager de chercher dans la façon dont PHP génère son Id de session et vérifier si c'est cryptographique sécurisé. Si elle ne l'est pas, alors vous devez rouler votre propre algorithme avec un cryptographiquement sûre source de l'aléatoire.

    • La chance de collision est entièrement déterminée par la fonction de hachage, de l'entropie utilisée, et le volume du trafic. À l'aide d'une fonction de hachage sécurisé sera de produire un plus grand ID de session de chaîne, donc si c'est ce que tu entend par la plus courte de l'ID de session longueurs avoir plus de chance de collision, alors vous êtes correct, mais que le raccourcissement de la longueur à l'aide d'un supérieur, la profondeur de bits par caractère n'aura aucun effet.
    • Est de 128 caractères identifiant de session d'un overkill pour l'application web générique?
    InformationsquelleAutor John Woo
  4. 0

    Je ne sais pas où est mon application sera utilisée pour puis-je définir comme:
    VARCHAR(127)
    et j'espère que ce sera la grande inconnue utilisateurs MySQL.

    • Si par des inconnus vous dire inconnu, vous pourriez envisager de le configurer en tant que TEXTE du contrat et à étendre en tant que de besoin, sinon vous aurez beaucoup d'espace vide dans votre table, et même alors, il peut échouer avec un 128 valeur de la longueur.
    • VARCHAR est plus rapide que le TEXTE.
    • yep, il aura à choisir entre la sécurité et le TEXTE souple et rapide de type VARCHAR
    InformationsquelleAutor Abbas Uddin
  5. 0

    Par le php longueur d'installation est toujours 26 (exmp: psprdaccghmmre1oo2eg0tnpe6)

    InformationsquelleAutor Gocha