Login ProductsSalesSupportDownloadsAbout |
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 |
Roy Lambert NLH Associates Team Elevate | Rita
Yup and I'll have a test this weekend. Roy Lambert |
Thu, Mar 19 2009 4:55 PM | Permanent Link |
"Raul" | Actually this just compresses the exe - it does not technically encrypt
anything. You can also run "upx -d <your compressed exe>" and you have your original exe back. A better solution might be something like this : http://www.bitsum.com/pecompact.php It costs money though if used on commercial apps and i have no idea how good the protection actually is - caveat emptor Raul "Rita" <no@spam.com> wrote in message news:5781EAA7-D7A9-4F86-B3A4-BC84535AA47D@news.elevatesoft.com... > Try this freebie it encrypts the exe that > holds your password to the passwords. > http://upx.sourceforge.net/ > FREE FREE FREE FREE LIKE ZILCH NOWT BUGGER ALL COST > HTH > Rita > "Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message > news:A07601A0-6828-4805-AA19-AA36D2B2677D@news.elevatesoft.com... >> 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 >> information. >> >> Where do you suggest, in the program files, that it is hidden? >> >> Roy Lambert > > |
Tue, Apr 21 2009 11:03 AM | Permanent Link |
"James Relyea" | 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 = effort 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. jr >>> Now (with much help) that I have got Tim's blowfish encryption = working=20 >>> I'll be creating a key to the app that will contain (amongst other = stuff)=20 >>> the allowed number of simultaneous users and the encryption key to = some=20 >>> of the tables (I'm only going to encrypt tables with personal data) = I=20 >>> need a place to hold the password used to encrypt/decrypt this=20 >>> information. >>> >>> Where do you suggest, in the program files, that it is hidden? >>> >>> Roy Lambert >> >>=20 >=20 > |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, March 28, 2024 at 06:05 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |