|
Based on this question, I would like to ask whether there are plans to change the way passwords are stored in ODBC DSNs. Since many versions, when creating user or system DSNs under Windows, passwords are stored in plain text (when storing them not "encrypted", aka as PWD parameter) or in obfuscated form (when storing them "encrypted", aka as ENP parameter). It's easy that way to un-encrypt an "encrypted password", as discussed in the question. Although the docs warn that storing passwords (in either way) is not recommended, I guess the ODBC configuration UI does evoke the impression a real encrypted storage was supported. Therefore I would suggest to add a facility that does store them in a "better" way. I'm aware that it's technically impossible to store a password in a non-breakable fashion, and that the final recommendation will always be to not store passwords at all. Nevertheless, I guess it's not that uncommon to store them (for example with databases that use their own user-management and connect all users with the same database user). Here, a more secure way to store passwords (say, with the help of the Windows DPAPI or the like - as DBFHide v12 seems to use) might be helpful. As said, that would not be perfectly secure - but it could omit the current misleading (and reversable) "encrypted" storage. |
|
I just came over CR note 773529 that makes me think fitting improvements have been made with v16.0.0.2041 (but not for v12) - to cite from that long description:
|
|
I discussed this topic with a few others while investigation this question and the general opinion was that at best we should have never allowed the ability of getting the plain text from the "encrypted" ENP value (i.e. I considered this a bug but since the code is out there that already allows this there is no sense in making a fix) - this would have provided some limited value. Since no method of protecting the password exists without requiring a key to unlock the protected value, there is little sense in implementing yet another method that doesn't really provide any protection. Storing your password in a text file and using v12's dbfhide on the file (using -w or -wm options) will provide the best level of protection. But please note that even using -w or -wm options does not completely make the contents of the "hidden" file inaccessible since the original file contents can still be retrieved without the use of a key - the file protection is only as good as the protection provided by Windows' encryption API! I.e. there are currently no plans to implement any new method of storing passwords. I appreciate your answer and agree on the thoughts. - The one disadvantage of DBFHide seems that it can't be used for client connections, right?
(01 Aug '11, 05:21)
Volker Barth
@Mark: Just to clarify: There's no way to use DBFHide (and configuration files) with client connections (besides the database tools and DBISQL), right?
(14 Aug '11, 17:04)
Volker Barth
Replies hidden
1
You can create a file DSN and use dbfhide to hide the file, and then use the FileDSN connection parameter.
(19 Aug '11, 17:19)
Graeme Perrow
Wow, I wasn't aware of that possibility at all. Guess I have to repeat it as a separate question to get the focus on that nice facility:)
(21 Aug '11, 15:22)
Volker Barth
|
