El 12/07/2016 a las 21:39, Graeme Geldenhuys escribió:
> No, but why the hell would you want to hard-code a password inside an
> executable. Encrypt it externally and read it from a .INI file at
> runtime (or prompt for a password). Even something as simple as
> XorString() is better than nothing - compared to storing it inside your
> source code.
>
> Regards,
> Graeme
Well, if you don't prompt the password, where do you store the password
to decrypt the externally encrypted password? ;-)
Whenever you try to hide something without storing the password in
user's brain you are just ofuscating. A hard coded password is just
another way of ofuscating strings, but with a higher level of ofuscation.
My solution to store passwords was to store de password in a .INI file
(i.e. user doesn't want to type the password, wants the program to
remember it).
The connection password was encrypted with a hard-coded password and
stored in base64 in the in file.
i.e.
implementation
Const _Password='48-49-50'; // hardcoded ofuscated 123, so in resources
it is not plain
function unofuscate(s):string;
begin
.....
end;
procedure LoadData;
begin
....
IniPassword:=unofuscate(_Password);
ConnectionPass:=SimpleDecrypt(Base64Decode(ini.ReadString('connection','pass','')),IniPassword);
....
end;
I always declared the password in the implementation section, (don't
know where I read that that way there is not a recognizable symbol
"_Password"), if I had to use it in several places, I used ($include
pass.inc}
My ofuscate function was a little more complex, and but anyway, any
system that stores passwords without human intervention is inherently
insecure.
Well, it was long time ago.
--
Saludos
Santiago A.
s...@ciberpiula.net
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
