tracker issue : CF-3754573

The encryption is only to be safe in case of any intrusion. It wont be portable across CF servers anyway. We can provide something in the admin to get the encrypted password and put it in code but that's also not for people who dont have access to admin. (These are the people who will actually use this).

Comment by Himavanth R.

The sole reason for adding this functionality was to make it easy for the frameworks to define the datasources from within the framework without going through the administrator. If one has to go through the administrator to get the encrypted password, that defeats the whole purpose. You can very well keep it defined there. So why define it in the application at all? As far as the railo approach is concerned, I don't know the details of their implementation. As Hima said, after putting the encrypted string, your code would not be portable because encryption will be installation specific. In case they are claiming the encrypted string is portable, it would mean that they are encrypting it with a static key same across all installation which is not at all a secure practice. Now we are not saying that you keep the password in the plain text format in your source. You can very well keep the password in encrypted form on the disc and decrypt it before passing it to the datasource definition. I don't see any issue in the current approach. IMO, there is nothing to be done here. we can possibly blog about how one should store the password and use it like this.

Comment by Rupesh K.

You're (both) kinda missing the point, in different ways. Firstly, the encrypted password is not supposed to impart Fort-Knox-like security, it's more just so one doesn't have a plain text password sitting there looking at you in the code. When you accidentally type in your password into the wrong field and see it on the screen, don't you feel a bit "wrong"? It's just obfuscation... but it's a lot further along the path to security than having it sitting there in plain text. Secondly, Rupesh, the functionality in Railo Admin is just to generate the code for you; having one that, one deletes the DSN in admin and puts the code in the application. Make sense? I'm slightly annoyed to have to mention this again here because I already said that in the blog article I linked to above. Which you should have read as part of assessing the ticket. However now that I've repeated myself, does that clear that one up? -- Adam

Comment by External U.

I have read the article you talked about and I think you are not getting what Hima or I am trying to say. 1. For putting an encrypted password, you have to get the encrypted string, right? The Railo approach is that you go define the datasource in the admin, get the string, copy and put it in the application.cfc and then delete the datasource from admin. Now, if you already have the access to admin, why would you bother to define in the application.cfc in the first place? The primary usecase for this is for the case when you don't have the access to the administrator. If you are required the access for administrator, the whole purpose for this feature is lost. 2. Putting the encrypted password will make your application unportable. You can not take this application and put it on another server? If Railo is making it run that way, then that encryption is not secure enough. 3. Again as I said earlier, why would you need to have plain text password sitting there in the code? Use a variable which holds the password. The password can come from a file or an encrypted string which you would have decrypted. 4. This is how password is specified in datasource definition for all the languages - be it Java, PHP, or any other language. Java's JDBC api takes the password like this. Does this mean that the JDBC API is badly designed OR java applications are insecure OR java developers need to put the passwords in plain text? No. It is up to the application developers to store the password the way they want.

Comment by Rupesh K.

This would be a huge benefit for those of us who don't have admin rights to their servers and would like to deploy code "the Java way" (via a WAR file, etc). By being able to embed the entire DSN within my application and have the password encrypted, it makes it much easier to give our java admins the pre-packaged WAR files and let them deploy as needed (and not have to do the song and dance of having to give them the WAR, have them deploy, then me go in and set the DSN, etc). I still have a copy of CF locally I develop with -- so I should be able to get the encrypted string with no issue (I just don't always have access to the CF Administrator in production -- esp after following the lock-down guide). We are all aware that the password won't be FIPS secure -- but by having it in the Application.cfc (which you can only access via the filesystem), and using a 2-way encryption, you are reasonably secure with the implementation.

Comment by External U.

This would be a huge benefit for those of us who don't have admin rights to their servers and would like to deploy code "the Java way" (via a WAR file, etc). By being able to embed the entire DSN within my application and have the password encrypted, it makes it much easier to give our java admins the pre-packaged WAR files and let them deploy as needed (and not have to do the song and dance of having to give them the WAR, have them deploy, then me go in and set the DSN, etc). I still have a copy of CF locally I develop with -- so I should be able to get the encrypted string with no issue (I just don't always have access to the CF Administrator in production -- esp after following the lock-down guide). We are all aware that the password won't be FIPS secure -- but by having it in the Application.cfc (which you can only access via the filesystem), and using a 2-way encryption, you are reasonably secure with the implementation.

Vote by External U.

@QueTwo, it would be great if you can go through my note. As I said, you should never keep your password in plain text in the source. You have the complete freedom about how you want to keep your passwords. You can keep it in a config file in encrypted form or encoded form. You can even keep it encrypted in the source and decrypt it while defining the password. You can even keep the encryption key in a file so that it is not hardcoded in the source. You can define the password as password = Decrypt(fileRead('path/to/configfile'), key) //If the password is encrypted Or if it is encoded password = ToString(BinaryDecode(encoded, "Base64")) // If the password is encoded

Comment by Rupesh K.