Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 13 of 13 total
Thread Hiding the password to the password
Tue, Mar 17 2009 10:47 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Rita


Yup and I'll have a test this weekend.

Roy Lambert
Thu, Mar 19 2009 4:55 PMPermanent 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 AMPermanent 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.

Smile
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 PagePage 2 of 2
Jump to Page:  1 2
Image