Forum:  Designer

Thread:  Save credentials for relational model

HcD (User)   Posted on: 22-Nov-2017 10:50:56.

Using LLBLGen 5.1, we have the annoying issue that we have to enter the password in the "Relational Model Data Retrieval Wizard" dialog, every time we want to refresh our model from the database when we "Sync Relational Model Data"

Is there a setting to save this pasword in the LLBLGenProj file ? I know there is a placeholder for this password, because when I edit the llblgenproj xml file in notepad and set the password in the
<ConnectionElement Name="Password" Value="mypassword" />
, then the next time in the wizard, the password is pre-filled. But after syncing, regenerating and saving the llblgenproj file, the password is again empty ....

It would be great if there was a setting to choose to persist the password.

Kind regards,
Otis (LLBLGen Pro Team)   Posted on: 22-Nov-2017 14:47:24.
The password specified is never saved, as it's a security issue (the file is plain text after all). We could encrypt it with an embedded key, which isn't that great either, as it's easy to hack it out. Any other ideas for this? I know an option to persist it would make it the responsibility of the user, but we all know how these things go: one person sets the setting, password gets persisted, it is forgotten after a while and then misused by another person who read the file contents.

I don't know if it's possible to map a windows user to a DB user in the database you're using, e.g. in Oracle and SQL Server (and I also think in DB2) this is possible. This means you can define a windows user, and in the DB this is mapped to the db user you'd otherwise use. The advantage is that you can then use the windows login, which doesn't require a password in the dialog.

HcD (User)   Posted on: 22-Nov-2017 15:08:04.
I completely understand it should not be saved by default, but an option would be nice. We recently decided to put our dev db in AzureSQL instead of a local SQL server.
We have created a specific account for connecting llblgen with that DB, and these account credentials are shared amonst our devs. The problem is that this password HAS to comply with the complexity rules of AzureSQL (which cannot be turned off), thus it's a password which is long and complex.
So in practice, we each have the password in a textfile on the desktop, and copy paste it in the dialog when we need it.

It would be so much more convenient to save it in the llblgenproj file. (and the placeholder is already there in the xml), and imho, not a lot less secure that having the pwd in a plaintext file on the desktop ...

Otis (LLBLGen Pro Team)   Posted on: 23-Nov-2017 09:57:58.
That's true indeed... And a windows domain user is of course then also out of the question.

Ok, we'll think of something. If our measures are resulting in post-its with the password on a monitor (paraphrasing) then they've obviously failed as well Wink

HcD (User)   Posted on: 23-Nov-2017 10:10:33.
Super, thnx !! Regular Smiley

jovball (User)   Posted on: 19-Dec-2017 01:44:30.
Ummm. This seems like a bad idea to me and likely to be abused by people who don't have your use case. Your credential is going to end up in source control among other things.

It's true that what you are doing now isn't the best idea either. You'd be better off using a password vault of some kind. I'd suggest KeePass, it's free and secure. Certainly there are multiple software options in this space.

Otis (LLBLGen Pro Team)   Posted on: 19-Dec-2017 10:07:59.
Thanks Joel for the feedback / insight Regular Smiley We'll take it into account when we're looking at this feature and whether we decide to implement something or not.
Otis (LLBLGen Pro Team)   Posted on: 12-Feb-2018 12:04:54.
As we can't guarantee security even if we encrypt it (as the encryption key is in the IL which is easily decompiled) and if we add an option and the user enables it, they'll blame us for weak encryption that's easy to hack, so we won't implement this.

The suggestion to use KeePass (or lastpass or 1password or other options) is a better one.