|Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread|
|Messages 11 to 13 of 13 total|
|Hiding the password to the password|
|Tue, Mar 17 2009 10:47 AM||Permanent Link|
Yup and I'll have a test this weekend.
|Thu, Mar 19 2009 4:55 PM||Permanent Link|
Actually this just compresses the exe - it does not technically encrypt
You can also run "upx -d <your compressed exe>" and you have your original
A better solution might be something like this :
It costs money though if used on commercial apps and i have no idea how good
the protection actually is - caveat emptor
"Rita" <email@example.com> wrote in message
> Try this freebie it encrypts the exe that
> holds your password to the passwords.
> FREE FREE FREE FREE LIKE ZILCH NOWT BUGGER ALL COST
> "Roy Lambert" <firstname.lastname@example.org> wrote in message
>> Now (with much help) that I have got Tim's blowfish encryption working
>> I'll be creating a key to the app that will contain (amongst other stuff)
>> the allowed number of simultaneous users and the encryption key to some
>> of the tables (I'm only going to encrypt tables with personal data) I
>> need a place to hold the password used to encrypt/decrypt this
>> Where do you suggest, in the program files, that it is hidden?
>> Roy Lambert
|Tue, Apr 21 2009 11:03 AM||Permanent Link|
I guess I'll throw in my 2 cents worth too.
I don't know much about blowfish, but have worked with AES here and =
there--I'm very far from being an AES whiz bang though. I've never came =
up with a good solution really.
a.. If the same private key is used for encrypting a table or entire =
db, and the key is discovered all of the data is exposed with next to no =
b.. Best practice is to use a private key per record or per user and =
not per DB per table or per app. The larger the number of users and =
records the harder it becomes for a brute force/dictionary attack
c.. Keep the SALT private because if that's exposed, the attacker =
would have a significantly easier time getting to the data
d.. Where to keep the private key? Keep it per machine? Means if the =
user launches from another machine the data won't decrypt. Per user? Not =
sure how unless roaming profiles are used. Don't want to keep it in the =
DB cuz if someone grabs the files, there goes the private key, so that's =
a lousy idea. Bury it with the app? Don't want to do that because if =
they grab the files & DB the private key is exposed here as well.=20
e.. Put the private key in a file on the OS? Anything like FileMon =
will show what files are being accessed.The file can be grabbed then.
f.. Maybe (just maybe?) putting the private keys on a secure file =
servers if the app is used interally in an enterprise might work and =
restrict access to them via NTFS permissions in AD.
g.. Create some seemingly clever (complex/complicated?) method to =
create the salt or hide the private keys is writtend by security experts =
as beeing weak because a hacker can work around that without breaking =
into a sweat
h.. Generally, for plain passwords a 1 way encryption is OK (perhaps =
MD5 or SHA1). Encrypt it, save it, encrypt the passwords entered by =
users so only the encrypted PW gets compared. The original can't be =
retrieved and doesn't need to be.
i.. Another valid way might be to leverage the certificate stores of =
the Windows OS. That'd contain the private & public keys needed and =
expire them when necessary. I don't know what's involved with creating =
certs and using them in a .Net app with EDB, but .Net does support them. =
Depending on your implementation, I don't know how to tie that to EDB. I =
think this may be the most secure but probably takes the most amount of =
work if I were to take a guess. If the enterprise running/purchasing =
your app has an internal certificate server as part of AD, that could be =
used to manage the cert requests & certs.
I don't know what the best or most practical way is to secure the =
private keys & SALTs, but they can not risk being discovered. Odds are =
we are not as clever as a hacker would be.
>>> Now (with much help) that I have got Tim's blowfish encryption =
>>> I'll be creating a key to the app that will contain (amongst other =
>>> the allowed number of simultaneous users and the encryption key to =
>>> of the tables (I'm only going to encrypt tables with personal data) =
>>> need a place to hold the password used to encrypt/decrypt this=20
>>> Where do you suggest, in the program files, that it is hidden?
>>> Roy Lambert
|« Previous Page||Page 2 of 2|
|Jump to Page: 1 2|