![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 21 to 30 of 43 total |
![]() |
Thu, Aug 25 2016 11:55 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 |
Thu, Aug 25 2016 12:12 PM | Permanent Link |
Matthew Jones | 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 |
Thu, Aug 25 2016 12:13 PM | Permanent Link |
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 |
Fri, Aug 26 2016 3:02 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Matthew
Just for a bit of fun http://www.theregister.co.uk/2016/08/25/us_bank_breaches_survey/ Roy Lambert |
Fri, Aug 26 2016 10:08 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Fri, Aug 26 2016 10:13 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Fri, Aug 26 2016 10:39 AM | Permanent Link |
Matthew Jones | 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 |
Fri, Aug 26 2016 1:19 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 |
Sat, Aug 27 2016 3:46 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 |
Sat, Aug 27 2016 3:51 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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 |
« Previous Page | Page 3 of 5 | Next Page » |
Jump to Page: 1 2 3 4 5 |
This web page was last updated on Saturday, June 22, 2024 at 05:51 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |