Matthew


Forgot to mention that for the live system everything has to be typed in. The development system, on the other hand, being a lazy soul I have it programmed into AutoHotKey
Roy Lambert

Roy Lambert wrote:

> It would be a good change but I wonder what the impact on current
> users would be if Tim made that sort of change?

Should be pretty minimal I'd think. A little bit more on the hash for
login, but once connected all as usual. Anyone who is making a new
connection for each interaction is already not concerned with
performance.


> > The signatures
> > are there on the disk in your application
>
> Yes and no - the encryption key is in there but obfusticated in a
> nice difficult to find way, the engine signature isn't. As long as I
> stick to file/server the combination of engine signature/table
> encryption/user passwords/ no direct user SQL input makes it fairly
> secure. Once moved to client/server and the standard ini file which
> holds the engine signature/table encryption key it isn't.

The problem does assume access to the computer hosting the data. Once
someone has access, you can't hide anything (unless you get clever with
money as usual, where the salt and the hash are on separate computers
accessed via APIs, etc etc). If the database computer is all self
contained, and it is in this case, then all the data is there for
someone to dig into. Thus if the best they can get is your hashed
password, that's a "good" result.


--

Matthew Jones

Roy Lambert wrote:

> Forgot to mention that for the live system everything has to be typed
> in. The development system, on the other hand, being a lazy soul I
> have it programmed into AutoHotKey

Likewise. On my dev PC, the admin is auto-logged in using the EDB
Manager facility. For the live computers, I copy to clipboard and then
quickly paste and clear it. The ideal is to copy all but one letter to
the clipboard, and type the last, but if someone is watching my
activity, they already have the server pwned...

--

Matthew Jones

Matthew


Just for a bit of fun

http://www.theregister.co.uk/2016/08/25/us_bank_breaches_survey/

Roy Lambert

Matthew,

Somehow I missed this whole thread.

Yes, EDB stores the passwords as plain-text, but *inside* of the configuration file, which is *always* encrypted.  So, the key here (pardon the pun) is getting physical access to the configuration file, and then knowing the encryption key so that you can decrypt it.  If a hacker has gotten that far, then it would be *nice* to have the passwords hashed so that they aren't plain-text, but that's a little like closing the barn door after the horse has left.

Also, user IDs/passwords are *never* sent in the clear, and are always encrypted when sent over the wire, using a *separate* encryption key from that used for the file encryption.

Having said that, I'll look into making sure that the passwords are hashed, but it will probably be an optional feature and require a configuration file format change.

Tim Young
Elevate Software
www.elevatesoft.com

Roy,

Yeah, Rise of the Hackers covers this right out of the gate:

http://www.pbs.org/wgbh/nova/tech/rise-of-the-hackers.html

Good hackers today don't even bother with trying to hack into a system with code, they simply social-engineer their way into systems enough so that the rest of the actual hacking that does use code has a simple job of getting what they want.  Encrypting data at-rest is a good solution for preventing data leakage, but you've got to keep the encryption keys hidden away somewhere where nobody can find/access them, and that's hard to do when the system itself needs them for decrypting the data.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>  If a hacker has gotten that far, then it would be nice to have the
> passwords hashed so that they aren't plain-text, but that's a little
> like closing the barn door after the horse has left.

Indeed, once someone has access to the physical computer, all bets are
off. But making it as good as it can be is the ideal, and I look
forward to a future update. Knowing nothing about how the file is
formatted etc, I think the "password mode" column which would default
to "plain text" allows it to migrate without breaking anything, other
than not being able to get the plain text password should anyone need
it (the hash being provided instead). Anyway, happy to see you are on
it.

--

Matthew Jones

Matthew,

<< I think the "password mode" column which would default to "plain text" allows it to migrate without breaking anything, other than not being able to get the plain text password should anyone need it (the hash being provided instead). >>

The only downside to any configuration file format change isn't upgrading, which is automatic when the file is read, but rather that after it is updated, it can't be used with earlier versions of EDB.  For that reason, I try to keep such changes to a minimum.

Tim Young
Elevate Software
www.elevatesoft.com

Tim


There's an interesting thread on the Embarcadero newsgroups on this issue which I found quite interesting. Ultimately it seems to boil down to boil down to preventing nasties from finding the "key". I favour machine gun posts and underfed pitbulls!

Roy Lambert

Tim


Another issue is the ini file for EDBManager. What can be done about that apart from not let people use EDBManager or at least don't let them put admin level passwords in ye ini I don't know.

Roy Lambert