Recent

Author Topic: Security Question  (Read 104275 times)

goodname

  • Sr. Member
  • ****
  • Posts: 297
Re: Security Question
« Reply #15 on: July 27, 2012, 04:03:39 pm »
Personally, I would hash the encryption key and store in a separate file and hide the file path string in the application.
How do you propose making it difficult for someone to reverse engineer your program and discover the path embedded in your application?

BigChimp

  • Hero Member
  • *****
  • Posts: 5740
  • Add to the wiki - it's free ;)
    • FPCUp, PaperTiger scanning and other open source projects
Re: Security Question
« Reply #16 on: July 27, 2012, 04:13:59 pm »
Personally, I would hash the encryption key and store in a separate file and hide the file path string in the application.
How do you propose making it difficult for someone to reverse engineer your program and discover the path embedded in your application?
I'd like to start with this remark: once somebody has physical access to a machine running your code it's game over as far as absolute security is concerned. The only thing that remains is how hard it is to crack.

I'd say obfuscating the path where the key is (and its decryption, if it is encrypted) is more or less the same problem as obfuscating a hardcoded encryption key in the program itself.
Of course, you can find out the path where the key is stored by running a tool such as process monitor or strace or similar tools... dealing with the contents of that file is another matter.

Want quicker answers to your questions? Read http://wiki.lazarus.freepascal.org/Lazarus_Faq#What_is_the_correct_way_to_ask_questions_in_the_forum.3F

Open source including papertiger OCR/PDF scanning:
https://bitbucket.org/reiniero

Lazarus trunk+FPC trunk x86, Windows x64 unless otherwise specified

Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #17 on: July 27, 2012, 05:13:42 pm »
Otherwise, by which ever mechanism starts an application, usually a scheduler, the password is put there, and never with the code.

When a password is found in an isolated environment, with no mention as to where it applies, there, it is comparable as to if someone finds your carkeys somewhere, but there is no tag to relate it to the user or object that it opens. The password, additionally, could be in a usbstick, or for that matter, almost any where (somewhat like having a dongle).
So your saying that the data should be in a separate file, registry, dongle, ... The separation makes it hard to associate with the program that uses it. This is security by obscurity. Just a different approach to doing the obscurity.

No.

This is not security by obscurity. What I explained is Visible Security, provided by a datatabase engine.

You asked about when a program is to be started with no user, and for that, if you have to use an unencrypted password, you put it in a separate place, if you want to.  Up to you. Also up to how a program is to be run if it is to be run by scripts, or schedulers. Those could have their own means to encrypt/decrypt passwords.

However, when running scheduled scripts, though much of the protection comes from the operating system user account. You run your script (scheduled) from a directory that only you have access to, for instance. If you wanted too, you can create scripts that delete themselves after termination.




goodname

  • Sr. Member
  • ****
  • Posts: 297
Re: Security Question
« Reply #18 on: July 27, 2012, 06:45:24 pm »
A database can not secure the login information. It is all about  how hard is it to get at this information. It does not matter if you call it obscure or visible it is all about difficulty level.

Techniques to increase the difficulty level for embedded are described in this thread. To crack this requires some reverse engineering of the binary file.

To place it in a separate location could just require
process monitor or strace or similar tools...
which might actually be easier.


Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #19 on: July 28, 2012, 12:35:03 am »
A database can not secure the login information. It is all about  how hard is it to get at this information. It does not matter if you call it obscure or visible it is all about difficulty level.

Techniques to increase the difficulty level for embedded are described in this thread. To crack this requires some reverse engineering of the binary file.

To place it in a separate location could just require
process monitor or strace or similar tools...
which might actually be easier.

Goodname,

Databases secure billions of dollars for businesses, and also of critical and not critical data, for you and anyone else, whatsomore a login password.

Here is the word "password" encrypted, shown as plain text:
AD20F1E9B39B714491C3095C2ABD7F1E
using a crappy password to encode it.

WHAT "reverse engineering" could you apply to decode it?

And, here is the same word "password" encrypted typing a 32 character password:
573E45698F6B00C43C7B35A98B8BD852

They are both the same length.

Therefore, the amount of security does not necessarily relate to "difficulty", as you say.

There are no "absolutes" in any thing.

Most security failures are due to negligence.

And, for diligence, there is always brute force.

Yet, nothing is guaranteed as to safekeeping, be it for protecting or for the other way around.

The best security, though, is VISIBLE security, so far. Both in the world of real objects, or in the world of information management.

In both worlds,  many choices are there, likewise.




ezlage

  • Guest
Re: Security Question
« Reply #20 on: July 28, 2012, 12:50:09 am »
My friends,

My case is a lot specific:

