Do these really work if you have strong passwords? I can imagine being
able to crack weak passwords -- few characters, dictionary words, easy
to guess, etc -- but what about strong passwords?
If strong passwords can be easily cracked, then what security is there
really in passwords?
I'm having an "am I invisible?" day here. ;)
As I stated before, password crackers do not reveal passwords in .fp7
files. The password is stored as a hashed string and cannot be
extracted.
What they do is replace the segment of the file with the hash with a
hash of a known password. Then they tell you the known password.
Almost all programs that use passwords can be hacked, particularly if a
user has physical possession of the file and some motivation. So FM
passwords are useful for keeping out amateurs, and for separating
account users from each other. They aren't terrific for protecting
data. You have to take other steps for that.
One is to use FMPro Advanced to strip out the admin access to files
that you distribute, such as for vertical market products. This means
that even if someone obtains a cracked password, it does them no good.
They have no higher access than the user password. They can't see
structure, scripting, tables, field defs, etc. So they can't reverse
engineer or hijack your product.
Another method is to run proper backups in a hosted situation, so that
a disgruntled user doesn't prevent access to your data, or as in the
case of the original poster, change admin passwords.
Using encryption is another method, but it's a performance-killer, to
be used sparingly.
--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer
The first question is what are you trying to protect and from whom?
Are you selling a commercial database and don't want customers
reselling your work? Are you protecting the data inside the solution?
Passwords are only one element in a security system, not the whole
thing. Properly constructed account permissions and physical security
of the database are two other big ones.
There are ways of mitigating the dangers. All Full Access passwords
should follow good practices. Without Full Access, and with non-Full
Access users allowed access to only the features the need, a cracker
is less useful.
But most critically, a cracker requires physical possession of the
database. If someone can get their hands on your solution, your
options are limited.
On the upside, I've heard a FM password crackers can corrupt the
database, making it unusable (though with data available). Don't know
if that's true.
Often, passwords are for account management as much as for security.
> But most critically, a cracker requires physical possession of the
> database. If someone can get their hands on your solution, your
> options are limited.
While this is true of the commercial crackers, it is not true of true
experts. I have personal knowledge that it's possible to crack hosted
files. Not easy, and there's only one person I know who can do it, who
is, thankfully, completely ethical. But it can be done.
However, run of the mill Bad Guys do need physical possession of the file.
>
> On the upside, I've heard a FM password crackers can corrupt the
> database, making it unusable (though with data available). Don't know
> if that's true.
Yes. The replacement of the hash may corrupt the file. It certainly
makes it unreliable for development or production.
>
> Often, passwords are for account management as much as for security.
Absolutely true. Most often, I'm endeavoring to keep well-meaning
people from committing unrecoverable errors with their own data. Only
rarely do my solutions rise to the level of protecting the solution
itself, or the data, from actual Bad Guys with Intent.
If you do need ironclad data security, then sorrowfully, FM is not your
tool. It just isn't secure enough.
Thanks to both Lynn and Grip for the answers. Need to think some more
about just what I am trying to protect.