12
votes

Pourquoi ne pas driversermanager.geconnection (URL à chaîne, utilisateur de chaîne, mot de passe [] de modèle)?

Nous savons que c'est une bonne pratique de préférer Char [] sur java.lang.string pour stocker des mots de passe. C'est pour les deux raisons suivantes (comme j'ai lu):

  1. Char [] sont mutables afin que nous puissions effacer les mots de passe après l'utilisation.
  2. Les littéraux de chaîne vont dans une piscine qui ne recevra pas les ordures recueillies comme d'autres objets, peut donc apparaître dans des décharges de mémoire.

    mais java.sql.drivermanager n'a pas de getconnection () qui se conformant à la meilleure pratique ci-dessus, car son paramètre de mot de passe est une chaîne.

    drivermanager.geconnection (URL de chaîne, utilisateur de chaîne, mot de passe de chaîne)

    Je pense que l'API devrait avoir une méthode surchargée avec la signature suivante:

    drivermanager.geconnection (URL de chaîne, utilisateur de chaîne, Char [] Mot de passe)

    Que pensez-vous de cela? Voyez-vous un moyen alternatif de surmonter ce tirage?

    aimerait entendre vos pensées.


0 commentaires

6 Réponses :


4
votes

chaîne littéraux aller dans une piscine, mais je ne m'attendrais pas à ce que le mot de passe soit littéral (codé dur dans le programme). Je m'attendrais à ce qu'il vienne d'une configuration ou similaire. En tant que tel, ce ne sera pas un littéral et obtenir des ordures recueillies (à condition que toutes les références soient cassées).


0 commentaires

2
votes

On ne peut spéculer que, sauf si vous pouvez demander au concepteur de l'API.

Ma spéculation est ceci:

L'API principale qui utilise char [] au lieu de chaîne pour les mots de passe que je connais est JAVILE> JPASSWORDFIELD . Il le fait afin de permettre au programme d'écraser le mot de passe entré par l'utilisateur avec d'autres valeurs une fois que les valeurs ont été utilisées (ce qui n'est pas possible avec une chaîne , qui s'attardera en mémoire à moins jusqu'à ce qu'il soit recueilli à la poubelle).

Le mot de passe utilisé pour se connecter à une base de données n'est généralement pas entré par l'utilisateur dans la plupart des applications que je connais, mais provient d'une sorte de configuration / répertoire /...

Peu importe l'origine de: l'application est capable de la reconstruire une fois qu'elle n'est plus connue. C'est la grande différence entre les mots de passe entrés par l'utilisateur et les mots de passe d'acquisition par programme.

Étant donné que le mot de passe peut généralement être acquis sur des moyens plus facilement que de rechercher toute la mémoire, un programme utilisé, la fixation de ce vecteur d'attaque n'est pas une priorité absolue


0 commentaires

2
votes

Votre raison n ° 2 est celle que j'ai vue donnée le plus souvent pour l'utilisation de Char [] sur une chaîne. Cependant, en général, je pense que si vous supposez que quelqu'un a accès à l'État de votre programme via un débogueur ou un autre moyen, il n'y a aucune raison pour laquelle ils ne peuvent pas aussi regarder le contenu d'un caractère [].


0 commentaires

1
votes

L'argument d'utilisation de Char [] Les matrices s'appliquent la plupart desquelles l'utilisateur tape le mot de passe, et vous souhaitez minimiser l'exposition de ce mot de passe.

Les connexions JDBC ne sont presque jamais comme ça. Le mot de passe est stocké dans un fichier de configuration, peut-être obscurci et constitue une source beaucoup plus grande d'une fuite que le potentiel de lecture de la mémoire.

Quoi qu'il en soit, la norme JDBC permet de passer des mots de passe dans des objets de propriétés et même de l'URL, donc je pense avoir un paramètre char [] vous donnerait un faux sentiment de sécurité.

Si vous avez un cas d'utilisation réel où le mot de passe doit être retiré de la mémoire le plus rapidement possible pour être irrécupérable, ce qui a du sens dans le contexte d'une vraie application JDBC, j'aimerais l'entendre. Je peux imaginer qu'une telle chose pouvait exister, mais je ne peux pas penser à un scénario où l'utilisation d'un Char [] rend vraiment les choses plus sécurisées.


1 commentaires

Note intéressante sur "Les connexions JDBC ne sont presque jamais comme ça". Je suis venu chercher ce sujet parce que dans notre cas, il est comme ça. L'utilisateur entre dans le mot de passe, nous essayons de le garder aussi secure que possible, puis de certaines API - à savoir JDBC et URL, bousillez-la d'une manière majeure comme celle-ci, puis nous sommes de retour à ne rien avoir amélioré en appuyant sur le charcuterie. []. :(



1
votes

Votre point 1 est valide à certains étendue, mais le point 2 sur les chaînes qui se retrouvent dans une piscine à chaîne non collecte ne sont que pour les chaînes littérales statiques (chaînes qui apparaissent directement dans le code). Si vous auriez des mots de passe stockés directement dans votre code, je vous recommande de vous inquiéter de ces premiers car il est beaucoup plus facile de les trouver dans des fils de classe, puis dans une machine virtuelle en cours d'exécution.

Donc, si vous pensez que vous devez stocker vos mots de passe dans un caractère [], vous pouvez toujours créer un objet de chaîne à partir de celui-ci avant d'appeler GetConnection (). Si la mise en œuvre du pilote ne stocke pas l'objet de chaîne en interne, il ne sera plus accessible et ainsi être collecté assez rapidement. La seule chance de toujours le lire puis d'examiner la mémoire de la JVM directement là où elle pourrait toujours exister. Donc, vous avez raison que l'utilisation d'un caractère [] serait un peu plus sécurisée, mais pas tant que le mot de passe devrait être dans la mémoire à l'autre de toute façon.

I.e. Un moyen très simple de saisir le mot de passe avec n'importe quel type d'API serait d'injecter un pilote SQL Fake et de saisir le mot de passe directement dans la méthode de connexion. Quiconque est capable d'examiner la mémoire JVM pour trouver une chaîne de mot de passe pas encore écrasée. Elle sera également capable d'injecter un pot de pilote modifié.


1 commentaires

Excellent point sur la manière dont la nature enfuisible de JDBC facilite la remplacement d'un pilote à une base de données avec la vôtre.



3
votes

Vous faites un bon point et la plupart des personnes qui répondent les manquent. Le pire des cas est que le mot de passe "temporaire" est échangé par le système d'exploitation, dans le texte clair, vous. Après cela, ce fichier d'échange est facilement lu et sur le disque peut même survivre à être écrasé par des zéros si l'attaquant a environ 1500 $ d'équipement ...

Le meilleur que vous puissiez faire est de vous connecter, de mot de passe = null, suivi d'un appel explicite à GC (). Si vous avez de la chance, cela effacera même les chaînes utilisées par les implémentations de pilotes.

Toute façon ...

  • Ce que vous demandez est actuellement impossible, mais serait bien.
  • Même Char [] peut survivre à certaines conditions (par exemple l'échange).
  • Votre mot de passe sera copié plusieurs fois sur le chemin de la base de données, de sorte que [] ne résout qu'une partie du problème.

    La réalité est que si la plate-forme est conçue spécifiquement pour la sécurité, toutes les méthodes ne diffèrent que de la tactique. Faites ce que vous pouvez, mais si la personne déterminée peut accéder à votre machine, Char [] vous gagnera 1 heure max.


0 commentaires