Supplier refusing to decrypt data in our own database. Help!
Discussion
budgie smuggler said:
Thanks, I'll have to have a proper read of that later. The brief synopsis I read made it sound as if all 'trialware' and the licensing/activation systems used by Office, Windows etc would be illegal.
It's covert time locks that are illegal. Not trial ware."installing and activating a covert software time-lock is an Unauthorised modification"
R v Alfred Whittaker
Software developer AAS Management Systems installed bespoke software with covert timelock for Protech Formulations Ltd. Timelock activated and denied access to software after dispute arose over unpaid fees. Held - installing and activating a covert software time-lock is an Unauthorised modification. Defendant convicted. Conditional discharge. Decision widely reported as "time-locks are illegal".
R v Gareth Hardy
Encryption package installed by defendant computer manager. Time-lock (data no longer decrypted) activated one month after end of defendant's employment. Defendant pleaded guilty and convicted. £3000 compensation order and 140 hrs community service order.
beanbag said:
AnotherGuy said:
Early 90's PC database?
It's likely to be dBase, FoxPro or Paradox.
Send the .dbf files (or equivalent) to http://www.pwcrack.com/dbase.shtml
$75 later you'll have the password. These guys are legit and been around a while.
Cheers! I'll definitely give that a try!It's likely to be dBase, FoxPro or Paradox.
Send the .dbf files (or equivalent) to http://www.pwcrack.com/dbase.shtml
$75 later you'll have the password. These guys are legit and been around a while.
Vaud said:
It's covert time locks that are illegal.
...
R v Alfred Whittaker
Software developer AAS Management Systems installed bespoke software with covert timelock for Protech Formulations Ltd. Timelock activated and denied access to software after dispute arose over unpaid fees. Held - installing and activating a covert software time-lock is an Unauthorised modification. Defendant convicted. Conditional discharge. Decision widely reported as "time-locks are illegal".
R v Gareth Hardy
Encryption package installed by defendant computer manager. Time-lock (data no longer decrypted) activated one month after end of defendant's employment. Defendant pleaded guilty and convicted. £3000 compensation order and 140 hrs community service order.
I wouldn't have said this was covert - the customer knows damn well that it's there, and has known for years....
R v Alfred Whittaker
Software developer AAS Management Systems installed bespoke software with covert timelock for Protech Formulations Ltd. Timelock activated and denied access to software after dispute arose over unpaid fees. Held - installing and activating a covert software time-lock is an Unauthorised modification. Defendant convicted. Conditional discharge. Decision widely reported as "time-locks are illegal".
R v Gareth Hardy
Encryption package installed by defendant computer manager. Time-lock (data no longer decrypted) activated one month after end of defendant's employment. Defendant pleaded guilty and convicted. £3000 compensation order and 140 hrs community service order.
TooMany2cvs said:
Apart from the subtle detail that this software predates that, it's not in the UK.
Which bit of:plasticpig said:
Which is illegal in the UK but Spain could be a different matter.
did you not understand? The OP said early nineties. You cant get earlier than 1990 in the 1990's so unless the software was sold prior to June 1990 when the act came into force the software does not predate the Act.I'm highly sceptical that a 90s hotel booking system was encrypting it's data at rest, if it really is the issue then it's fairly easy to over come, Unfortunately i suspect the issue is much more fundamental than that, and the data is simply obscure and it does not matter if it's encrypted or not because you have nothing to interpret it with.
Personally i would completely forget about most of the historic data, you might be required to keep it by law, but it does not have to all be on the same system.
The main thing you'll need to extract is your future bookings, and your customer contact information.
I suspect if you only took that and ran the 2 systems in parallel for a while, within a few weeks you'd rarely have need to access the old system, and can then just leave it hosting the old data.
When the old system is no longer in use you can then poke about with it as much as you want without causing any disruption to try and see if you can get it all out, or try agree to a reduced licensing fee with the supplier now it's only used to auditing purposes, or failing that, get anything useful out, bundle the whole system up put it onto a VM which is inactive most of the time and do some messing around with the clock to ensure it never finds out it's license has expired when you do need to look at it.
Personally i would completely forget about most of the historic data, you might be required to keep it by law, but it does not have to all be on the same system.
The main thing you'll need to extract is your future bookings, and your customer contact information.
I suspect if you only took that and ran the 2 systems in parallel for a while, within a few weeks you'd rarely have need to access the old system, and can then just leave it hosting the old data.
When the old system is no longer in use you can then poke about with it as much as you want without causing any disruption to try and see if you can get it all out, or try agree to a reduced licensing fee with the supplier now it's only used to auditing purposes, or failing that, get anything useful out, bundle the whole system up put it onto a VM which is inactive most of the time and do some messing around with the clock to ensure it never finds out it's license has expired when you do need to look at it.
So, I've been feverishly working away getting this to work so apologies for not replying to some of the comments.
I spent quite a bit of time trying out a number of DB formats but none seemed to understand the files I had and once again after talking to my friend he agreed the format was very unusual. In short, I've no idea which system this developer used.
However, as a spotty teen, I used to play a lot in DOS and I remembered back in the day, executable strings were a way to unlock a lot of features in apps and lo and behold, "/help", revealed a lot of interesting options including an "admin" option.
By using this string, it enabled an export data option and I've been able to export all the data to a CSV ASCII file. It's not perfect as many of the special characters are now buggered up but there are a number of other options to choose I will give those a try as well.
However, after exporting all the data, I was able to import it into a MySQL database. It's not at all normalised and has a ton of repeat data but it's perfectly usable. Interestingly, the export files have no primary keys on any of the records. Booking records were simply matched to the customer account number but there was no way to look up a specific booking ID. The staff had to look up an owner and check through all the bookings. The point is I have five tables of data. None of which is normalised and there's no primary key for any record other than the account ID in the client table.
What's more worrying is the fact that none of the credit cards are hashed, so that will be one of the first things I do too....in short, it's very shoddy and very shocking.....
Anyway, I appreciate all your help. I haven't bothered telling the original supplier I have the data and don't plan to either.
I now need to work on getting a new system built from scratch to manage the business....
Once again; Thanks all for your help!
I spent quite a bit of time trying out a number of DB formats but none seemed to understand the files I had and once again after talking to my friend he agreed the format was very unusual. In short, I've no idea which system this developer used.
However, as a spotty teen, I used to play a lot in DOS and I remembered back in the day, executable strings were a way to unlock a lot of features in apps and lo and behold, "/help", revealed a lot of interesting options including an "admin" option.
By using this string, it enabled an export data option and I've been able to export all the data to a CSV ASCII file. It's not perfect as many of the special characters are now buggered up but there are a number of other options to choose I will give those a try as well.
However, after exporting all the data, I was able to import it into a MySQL database. It's not at all normalised and has a ton of repeat data but it's perfectly usable. Interestingly, the export files have no primary keys on any of the records. Booking records were simply matched to the customer account number but there was no way to look up a specific booking ID. The staff had to look up an owner and check through all the bookings. The point is I have five tables of data. None of which is normalised and there's no primary key for any record other than the account ID in the client table.
What's more worrying is the fact that none of the credit cards are hashed, so that will be one of the first things I do too....in short, it's very shoddy and very shocking.....
Anyway, I appreciate all your help. I haven't bothered telling the original supplier I have the data and don't plan to either.
I now need to work on getting a new system built from scratch to manage the business....
Once again; Thanks all for your help!
beanbag said:
.
What's more worrying is the fact that none of the credit cards are hashed, so that will be one of the first things I do too....in short, it's very shoddy and very shocking.....
Pretty standard for a system of that vintage. Even if it had been hashed or encrypted, it would likely be pish to crack these days.What's more worrying is the fact that none of the credit cards are hashed, so that will be one of the first things I do too....in short, it's very shoddy and very shocking.....
Glad you've had a good outcome though!
beanbag said:
What's more worrying is the fact that none of the credit cards are hashed, so that will be one of the first things I do too....in short, it's very shoddy and very shocking...
Woah up a sec! Step back, and do some reading up on PCI-DSS. Lose the stored cards, and outsource that part. Seriously.TooMany2cvs said:
beanbag said:
What's more worrying is the fact that none of the credit cards are hashed, so that will be one of the first things I do too....in short, it's very shoddy and very shocking...
Woah up a sec! Step back, and do some reading up on PCI-DSS. Lose the stored cards, and outsource that part. Seriously.KevinCamaroSS said:
Might I suggest buying an off-the -shelf solution rather than building from scratch. This will avoid the same potential problem in the future, and will likely be cheaper as well.
What they said. OP, hotel processes are pretty common. Have you evaluated the SaaS options?I appreciate what many of you are saying but we've looking into 3rd party solutions. There aren't many options and we don't want what they have to offer for the following reason:
- Price. The resort is a mature timeshare complex so it's not just holiday rentals. The moment you add timeshare to the equation, things get expensive. We are a very small family business. 9 employees (4 of them cleaners) and just under 40 apartments. The minimum cost is well over $10k for the first year, and then over $5k per year thereafter. In other words, it would push up the IT budget by triple which is unaffordable. (All the 3rd party solutions we contacted start with products that can support 100 units or more. Since we're just 40% of that, we end up paying more and none will negotiate on price).
- Complexity. The card data will be hashed and only the company administrator will have access to the private key. Under Spanish law, the administrator is allowed access to card data and is ultimately responsible for it. No employee will have access to real card data (unless they are entering it manually which they must do). Most hotels will not do this. Next time you check in to a hotel, (especially abroad), have a look at the number of times they photocopy your passport / license and leave your booking.com reservation letter available on the desk. It'll have your full payment details (card number and all), on display.
- API integration. Most suppliers will offer API integration with booking.com or expedia, etc, etc...but not all so you end up having to choose. We want to integrate all 3rd parties that we work with, plus this would mean no employee would ever have to touch a credit card number (unless it's a reception or phone booking).
- Finally, coming back to the price, if you tie yourself into a product it costs a fortune to leave. Set-up costs, training, integration and you never own the software as it's all cloud based.
Anyway.....we're well into development already so it's all good....
- Price. The resort is a mature timeshare complex so it's not just holiday rentals. The moment you add timeshare to the equation, things get expensive. We are a very small family business. 9 employees (4 of them cleaners) and just under 40 apartments. The minimum cost is well over $10k for the first year, and then over $5k per year thereafter. In other words, it would push up the IT budget by triple which is unaffordable. (All the 3rd party solutions we contacted start with products that can support 100 units or more. Since we're just 40% of that, we end up paying more and none will negotiate on price).
- Complexity. The card data will be hashed and only the company administrator will have access to the private key. Under Spanish law, the administrator is allowed access to card data and is ultimately responsible for it. No employee will have access to real card data (unless they are entering it manually which they must do). Most hotels will not do this. Next time you check in to a hotel, (especially abroad), have a look at the number of times they photocopy your passport / license and leave your booking.com reservation letter available on the desk. It'll have your full payment details (card number and all), on display.
- API integration. Most suppliers will offer API integration with booking.com or expedia, etc, etc...but not all so you end up having to choose. We want to integrate all 3rd parties that we work with, plus this would mean no employee would ever have to touch a credit card number (unless it's a reception or phone booking).
- Finally, coming back to the price, if you tie yourself into a product it costs a fortune to leave. Set-up costs, training, integration and you never own the software as it's all cloud based.
Anyway.....we're well into development already so it's all good....
Gassing Station | Speed, Plod & the Law | Top of Page | What's New | My Stuff