Re: security in programming
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:
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.
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]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/56de96c4.6060...@hawthorncottage.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
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 . 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 ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/56de0e20.6040...@verizon.net ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
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: 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. 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] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/56dddab2.3060...@americansentry.net ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
On 07/03/2016 17:16, John R. Sowden wrote: 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. 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 ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/56ddbb84.4010...@whisperingsmith.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
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] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/56ddb768.8060...@americansentry.net ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
Want secure ? Don't connect to the net. On Mon, Mar 7, 2016 at 3:43 PM, 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. > > > > On Mon, Mar 7, 2016 at 7:48 AM, Ted Roche 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 > > 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] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/capqlobydtno8r5gmyvrqugj1aihqadywlj0xqbexplmxuqb...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
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 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 > 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] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cajidmylrcxxqcrtbsb+5xduudbyliobunlbq6x-ump0wz9r...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
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 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] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4uCSVrWA9iFt-kS7pZQpY7zJ6ZTTt2F==ofgjliant...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
IMO if your data is in DBF files, it's not secure. -- Alan Bourke alanpbourke (at) fastmail (dot) fm ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/1457354605.619027.541751186.00ad3...@webmail.messagingengine.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: security in programming
> > 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 --- ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cal4qjhjmjz+x0mpas3q5kjbuegz2p9uk7_d1bry0pawknk2...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
security in programming
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 --- ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/56db695c.9020...@americansentry.net ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
