changing table password

[SpandexBobcat]

Hi gang,

I am having a nightmare here. I am trying to import a paradox database into Access. I have done it in the past without any problems but now it would seem the password on two tables is no longer accepted. The message 'Cannot decrypt file' keeps coming up. Even on just trying to access the tables from with paradox, when asked for the password simply clears as if it were wrong. Other password protected tables open (they have a different password)....

Is there any way I can change this password? What would you do?!?! I am at a complete loss.... Not being a wizz at paradox makes this even more difficult for me. I am using version 5.

All help would be appreciated.

SB

 

[Langley]

Your table may be corrupted. If you have a recent backup, I'd try restoring it. Failing that you can try some of the cracking programs on the web.

Mac

"There are only 10 kinds of people in this world... those who understand binary and those who don't"

langley_mckelvy@cd4.co.harris.tx.us

 

[Bystander]

Langley,

This is scary I thought that Paradox encryption/passwords were uncrackable?

Rgeards

Bystander

 

[Langley]

No, unfortunately they are not. Lance can probably tell you exactly why, but as I recall it was a flaw in the original Borland product that has been carried forward.

Mac

"There are only 10 kinds of people in this world... those who understand binary and those who don't"

langley_mckelvy@cd4.co.harris.tx.us

 

[footpad]

Bystander,

Mac's correct; Paradox table passwords are not secure and can be defeated with minimal effort.

The problem is not so much as flaw, but a side-effect of the way passwords are stored in the encrypted tables. Instead of storing the original password, a digest of the password is generated and then stored. That is, your password is converted to a numeric representation.

Unfortunately, the conversion is fairly simple. If you can find that number or calculate one that matches, you're in. It's something that's doable in many password storage systems, not just Paradox's.

For a loose analogy, consider the easiest way to break into a locked car: break the window. Sure, you hope that won't happen and in many cases, it won't. But, if someone really wants your radio, they'll get it. We don't normally think about it, because locking the car does stop most thieves.

True security is nearly impossible; most security professionals talk about "acceptable levels of risk." You need to balance the possibility of compromise against the effort needed to secure things as completely as possible.

It's a balancing act, one that's different for each situation.

Now, there is another weakness in the BDE table password system. For technical and support reasons, the BDE developers created backdoor passwords that would always decrypt protected tables. They did this for testing reasons (e.g. if we encrypt the data, can we accurately unencrypt it? How do we test that?) and they also did this for what I call political reasons. ("What do we do when someone with 5,000 licenses calls up and tells us they're forgotten the password to their mission critical data?&quot

(Aside: When I was in support, I took a call from a woman frantic because she'd lost the password. We told her the official answer: "We're sorry, there's nothing we can do. There's no way to unencrypt the data without the original password." Her boss was listening, broke into the conversation, and fired her on the spot.

As you can imagine, it was a very difficult call to listen to. Very theatrical and possibly very staged. There was no way to know. Nevertheless, it's one of the few calls I remember after all this time. I only mention it to illustrate the questions that go into this sort of thing.)

In my experience, though, you can improve the security of your data in many ways. For example, you can encrypt the data using a different mechanism, such as Dynazip or other third-party library.

You can also (and should) restrict access to the most sensitive data. One reason people are able to steal credit card numbers from Internet sites is simply because those numbers are available when they should be locked away on a different network, one that doesn't have outside access.

Still, no matter how many safeguards you build into the system, there's always the risk that someone will simply copy the data and carry it out of the office.

If you're really interested in these issues and how to respond to them in a reasoned, thoughful way, then I highly recommend the writings of Bruce Schneier (

http://www.schneier.com/),

who is well-regarded in the Internet security community and has written books that are considered *the* titles to know.

Now, having gone into that rant -)), there's a completely different reason you may be getting this error. Specifically, BDE contains a safegard designed to prevent older versions from mangling newer versions of the format.

When you try, for example, to open a Paradox 7 table in Paradox 5.0, you'll get this error. (Primarily because Paradox 7 tables have features that Paradox 5 doesn't know how to deal with.)

This error appears frequent with older versions of Microsoft's ODBC driver for Paradox because it was written with an older technology called the Paradox engine. The Paradox engine predates BDE (and ODAPI, BDE's original name). The Paradox engine supported Paradox v3 tables and therefore doesn't know how to handle memos and other features added to the Paradox v4 format.

So, it's entirely possible this is an "honest" error designed to protect you.

One way to test this is to use Paradox to export your data to a different format, such as dBASE, CSV (text), or whatever. That done, try to import the converted data.

If it works, then the error was probably genuine, though it displayed a weird message.

Hope this helps...

-- Lance

 

[NotAllThere]

If you need to implement good security for Paradox tables then have a look at Px3P - practically uncrackable, if a little dated. It allows the use of indices, etc as normal, but if the Px3p dll and the correct password are not present, cracking Paradox tables only yields encoded (garbled) record contents.

Make sure you backup critical data in a clear or normally encrypted format, because table recovery tools may not work at all.

http://www.rksolution.cz/DELPHI/DELPHI.htm

Regards,
Padraig.