applications that I use need to be secure and have an audit trail. I encrypt entered passwords, compare them to encrypted stored passwords, ala linux. I am comfortable with that. My concern is relating the authorized user, with their access level to the actual programs. Currently I use the: if choice='A' .and. x=5 .and. y > 3 do the procedure endif where x is theuser's id number and Y is the user's access level. I use fp/dos 2.6. I encrypt my source on compiling. I don't use variable names that are too descriptive. I do other things to keep a program from running on a computer that is not mine.
Any thoughts on a better way to connect the user data with the application?
John
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
I encrypt entered passwords, compare them to encrypted stored passwords, ala linux. I am comfortable with that.
I hope you mean hashed... Encrypting passwords is not a lot more secure than storing passwords unencrypted, especially considering the lack of libraries with modern encryption routines on FP DOS.
Currently I use the: if choice='A' .and. x=5 .and. y > 3 do the procedure endif where x is theuser's id number and Y is the user's access level.
The most common approach for that is to assign users specific rights or roles and then check for those. Hardcoding user ids only works in single installations and is prone to errors after years.
I encrypt my source on compiling.
That doesn't help much, to be honest.
I don't use variable names that are too descriptive.
There are two way. A hard one and an easier one.... The hard one is to actually use non-descriptive variable names in the code. That make it hard to maintain the code. The easy way is to use a DEFINE statement to translate the descriptive name to a non-descriptive name.
Since FP DOS does not support include files, you need to insert the #DEFINE statement at the beginning of the program. A simple program can do this automatically in all of your PRGs within a project.
-- Christof
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
IMO if your data is in DBF files, it's not secure.
Well, nothing is secure, given North Korea has nuclear weapons. But that's not the question, really.
"Secure against what?"
If the curious can read your DBFs in Excel, they may gain information that you have a column named FooBar that holds integer values. If the significance of FooBar isn't obvious unless you have access to unencrypted source code, well, that might qualify as "secure enough."
On Mon, Mar 7, 2016 at 7:43 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
IMO if your data is in DBF files, it's not secure.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
When they open the employee table and can read a SSN is when it gets shaky.
Or open the customer table and make a copy for themselves as they walk off to a new job.
On Mon, Mar 7, 2016 at 7:48 AM, Ted Roche tedroche@gmail.com wrote:
Well, nothing is secure, given North Korea has nuclear weapons. But that's not the question, really.
"Secure against what?"
If the curious can read your DBFs in Excel, they may gain information that you have a column named FooBar that holds integer values. If the significance of FooBar isn't obvious unless you have access to unencrypted source code, well, that might qualify as "secure enough."
On Mon, Mar 7, 2016 at 7:43 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
IMO if your data is in DBF files, it's not secure.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
Want secure ? Don't connect to the net. <s>
On Mon, Mar 7, 2016 at 3:43 PM, Stephen Russell srussell705@gmail.com wrote:
When they open the employee table and can read a SSN is when it gets shaky.
Or open the customer table and make a copy for themselves as they walk off to a new job.
On Mon, Mar 7, 2016 at 7:48 AM, Ted Roche tedroche@gmail.com wrote:
Well, nothing is secure, given North Korea has nuclear weapons. But that's not the question, really.
"Secure against what?"
If the curious can read your DBFs in Excel, they may gain information that you have a column named FooBar that holds integer values. If the significance of FooBar isn't obvious unless you have access to unencrypted source code, well, that might qualify as "secure enough."
On Mon, Mar 7, 2016 at 7:43 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
IMO if your data is in DBF files, it's not secure.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On 3/7/2016 9:43 AM, Stephen Russell wrote:
When they open the employee table and can read a SSN is when it gets shaky.
Or open the customer table and make a copy for themselves as they walk off to a new job.
Or use their smart phone to take a picture of the screen full of sensitive personal data, or company proprietary information. ROFLTIPMP
I used to worry about this a little. But then I saw just how easily any employee that has rights to use an application can compromise data of that application. And it has nothing to do with the underlying technology. Generally speaking, a directed employee attack will succeed to varying degrees of success. "Outside" attacks are the real danger, but are also the most easily blocked (unless of course you're developing brower-based applications.... hahahaha)
Now, of course if you're talking about "direct access" to a database from "anywhere" then, yeah, that's a worry. But then, even all DB servers have security problems (aka SQL Injection etc).
I've found a VFP database on a network share, with managed user access rights, has been quite secure. Sure, if some user is granted rights that shouldn't have it, problems are possible. But then that's a failure of network security processes.
Some things like segregating data inside an application are definitely easier out of the box for DB servers, but I accomplished the same thing in VFP apps by using subfolders <shrug>.
But hey, go ahead and think you're secure just because you're using SQL Server or Oracle... or PostgreSQL... Nowadays technology folks aren't so much about truth as they are about money and lying enough to themselves to sleep at night.
-Charlie
Let me address a few issues:
1) My question was regarding making the software association between the user data in the user database, along with his/her authority level and id, and the executing program.
2) The security issue of my .dbf files is another issue. First, I link some data to other databases, the association being in the program. Secondly, I encrypt certain fields (actually very few-name, etc.). Thirdly, I lock the .dbf so it cannot be accessed by the excels of the world. Finally, I perform non-computer security procedures regarding data security. (How's that for being vague? :) )
I used to compare the entered plaintext password to the decrypted password for authentication. This was back in the 1990's before I learned how Linux does it. What happened is I learned how someone else solves the problem, liked the idea, and use it. I am using the same theory here regarding associating the user data with my program. That is why I showed the simple code that I use. I will not mention my security concern regarding how I associate the data to the program. I am hoping that someone out there will recognize the errors of my ways, and show me a better way to solve it.
I consider security to be a series of chain links. I attack them individually, not as a big blob.
John
On 03/05/2016 03:18 PM, John R. Sowden wrote:
applications that I use need to be secure and have an audit trail. I encrypt entered passwords, compare them to encrypted stored passwords, ala linux. I am comfortable with that. My concern is relating the authorized user, with their access level to the actual programs. Currently I use the: if choice='A' .and. x=5 .and. y > 3 do the procedure endif where x is theuser's id number and Y is the user's access level. I use fp/dos 2.6. I encrypt my source on compiling. I don't use variable names that are too descriptive. I do other things to keep a program from running on a computer that is not mine.
Any thoughts on a better way to connect the user data with the application?
John
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
On 07/03/2016 17:16, John R. Sowden wrote:
Let me address a few issues:
- My question was regarding making the software association between
the user data in the user database, along with his/her authority level and id, and the executing program.
Are you talking about a better way to limit/change which programs that the user is allowed to run? If so I can explain how we do it and that might help.
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715
London Office:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960
Your comment: Yes, that is one area of concern. Is my way best, etc. But my other concern is how the program receives that data of ID and Access Level, and how is that data packaged. Is that process a security risk. My usage is simple and often simple is easy to bypass.
Example: I have 10 security levels. I ID each user from 0 to 9. Maybe that is too simple to avoid tampering. I have 10ish employees, so I have 20 ID 'numbers'. That is also easy to tamper with. These are my concerns.
John
On 03/07/2016 09:33 AM, Peter Cushing wrote:
On 07/03/2016 17:16, John R. Sowden wrote:
Let me address a few issues:
- My question was regarding making the software association between
the user data in the user database, along with his/her authority level and id, and the executing program.
Are you talking about a better way to limit/change which programs that the user is allowed to run? If so I can explain how we do it and that might help.
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email. www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715 London Office:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960
[excessive quoting removed by server]
As has been commented, if you're on dbf's they are inherently insecure (how sensitive is the data? if *very* then migrate to a dbms), but a clear-text userId hashed and used as an index against a file of hashed Id's seems pretty good to me. I have done something similar (though for more users and using a dbms and domain userids) :- to keep things manageable all users were a member of one *or more* 'groups' (groups table); each group had a list of fields it could access (fields table); when a user started the program (from a departmental file-server or possibly a pc) it first created a local ('C drive') dbc view on-the-fly from an spt select on the groups/fields tables (followed by some code 'borrowed' from MakeUpdateable.prg); the main menu could also be modified on-the-fly to en/disable some 'special' functions.
On 08/03/2016 01:16, John R. Sowden wrote:
Your comment: Yes, that is one area of concern. Is my way best, etc. But my other concern is how the program receives that data of ID and Access Level, and how is that data packaged. Is that process a security risk. My usage is simple and often simple is easy to bypass.
Example: I have 10 security levels. I ID each user from 0 to 9. Maybe that is too simple to avoid tampering. I have 10ish employees, so I have 20 ID 'numbers'. That is also easy to tamper with. These are my concerns.
John
On 03/07/2016 09:33 AM, Peter Cushing wrote:
On 07/03/2016 17:16, John R. Sowden wrote:
Let me address a few issues:
- My question was regarding making the software association between
the user data in the user database, along with his/her authority level and id, and the executing program.
Are you talking about a better way to limit/change which programs that the user is allowed to run? If so I can explain how we do it and that might help.
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email. www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715 London Office:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960
[excessive quoting removed by server]
-
Alan Bourke -
AndyHC -
Charlie -
Jean Laeremans -
John R. Sowden -
Peter Cushing -
Stephen Russell -
Ted Roche -
Wollenhaupt, Christof