Le chiffrement db mot de passe dans l'application.conf pour Jouer 2.0/anorm

Question

Je ne veux pas mettre des mots de passe non cryptés dans le fichier de config.

Cette question: Le chiffrement db mot de passe dans l'application.conf a une excellente solution au problème, mais il ne fonctionne que pour Jouer en 1.

Quelqu'un connais une solution qui fonctionne pour Jouer 2.0?Je suis à l'aide de anorm en Scala version de Play 2.0.2.

Answer 1

Grâce à la discussion avec Raffaele et à la suite de ma propre enquête sur le code, il semble que la lecture 2.0 ne vous permet pas de chiffrer les mots de passe de DB.

Si j'ai manqué quelque chose, merci de me le faire savoir.

edit : On peut contourner le problème en utilisant un pilote de base de données personnalisé de la manière suivante:

// Just redirect everything to the delegate
class DelegatingDriver(delegate: Driver) extends Driver
{
  def connect(url: String, info: Properties) = delegate.connect(url, info)
  def acceptsURL(url: String) = delegate.acceptsURL(url)
  def getPropertyInfo(url: String, info: Properties) = delegate.getPropertyInfo(url, info)
  def getMajorVersion = delegate.getMajorVersion
  def getMinorVersion = delegate.getMinorVersion
  def jdbcCompliant() = delegate.jdbcCompliant()
}

// Replace password in properties with the decrypted one
class MyDecryptingDriver extends DelegatingDriver(Class.forName("<my.original.Driver>").newInstance().asInstanceOf[Driver])
{
  override def connect(url: String, info: Properties)= {
    // copy Properties
    val overriddenProperties= clone(info)   
    // override password property with the decrypted value
    Option(info.getProperty("password")).foreach(value => overriddenProperties.setProperty("password", decryptPassword(value)))
    super.connect(url, overriddenProperties)
  }

  def clone(orig: Properties)= {
    val result= new Properties()
    orig.propertyNames().map(_.asInstanceOf[String]).foreach(pName => result.setProperty(pName, orig.getProperty(pName)))
    result
  }

  def decryptPassword(encrypted: String)= ...
}

Ensuite, vous remplacez l'application.conf / dB..Driver par My.com.MyDécrypte pilote.Pas parfait mais travaille pour moi ...

Answer 2

Tous les efforts sont inutiles. Lorsque nous mettons le mot de passe haché dans une base de données, c'est parce que les humains peuvent conserver des mots de passe dans leur cerveau et leur cerveau ne sont pas lisibles . C'est ce qu'on appelle le cryptage asymétrique .

La chose que vous parlez est uniquement possible avec Symmetric cryptage: le programme a la clé de l'exécution et utilise cette touche pour déchiffrer le mot de passe de DB. Mais quel est le point dans la conservation du mot de passe de DB crypté avec une clé, et toujours à la disposition de cette clé disponible au public? (Ceci est vrai pour les sources Java et les classes compilées). Une chaîne n'est aussi forte que son lien le plus faible.

Lorsqu'une machine doit se connecter à un dB, il a besoin d'un mot de passe: nous stockons ce mot de passe en texte brut car le programme doit l'utiliser tel quel et Aucune entrée humaine n'est requise . Tout ce que nous pouvons faire pour appliquer la sécurité consiste à restreindre l'accès à ce fichier texte brut, à la protéger avec un mot de passe stocké uniquement dans l'esprit de l'administrateur (BTW, plus probablement que l'administrateur conserve tous ses mots de passe dans une base de données, peut-être avec un mot de passe maître). Notez que les choses ne changent pas si vous utilisez le plugin de lecture mentionné.

La seule autre chose qui vient à mon esprit est une application de lecture qui se connecte uniquement à la base de données lorsque l'administrateur entrait le mot de passe de DB (mais ce n'est vraiment qu'un exercice de pensée)

Answer 3

Je sais que c'est un peu tard, mais il n'y a pas plus récent des discussions à ce sujet problema.Je veux partager la solution réelle (lire en v. 2.5.X), tel que suggéré dans la documentation, est maintenant possible de remplacer le GuiceApplicationLoader pour configurer le GuiceApplicationBuilder pour traiter d'une certaine manière la première configs.

Dans une nouvelle classe modules/ApplicationLoaderConfig.scala:

import javax.crypto.Cipher
import javax.crypto.spec.SecretKeySpec
import javax.xml.bind.DatatypeConverter

import play.api.inject.guice._
import play.api.{ApplicationLoader, Configuration}

class ApplicationLoaderConfig extends GuiceApplicationLoader() {

  override def builder(context: ApplicationLoader.Context): GuiceApplicationBuilder = {

    // Decrypt secrets
    val decryptedConfig = context.initialConfiguration ++
      Configuration("config.to.descrypt.1" -> decryptDES(context.initialConfiguration.getString("config.to.descrypt.1").get)) ++
      Configuration("config.to.descrypt.2" -> decryptDES(context.initialConfiguration.getString("config.to.descrypt.2").get))

    initialBuilder
      .in(context.environment)
      .loadConfig(decryptedConfig)
      .overrides(overrides(context): _*)
  }

  private def decryptDES(secret: String): String = {
    val key = "12345678"
    val skeySpec = new SecretKeySpec(key.getBytes("UTF-8"), "DES")

    val cipher = Cipher.getInstance("DES/ECB/PKCS5Padding")
    cipher.init(Cipher.DECRYPT_MODE, skeySpec)

    new String(cipher.doFinal(DatatypeConverter.parseBase64Binary(secret)))
  }
}

Également ajouter à application.config:

play.application.loader = "modules.ApplicationLoaderConfig"