A- My program is a finance manager (hot target for malicious people)
B- Portable, runs at usb disks (pendrives)
C- Because of portability, the database needs to be local (I'm using DBF)
D- Table files won't be stored in disk while decrypted (in TMemoryStreams)
E- The DBF's engine doesn't support encryption, so I can load it in memory and store it encrypted in disk
F- I'm thinking about encryption by user key, but if user lost the password, will be impossible to recover data
G- If I store keys in a separated file, is so easy to find it (search by creation date, modification date and so many ways, too, I will lost the portability)

I implemented many protections (against AutoIt, O'Matic, brute force [with temporized login, changing the memory addresses, etc], capturing coordinates of clicks, changes in executable file, etc, etc, etc), but with storing cryptographic keys I'm not doing a good job.

So, have anyone more ideas that can help me?
Suggestions that can help me with another protections?

Thank all of you!
Sorry by my poor english.

Regards,
Ezequiel Lage

Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #21 on: July 28, 2012, 01:16:02 am »
My friends,

My case is a lot specific:

A- My program is a finance manager (hot target for malicious people)
B- Portable, runs at usb disks (pendrives)
C- Because of portability, the database needs to be local (I'm using DBF)
D- Table files won't be stored in disk while decrypted (in TMemoryStreams)
E- The DBF's engine doesn't support encryption, so I can load it in memory and store it encrypted in disk
F- I'm thinking about encryption by user key, but if user lost the password, will be impossible to recover data
G- If I store keys in a separated file, is so easy to find it (search by creation date, modification date and so many ways, too, I will lost the portability)

I implemented many protections (against AutoIt, O'Matic, brute force [with temporized login, changing the memory addresses, etc], capturing coordinates of clicks, changes in executable file, etc, etc, etc), but with storing cryptographic keys I'm not doing a good job.

So, have anyone more ideas that can help me?
Suggestions that can help me with another protections?

Thank all of you!
Sorry by my poor english.

Regards,
Ezequiel Lage

You can save your password in one or more emails to yourself, in one or more e-mail accounts.

You can save it either encrypted or unencrypted, too.

Also, there are usb sticks that come with their own data-encryption schemes, so that if lost, no one should be able to read the contents.

They are readily available.

Knipfty

  • Full Member
  • ***
  • Posts: 232
Re: Security Question
« Reply #22 on: July 28, 2012, 04:43:45 am »
ezlage,

I always look at what others have done before embarking on a new adventure.  Usually, I find that someone has traveled down my path and solved my problem for me.

Take a look at Trucrypt.  It can fully protect your USB drive.  Trucrypt can use a password or key file or both to secure the USB drive (really any drive).  This is heavy duty encryption.  I use on my laptop.  It's also an Open Source project.

Your program can then control access to the DBF files with another password or the same password.  The key here is that your data will be very secure will encrypted.  If someone grabs the USB drive, they will find it useless.  Even if it was decrypted during a session since the data is always encrypted on the USB drive and only decrypted when read into memory.

This may be your nest bet.

Knipfty

PS.  Your English is fine  :)
64-bit Lazarus 2.2.0 FPC 3.2.2, 64-bit Win 11

goodname

  • Sr. Member
  • ****
  • Posts: 297
Re: Security Question
« Reply #23 on: July 28, 2012, 02:50:48 pm »
Here is the word "password" encrypted, shown as plain text:
AD20F1E9B39B714491C3095C2ABD7F1E
using a crappy password to encode it.

WHAT "reverse engineering" could you apply to decode it?

And, here is the same word "password" encrypted typing a 32 character password:
573E45698F6B00C43C7B35A98B8BD852

The actual connection string that is sent by your application does not contain AD20F1E9B39B714491C3095C2ABD7F1E or 573E45698F6B00C43C7B35A98B8BD852. These would be rejected as they are not the password. Your application must convert the encrypted string to the actual password. The reverse engineering would be finding the encrypted passwords in your external location and the key the application uses for decryption.

Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #24 on: July 28, 2012, 08:01:30 pm »
Here is the word "password" encrypted, shown as plain text:
AD20F1E9B39B714491C3095C2ABD7F1E
using a crappy password to encode it.

WHAT "reverse engineering" could you apply to decode it?

And, here is the same word "password" encrypted typing a 32 character password:
573E45698F6B00C43C7B35A98B8BD852

The actual connection string that is sent by your application does not contain AD20F1E9B39B714491C3095C2ABD7F1E or 573E45698F6B00C43C7B35A98B8BD852. These would be rejected as they are not the password. Your application must convert the encrypted string to the actual password. The reverse engineering would be finding the encrypted passwords in your external location and the key the application uses for decryption.

Hi goodname,

I am curious why would you or anyone have to reverse engineer any thing, since the program that created this password is open source, both for encrypting AND decrypting?

This one I did with PGP (Pretty good privacy) and it is used by e-mails, databases; you name it.

The  OpenPGP standard (RFC 4880) is available since the early 90's.

In fact, most data encryption algorithms are public knwowledge, usually found in technical journals, such as the ACM, the IEEE, or if not in patents, which are also public information.

goodname

  • Sr. Member
  • ****
  • Posts: 297
Re: Security Question
« Reply #25 on: July 28, 2012, 09:37:11 pm »
The reverse engineering is done on the distributed binary application to find the encryption key that is used, not the encryption algorithm. Anyone that has the key can use their own copy of PGP or OpenPGP to do the decrypting.

This thread started because someone wanted to hide the encryption key used in their distributed binary application from a disassembler or hex editor.

Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #26 on: July 29, 2012, 05:14:02 am »
The reverse engineering is done on the distributed binary application to find the encryption key that is used, not the encryption algorithm. Anyone that has the key can use their own copy of PGP or OpenPGP to do the decrypting.

This thread started because someone wanted to hide the encryption key used in their distributed binary application from a disassembler or hex editor.

No, goodname.

Cracking is not done using "reverse engineering" of any binaries of distributed applications, because, as said, applications for encrypting/decrypting are based on algorithms that are already public knowledge.

Cracking is done by attacking first with weak passwords that are already in dictionaries, and also with the whole dictionary of words, and mixtures or variations. Then brute force is tried, but it is not totally brute force, since some judgement is still made. Pure brute force could take zillions of years to find the password, according to cryptology.

What you say about Pretty Good Privacy about "anyone that has PGP" is not quite right either, because it is the "server" that does the decrypting with an established (not by PGP) PRIVATE key, that is not known to the client. The Private Key is set by admininstrator, and the Public Key, the whole world can have. In addition, PGP generates a random, one-time only key.

In addition, compression is used at the local level, before encryption.

As you might want to see, working on binaries is the wrong aproach to wanting to crack passwords, when professional/academic, and commercial  level encryption is enforced.

If someone invents his own personal encryption based on the executable code, then, of course, you would be right, and cracking the binary would be the task, which probably would not be too difficult for an experienced cracker.

Of course, there are various other means of stealing passwords, such as trojans, or viruses.

BigChimp

  • Hero Member
  • *****
  • Posts: 5740
  • Add to the wiki - it's free ;)
    • FPCUp, PaperTiger scanning and other open source projects
Re: Security Question
« Reply #27 on: July 29, 2012, 10:25:25 am »
If passwords/encryption keys are processed by an application (using whatever algorithm), disassembling that application is a valid attack vector to get to that key, either by figuring out how the key is obtained and what format it is in in order to get access to it (e.g. if the key is stored in a file, or the executable itself, whether obfuscated or not) or as a first step to modifying the application (e.g. by patching the binary) in order to leak the key when it is entered (e.g. coming from user input).
Want quicker answers to your questions? Read http://wiki.lazarus.freepascal.org/Lazarus_Faq#What_is_the_correct_way_to_ask_questions_in_the_forum.3F

Open source including papertiger OCR/PDF scanning:
https://bitbucket.org/reiniero

Lazarus trunk+FPC trunk x86, Windows x64 unless otherwise specified

Elmug

  • Hero Member
  • *****
  • Posts: 849
Re: Security Question
« Reply #28 on: July 29, 2012, 05:36:41 pm »
If passwords/encryption keys are processed by an application (using whatever algorithm), disassembling that application is a valid attack vector to get to that key, either by figuring out how the key is obtained and what format it is in in order to get access to it (e.g. if the key is stored in a file, or the executable itself, whether obfuscated or not) or as a first step to modifying the application (e.g. by patching the binary) in order to leak the key when it is entered (e.g. coming from user input).

That's why we said since the beginning that for applications that need passwords, they should not be stored as part of the application, and that a database is the recommended place to store not only the password, but also the data being safeguarded.

BigChimp

  • Hero Member
  • *****
  • Posts: 5740
  • Add to the wiki - it's free ;)
    • FPCUp, PaperTiger scanning and other open source projects
Re: Security Question
« Reply #29 on: July 29, 2012, 06:00:48 pm »
If passwords/encryption keys are processed by an application (using whatever algorithm), disassembling that application is a valid attack vector to get to that key, either by figuring out how the key is obtained and what format it is in in order to get access to it (e.g. if the key is stored in a file, or the executable itself, whether obfuscated or not) or as a first step to modifying the application (e.g. by patching the binary) in order to leak the key when it is entered (e.g. coming from user input).

That's why we said since the beginning that for applications that need passwords, they should not be stored as part of the application, and that a database is the recommended place to store not only the password, but also the data being safeguarded.
And how do you secure the password to the database?
Want quicker answers to your questions? Read http://wiki.lazarus.freepascal.org/Lazarus_Faq#What_is_the_correct_way_to_ask_questions_in_the_forum.3F

Open source including papertiger OCR/PDF scanning:
https://bitbucket.org/reiniero

Lazarus trunk+FPC trunk x86, Windows x64 unless otherwise specified

 

TinyPortal © 2005-2018