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.

asked 30 Jul '11, 16:44

Volker%20Barth's gravatar image

Volker Barth
accept rate: 32%

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:

Encrypted password support has been enhanced with the following goals in mind:

  • Ability to restrict use to a particular computer or a particular computer/user.
  • Inability to reverse-engineer an encrypted password using the ODBC Configuration for SQL Anywhere dialog.
  • Better encryption algorithms to ensure that the encrypted password cannot be decrypted.
  • These enhancements to be available across all supported client platforms.
permanent link

answered 06 Jan '15, 08:01

Volker%20Barth's gravatar image

Volker Barth
accept rate: 32%

edited 06 Jan '15, 08:13

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.

permanent link

answered 31 Jul '11, 21:14

Mark%20Culp's gravatar image

Mark Culp
accept rate: 40%

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

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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 30 Jul '11, 16:44

question was seen: 2,007 times

last updated: 06 Jan '15, 08:13