0

I Have a grails application and i want to secure data before store it in the database. Hibernate grails and jasypt offer this possibility using EncryptedStringType. but this will need a key. where i can store this key ??. please refer to this sample:

encryptor.setPassword("some password here"); 
encryptor.setAlgorithm("PBEWithMD5AndTripleDES"); 
String myText = "358904051493345"; 
System.out.println(myText);         
String encryptedText = encryptor.encrypt(myText);
System.out.println(encryptedText);           
String decriptedText =
encryptor.decrypt(encryptedText);
System.out.println(decriptedText);
Yazid
  • 108
  • 3
  • 12

1 Answers1

2

The best place to keep configuration values such as this key is in your Config.groovy, the application configuration. Using your example you might have something like this:

// Config.groovy
...
jasyptKey = 'myKeyGoesHere'
...

Taking this one step further you should consider using an external configuration file (or property file) to store sensitive production information such as this encryption key. The Grails documentation has more information on externalized configurations.

Then in your domain/service/controller you can use dependency injection to access the grailsApplication:

// example service
class MyService {
  def grailsApplication
  ...
  def serviceMethod() {
    ...
    encryptor.setPassword(grailsApplication.config.jasyptKey)
    ...
  }
  ...
}

In the very rare case where you need to access this configuration from outside a Grails/Spring artifact that doesn't support dependency injection you can use the Holders instead:

// some class in /src/
import grails.util.Holders
...
encryptor.setPassword(Holders.config.jasyptKey)
...
Joshua Moore
  • 24,706
  • 6
  • 50
  • 73
  • I'm confused Burt, why not? What should be used instead. *very worried* – Joshua Moore Oct 15 '14 at 18:52
  • Sorry, seeing overuse/misuse of Holders a lot lately. It's like I went away for ~8-9 months and this weird antipattern is now in every new plugin, SO answers, etc. Using Holders is the opposite of IoC and DI - you're pulling instead of injecting. There are a few cases where it seems impractical to do anything else, but here, it's easy - add a DI for `grailsApplication` and instead of `Holders.config` use `grailsApplicaton.config`. Most fixes are like that or slightly more. E.g. what to do in src/groovy? It's not isolated - it's called by controller/service/etc. Pass beans & config in. Simple. – Burt Beckwith Oct 15 '14 at 19:16
  • Agreed. Okay. Thank you for explaining. I will update the answer. I also agree, DI should be used when it can be. I assumed too much from the code being presented in the question. Thank you again, for the clarification and I will be sure to be more specific in the future when mentioning the use of Holders. – Joshua Moore Oct 15 '14 at 19:18
  • 2
    :) A bit too much caffeine and too little sleep here, making me cranky. Have an upvote for your trouble (and correct answer). I'd go with externalized config here for that property - not the sort of thing you want in source control. Also for that src/groovy example, if it's a Spring bean redefine it (and subclass if needed) and set the config there so it doesn't need to pull. There's only one very obscure use case where Holders is justified. Gonna keep that a secret though, don't want to give people ideas ... – Burt Beckwith Oct 15 '14 at 19:34
  • Also another good point about making the `src` class an actual bean, and we won't talk about the use case that doesn't exist. Hope you get some rest. – Joshua Moore Oct 15 '14 at 19:36