How secure from hacking is confidential data (decrypted from an encrypted file) that has been loaded into an array for processing? If vulnerable, are there steps that can be taken to protect such data from hacking while working with it unencrypted (assuming that it is always encrypted when saved to storage media)?
FiveTech Support Forums
FiveWin / Harbour / xBase community
Board index FiveWin for Harbour/xHarbour Security of array data
Roger
I am not a forensics expert .. however, I think it would be EXTREMELY difficult if not downright technically challenging for a ( potential ) compromised workstation 'crook' to re-assemble 'active' bytes in memory ( or disk swap ) from an array in comparison to a file in a 'saved' users \temp folder... In this particular case.. I don't think the ( crooks ) juice would be worth their 'squeeze'
That is just my opinion..
Rick Lipkin
Thanks Rick,
Coming from you, that is reassuring.
- Roger
Roger,
Why do you think that a hacker could have some interest in reviewing that computer ? Will the hacker have access to it ?
Inspecting the memory is possible and it works. With little technical preparation it is possible to go that far, but the hacker may need full access to the computer. If that is the case, I would say to keep the data encrypted and just decrypt it for a moment when it is going to be used, but don't keep it decrypted in memory.
Softice, a software that is still around allows you to do it. Surely there may be others tools.
Hi Roger;
If the hacker already has access to the workstation, then there is little you can do about it from your harbour executable. However, there are things you can do with the os (Windows) to avoid the workstation from running anything else but your .exe -including lowering the user's permissions to very litle. I think that's where you want to focus your efforts.
Reinaldo.
Reinaldo,
Is it possible to set Windows permissions so that the DBF can be modified and deleted only by the EXE and not by users?
EMG
reinaldocrespo wrote:However, there are things you can do with the os (Windows) to avoid the workstation from running anything else but your .exe -including lowering the user's permissions to very litle.
Is it possible to set Windows permissions so that the DBF can be modified and deleted only by the EXE and not by users?
EMG
EMG;
No. You are right. (1) But you can set windows to auto-log as a given user, set the user permissions to auto-run your .exe, deny the user permissions to run the start menu, deny the user permissions to run cmd prompt, deny modifying the desktop, deny running ie, deny read/write from all directories except the dir with your .exe. etc... Have the workstation reboot if the .exe is terminated.... In short, the workstation is only good to run your .exe. Therefore it becomes a lot harder to execute any tool/utility to read the binary contents on RAM, and that was the original question.
(2) As far as closing access to your .dbfs -here is an idea -you could have your .dbfs on a server on a directory that is NOT shared. Make the directory belong to the user system, and deny access to any other user. That makes the .dbfs only visible/read/write to the "system" user on the server. Have the user system run a service that listens on port xxx for data requests. Have your app only speak to the server's ip through port xxx. Any data request is actually served by the service owned by the "System" user running on the server. This makes your .dbfs only visible to your .exe.
That's, in short, how ADS does it. ADS is a service running on the server, the ADS rdd simply replaces any data call (dbseek, skip, etc....) for requests to the service. It is transparent to the programmer, but you get to have your .dfs hosted on a server directory that is NOT shared and thus only your .exe has access to the .dbfs. Since the .dbfs are not on a shared directory you can not open a command prompt copy/delete a .dbf. The directory containing data is only visible to the "system" user on the server. That is only one of the reasons I switched to ADS over 10 years ago. I needed to secure my .dbfs from users trying to steal data, un-intentionally, or otherwise- deleting .dbfs, and simply making the database more stable and secured. In my apps, the .dbfs (I have now switched to .adts), are only visible to my apps. Users can not read/write or even see the files.
Hope that helps some,
Reinaldo.
Reinaldo,
EMG
reinaldocrespo wrote:No.
EMG
To All
I do not think there is a good answer here ... all that we can hope to achieve as developers is 'do diligence' as in encrypting our data. I know that many SC State Agency's have almost turned 'paranoid' after the SC Dept of Revenue hack to the point of not allowing any employee access to the internet 'period' at their workplace.
http://www.thestate.com/2012/10/26/2496 ... ivacy.html
I think we live in world where cyber crime is now a 'cost of doing business' .. lets face it .. If an employee makes a bad choice in downloading an attachment from their e-mail, or clicks on a link that re-directs them to a 'booby trapped' website that compromises their machine with malicious software or a 'key logger' .. there is nothing we can do as developers to stop that.
As developers we can not be responsible for the poor judgement of users that infect their machines .. what needs to be done to ( help ) eliminate the potential from being 'hacked' from the 'outside' is to be able to 'STOP' download requests at the infrastructure level .. from the gateways and routers of our companies and to be able to isolate outgoing packet traffic to suspicious IP addresses which alerts the IT staff a particular machine may be compromised... and that is only a partial answer.
Focus our efforts at the infrastructure level along with data encryption of our applications.. that is all we can do unless we adopt the use of Linux.. but given enough time an resources, cyber thieves will probably hack that OS as well.
Rick Lipkin
I do not think there is a good answer here ... all that we can hope to achieve as developers is 'do diligence' as in encrypting our data. I know that many SC State Agency's have almost turned 'paranoid' after the SC Dept of Revenue hack to the point of not allowing any employee access to the internet 'period' at their workplace.
http://www.thestate.com/2012/10/26/2496 ... ivacy.html
FINDINGS
Mandiant’s major findings are provided below.
Summary of the Attack
A high level understanding of the most important aspects of the compromise are detailed below.
1.August 13, 2012:
A malicious (phishing) email was sent to multiple Department of Revenue employees. At least one Department of Revenue user clicked on the embedded link, unwittingly executed malware, and became compromised. The malware
likely stole the user’s username and password. This theory is based on other facts discovered during the
investigation; however, Mandiant was unable to conclusively determine if this is how the user’s credentials were
obtained by the attacker.
I think we live in world where cyber crime is now a 'cost of doing business' .. lets face it .. If an employee makes a bad choice in downloading an attachment from their e-mail, or clicks on a link that re-directs them to a 'booby trapped' website that compromises their machine with malicious software or a 'key logger' .. there is nothing we can do as developers to stop that.
As developers we can not be responsible for the poor judgement of users that infect their machines .. what needs to be done to ( help ) eliminate the potential from being 'hacked' from the 'outside' is to be able to 'STOP' download requests at the infrastructure level .. from the gateways and routers of our companies and to be able to isolate outgoing packet traffic to suspicious IP addresses which alerts the IT staff a particular machine may be compromised... and that is only a partial answer.
Focus our efforts at the infrastructure level along with data encryption of our applications.. that is all we can do unless we adopt the use of Linux.. but given enough time an resources, cyber thieves will probably hack that OS as well.
Rick Lipkin
Antonio,
Sorry that I overlooked your questions to me a couple of months ago that I just rediscovered here upon review...
I have a customer that requires that the names and addresses in the dbf be encrypted, but yet requires that the user be able to search the database by name and address. Doing a search efficiently would seem to require indexes, but indexing on encrypted fields would be meaningless. So I thought I could create a simulated index by decrypting Lastname+Firstname into one element of an asorted array, and put the related RECNO() as nRecno in a second element of the array - creating this array based on the whole dbf. The user would search the array for the lastname+firstname, and if found, the nRecno would be used to access the correct record - using the array like an index. Then the record would be decrypted for display. So I was asking here just how secure this array containing decrypted data would be in memory. It seems to be secure enough for my customer's purposes.
All the best,
- Roger
Sorry that I overlooked your questions to me a couple of months ago that I just rediscovered here upon review...
Why do you think that a hacker could have some interest in reviewing that computer ? Will the hacker have access to it ?
I have a customer that requires that the names and addresses in the dbf be encrypted, but yet requires that the user be able to search the database by name and address. Doing a search efficiently would seem to require indexes, but indexing on encrypted fields would be meaningless. So I thought I could create a simulated index by decrypting Lastname+Firstname into one element of an asorted array, and put the related RECNO() as nRecno in a second element of the array - creating this array based on the whole dbf. The user would search the array for the lastname+firstname, and if found, the nRecno would be used to access the correct record - using the array like an index. Then the record would be decrypted for display. So I was asking here just how secure this array containing decrypted data would be in memory. It seems to be secure enough for my customer's purposes.
All the best,
- Roger
Roger,
the best option for u customer ADS. 5 minuts of work and the best solution for encripted dbf
Salutacions, saludos, regards
"...programar es fácil, hacer programas es difĂcil..."
UT Page -> https://carles9000.github.io/
Forum UT -> https://discord.gg/bq8a9yGMWh
HIX -> https://github.com/carles9000/hix
"...programar es fácil, hacer programas es difĂcil..."
UT Page -> https://carles9000.github.io/
Forum UT -> https://discord.gg/bq8a9yGMWh
HIX -> https://github.com/carles9000/hix