Ignorance and stupidity still runs in the so-called “expert consultant” fraternity.
“An outdated software that is used by about 200 Vermont municipalities and the Vermont Tax Department has long contained flaws that exposed sensitive information including Social Security numbers, according to an IT consultant and the software company’s founder.” “You could make a strong case that Visual FoxPro shouldn’t be used on a government level,” Johnson said.
https://vtdigger.org/2019/02/05/consultant-outdated-software-left-worker-inf...
Thankfully the software owners realise that it isn’t a fault in VFP, it is a fault in the designing of the infrastructure.
Expert: Ex - Out of date Spurt – a drip under pressure!!
Dave Crozier Software Development Manager Flexipol Packaging Ltd.
﴾⚆ᨎ⚆﴿
Flexipol® Packaging Ltd T 01706 222 792 E DCrozier@flexipol.co.uk W https://www.flexipol.co.uk/ Follow us: Unit 14 Bentwood Road, Carrs Industrial Estate, Haslingden, Lancashire, BB4 5HH
This communication and the information it contains is intended for the person or organisation to whom it is addressed. Its contents are confidential and may be protected in law. If you have received this e-mail in error you must not copy, distribute or take any action in reliance on it. 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.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the risk of virus transmission through email and therefore any files sent via e-mail will have been checked for known viruses. However, you are advised to run your own virus check before opening any attachments received as Flexipol Packaging Ltd will not in any event accept any liability whatsoever once an e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate virus protection.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Terms & Conditions: Notwithstanding delivery and the passing of risk in the goods, the property in the goods shall not pass to the buyer until the seller Flexipol Packaging Ltd. ("The Company") has received in cash or cleared funds payment in full of the price of the goods and all other goods agreed to be sold by the seller to the buyer for which payment is then due. Until such time as the property in the goods passes to the buyer, the buyer shall hold the goods as the seller's fiduciary agent and bailee and keep the goods separate from those of the buyer and third parties and properly stored protected and insured and identified as the seller's property but shall be entitled to resell or use the goods in the ordinary course of its business. Until such time as the property in the goods passes to the buyer the seller shall be entitled at any time
--- StripMime Report -- processed MIME parts --- multipart/related multipart/alternative text/plain (text body -- kept) text/html image/jpeg image/jpeg image/png image/png image/png image/png ---
Well, a lot of that article is correct, even though I don't want it to be. VFP as a *language* is as secure as the programmer programmed it to be. VFP as a *database* isn't secure itself. You can encrypt fields. You can encrypt the directory that the data is stored in. But DBF data isn't secure. You wouldn't store social security numbers or credit card numbers in Excel spreadsheets, right?
I've haven't recommended DBFs for storage for over a decade now. There are better storage mechanisms such as Postgres, MariaDB, and even SQLite which can be set up as an encrypted database. VFP as a language is still valid, although it will never be able to create 64bit applications but that is a different subject. [Insert Xojo plug here as a viable language for VFP developers.] I had a potential client where they based their primary keys based on employee Social Security Numbers. They didn't like it when I told them that they'd need a complete rewrite. Notice this would have been the case no matter what language/technology they were using. It was just piss poor design.
It appears from the article, that when the vendor was notified of the situation, that they were able to quickly address it although the article didn't say what that solution was. Probably encrypted the field? Hash the field with an external secured table containing the sensitive data? Who knows. To me, that's a win. Hopefully the vendor contacts all customers notifying them that there is a vulnerability and that there is a solution available.
As Ted Roche always says "Security is a process".
-Kevin
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Friday, February 22, 2019 6:07 AM To: 'ProFox Email List' profox@leafe.com Subject: VFP: false news....
Ignorance and stupidity still runs in the so-called “expert consultant” fraternity.
“An outdated software that is used by about 200 Vermont municipalities and the Vermont Tax Department has long contained flaws that exposed sensitive information including Social Security numbers, according to an IT consultant and the software company’s founder.” “You could make a strong case that Visual FoxPro shouldn’t be used on a government level,” Johnson said.
https://vtdigger.org/2019/02/05/consultant-outdated-software-left-worker-inf...
Thankfully the software owners realise that it isn’t a fault in VFP, it is a fault in the designing of the infrastructure.
Expert: Ex - Out of date Spurt – a drip under pressure!!
Dave Crozier Software Development Manager Flexipol Packaging Ltd.
﴾⚆ᨎ⚆﴿
Flexipol® Packaging Ltd T 01706 222 792 E DCrozier@flexipol.co.uk W https://www.flexipol.co.uk/ Follow us: Unit 14 Bentwood Road, Carrs Industrial Estate, Haslingden, Lancashire, BB4 5HH
This communication and the information it contains is intended for the person or organisation to whom it is addressed. Its contents are confidential and may be protected in law. If you have received this e-mail in error you must not copy, distribute or take any action in reliance on it. 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.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the risk of virus transmission through email and therefore any files sent via e-mail will have been checked for known viruses. However, you are advised to run your own virus check before opening any attachments received as Flexipol Packaging Ltd will not in any event accept any liability whatsoever once an e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate virus protection.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Terms & Conditions: Notwithstanding delivery and the passing of risk in the goods, the property in the goods shall not pass to the buyer until the seller Flexipol Packaging Ltd. ("The Company") has received in cash or cleared funds payment in full of the price of the goods and all other goods agreed to be sold by the seller to the buyer for which payment is then due. Until such time as the property in the goods passes to the buyer, the buyer shall hold the goods as the seller's fiduciary agent and bailee and keep the goods separate from those of the buyer and third parties and properly stored protected and insured and identified as the seller's property but shall be entitled to resell or use the goods in the ordinary course of its business. Until such time as the property in the goods passes to the buyer the seller shall be entitled at any time
--- StripMime Report -- processed MIME parts --- multipart/related multipart/alternative text/plain (text body -- kept) text/html image/jpeg image/jpeg image/png image/png image/png image/png ---
_______________________________________________ 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/CWLP265MB0852BBC5D439DBB2E4E97026FB7F... ** 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.
On Fri, Feb 22, 2019 at 6:11 AM Kevin J Cully kjcully@cherokeega.com wrote: <snip>
I had a potential client where they based their primary keys based on employee Social Security Numbers. They didn't like it when I told them that they'd need a complete rewrite. Notice this would have been the case no matter what language/technology they were using. It was just piss poor design.
<snip>
I must confess.... I did this once and used SSN's as a primary key. It is my shame....
I was told I had a year and a half to write a enterprise wide application and out of the blue the reality was I had about 3 weeks, and failure would have cost millions and millions... oh - and my job...
I was panicked and the first thing I thought to use was the SSN thinking that certainly they wouldn't be changing so as a PK would be handy to use. I went for it w/o thinking it through...
Granted, this was back in the day when the internet wasn't what we think of today, but still - it was a really dumb dumb idea I always regretted...
Forgive yourself and move on. :D We've all made bad design decisions at one point or another in the past. The most important part is that you are active in a developer community and seek to do better. I hope that I am a better developer today than I was yesterday. There are a ton of VFP developers and they've never reached out to their community to improve their skills and it shows in their code.
On 2/22/19 12:57 PM, M Jarvis wrote:
On Fri, Feb 22, 2019 at 6:11 AM Kevin J Cully kjcully@cherokeega.com wrote:
<snip>
I had a potential client where they based their primary keys based on employee Social Security Numbers. They didn't like it when I told them that they'd need a complete rewrite. Notice this would have been the case no matter what language/technology they were using. It was just piss poor design.
<snip>
I must confess.... I did this once and used SSN's as a primary key. It is my shame....
I was told I had a year and a half to write a enterprise wide application and out of the blue the reality was I had about 3 weeks, and failure would have cost millions and millions... oh - and my job...
I was panicked and the first thing I thought to use was the SSN thinking that certainly they wouldn't be changing so as a PK would be handy to use. I went for it w/o thinking it through...
Granted, this was back in the day when the internet wasn't what we think of today, but still - it was a really dumb dumb idea I always regretted...
I have trouble criticizing your former programming self for making a decision at an earlier time with the limited information, knowledge and experience. Hindsight is ALWAYS 20/20 and none of our earlier programming would stand up to much scrutiny using today's knowledge and experience. Besides, I've seen a lot of early mainframe programming that made the same kinds of decisions based on the best knowledge they had at the time. Any Cobol programmers out there remember Y2K?
I forgave my early programming, ignorant self a long time ago and tried to learn and do better every day going forward. Now when I look back at my earliest code, I try to focus on the mistakes I could have made but didn't. :)
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of M Jarvis Sent: Friday, February 22, 2019 11:57 AM To: profoxtech@leafe.com Subject: Re: false news....
On Fri, Feb 22, 2019 at 6:11 AM Kevin J Cully kjcully@cherokeega.com wrote: <snip>
I had a potential client where they based their primary keys based on employee Social Security Numbers. They didn't like it when I told them that they'd need a complete rewrite. Notice this would have been the case no matter what language/technology they were using. It was just piss poor design.
<snip>
I must confess.... I did this once and used SSN's as a primary key. It is my shame....
I was told I had a year and a half to write a enterprise wide application and out of the blue the reality was I had about 3 weeks, and failure would have cost millions and millions... oh - and my job...
I was panicked and the first thing I thought to use was the SSN thinking that certainly they wouldn't be changing so as a PK would be handy to use. I went for it w/o thinking it through...
Granted, this was back in the day when the internet wasn't what we think of today, but still - it was a really dumb dumb idea I always regretted...
Purely out of curiosity and not being familiar with your SSNs (Social Security Numbers I assume) can I ask what is the problem with using them as a PK?
John Weller 01380 723235 07976 393631
I must confess.... I did this once and used SSN's as a primary key. It is my shame....
John:
There's a couple of issues with using SSNs.
Technically, they are not unique. Several people have received duplicate numbers, so they're not ideal primary keys.
Second, they are considered "secret" Personally Identifiable Information (often PII) and disclosure of such information can be a considered a data breach, leaving you liable to state, local, federal and international laws (like GDPR) requiring you to provide disclosure, notification and possible liability.
They're also pretty easy to guess. The first two designates the state of birth, easy to find, the last four and printed on FAR too many documents, and the three in the middle were issued chronologically, so knowing a birthdate narrows the guessing down by far.
When I was in bootcamp in 1979, they gave us all stencils and required us to have our name and service number, also our SSN on the hundreds of pieces of uniform and gear we were issued. I've still got a few in my basement and attic. Some secret!
On Mon, Feb 25, 2019 at 11:13 AM John Weller john@johnweller.co.uk wrote:
Purely out of curiosity and not being familiar with your SSNs (Social Security Numbers I assume) can I ask what is the problem with using them as a PK?
John Weller 01380 723235 07976 393631
I must confess.... I did this once and used SSN's as a primary key. It is my shame....
[excessive quoting removed by server]
On Feb 25, 2019, at 10:26 AM, Ted Roche tedroche@gmail.com wrote:
There's a couple of issues with using SSNs.
Technically, they are not unique. Several people have received duplicate numbers, so they're not ideal primary keys.
They are presumably being used as PKs for tables representing humans, no? Then the vast majority of potential records would have null values, since most humans are not citizens of the USA.
-- Ed Leafe
On Mon, Feb 25, 2019 at 11:38 AM Ed Leafe ed@leafe.com wrote:
They are presumably being used as PKs for tables representing humans, no? Then the vast majority of potential records would have null values, since most humans are not citizens of the USA.
Ur either Muricans, or your not. ;)
But seriously, there are some non-citizens with SSNs, and citizens, without. So, yeah, Matt's really sorry and promises not to do it again.
Uh oh Ted - this kinda comment could push this thread into the Devious world of the OT Territory!!!
For the heck of it - I Googled the term - and I found it kind funny what was written up in the Urbandictionary:
"Those Muricans think they can just push everyone around. What abunch https://www.urbandictionary.com/define.php?term=bunchofarrogant https://www.urbandictionary.com/define.php?term=arrogantimperialisticbastards https://www.urbandictionary.com/define.php?term=bastards!"
Sure sounds like a word that Stephen Colbert would use a Lot!
;-) -K-
On 2/25/2019 9:00 AM, Ted Roche wrote:
Ur either Muricans, or your not.;)
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
At 08:38 2019-02-25, Ed Leafe ed@leafe.com wrote:
On Feb 25, 2019, at 10:26 AM, Ted Roche tedroche@gmail.com wrote:
There's a couple of issues with using SSNs.
Technically, they are not unique. Several people have received duplicate numbers, so they're not ideal primary keys.
They are presumably being used as PKs for tables representing humans, no? Then the vast majority of potential records would have null values, since most humans are not citizens of the USA.
You do not have to be a USA citizen to have an SSN. I had one when I worked down there on a visa; it might even still be assigned to me.
Sincerely,
Gene Wirchenko
Thanks Ted, that explains it well. We have a similar number, the National Insurance Number, which is unique and is not considered 'secret' at least as far as I am aware, but that is random and includes a check digit. I don't think I would use it as it is too cumbersome. 😊
I know what you mean about marking kit, fortunately when I went through basic training we didn't have to do that but I still have a boot brush with a relative's service number carved in it from when he did National Service (conscription) that I inherited.
John
John Weller 01380 723235 07976 393631
John:
There's a couple of issues with using SSNs.
Technically, they are not unique. Several people have received duplicate numbers, so they're not ideal primary keys.
Second, they are considered "secret" Personally Identifiable Information (often PII) and disclosure of such information can be a considered a data breach, leaving you liable to state, local, federal and international laws (like GDPR) requiring you to provide disclosure, notification and possible liability.
They're also pretty easy to guess. The first two designates the state of birth, easy to find, the last four and printed on FAR too many documents, and the three in the middle were issued chronologically, so knowing a birthdate narrows the guessing down by far.
When I was in bootcamp in 1979, they gave us all stencils and required us to have our name and service number, also our SSN on the hundreds of pieces of uniform and gear we were issued. I've still got a few in my basement and attic. Some secret!
On 25/02/2019 16:53, John Weller wrote:
Thanks Ted, that explains it well. We have a similar number, the National Insurance Number, which is unique and is not considered 'secret' at least as far as I am aware, but that is random and includes a check digit. I don't think I would use it as it is too cumbersome. 😊
I know what you mean about marking kit, fortunately when I went through basic training we didn't have to do that but I still have a boot brush with a relative's service number carved in it from when he did National Service (conscription) that I inherited.
Although the NI number is not considered secret, it is like your DOB and other details that you don't want people to have easy access to. Got to make it difficult for people to steal your identity.
You inherited a boot brush? That's a new one on me :-)
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: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
I should have said given 😊 Gt Ducie St - that brings back memories of commuting between Salford and Manchester Grammar many, many years ago!
John Weller 01380 723235 07976 393631
You inherited a boot brush? That's a new one on me :-)
On 25/02/2019 17:10, John Weller wrote:
I should have said given 😊 Gt Ducie St - that brings back memories of commuting between Salford and Manchester Grammar many, many years ago!
It's more or less the same now, but with worse traffic :-( Oh and Boddington's brewery has gone.
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: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
-
Dave Crozier -
Ed Leafe -
Gene Wirchenko -
John Weller -
Kevin Cully -
Kevin J Cully -
Kurt ＠ Gmail -
M Jarvis -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Paul H. Tarver -
Peter Cushing -
Ted Roche