My understanding is that these third party applications cannot reveal what an existing password is, but rather they enable you to set a new password which simply crunches the old one.
1 of 1 people found this helpful
This type of cracker software has been around for years.
Note that they don't actually claim to be able to recover original passwords, just that their software can change them, which not quite what I believe they are doing.
When this type of software first came to my attention many years ago, I seem to recall they were going into the file's code and actually overwriting a section where Admin account info was stored, and writing new code into the file. That would leave the file in a hacked state where the integrity of the file might not be reliable.
However, it is likely from their claims and marketing that this technique might enable someone to force open a FileMaker file and read the data inside.
I wonder if either removing or disabling the default "Admin" account would affect their technique? I have not been inclined to mess with their hack, but would like to hear from anyone who has tested it on a file copy they were willing to trash....
We have at least one version of these utilities on site. We use it to hack into databases that people have forgotten passwords to, or moved on. The version we have does not recover any passwords; it simply recovers the accounts and removes the passwords from the file.
However, as pointed out by Stephen, this allows the file to be entered and the data - and code, schema, and other structure - to be read and manipulated. So I would advise strongly that, in every case, you avoid giving an end user access to the physical database file. If that's not an option, then use the Developer Utilities functionality in Advanced to remove the [Full Access] accounts from any copy that is distributed. This leaves no [Full Access] account in the end state product to be hacked.
I don't know if the new version 13 encryption at rest affects this equation at all. Would be interesting to find out.
I'm fairly certain the AES-256 file encryption is designed to make the file completely unrecoverable, as I just wrote a client: "No one who doesn't already have the decryption key will open that file before the sun explodes and the universe reaches maximum entropy."
Still, I'm finding published concerns about ever storing sensitive data in a FileMaker database:
I can't imagine how FileMaker could been seen as especially insecure, unless it's just that their FileMaker servers aren't as secure physically or on the network as their servers where they do store sensitive data.
Not sure I would go quite that far. Any encryption can eventually be broken if you throw enough computing horsepower at it.
As for your linked MIT document, most of it is common sense or best practice. The prohibition on storing “PIRN” (which is, essentially, what the rest of us might call “PII”) appears to be on files that are stored either locally or on a workgroup (NAS) share. (The reason I say that is the reference to not web-enabling the database if you’re storing sensitive data; it appears you can store sensitive data if it’s hosted on Server.) Putting the database on a share or local hard drive is what we’ve been talking about; it exposes the database file itself to a potential attacker. So you wouldn’t want sensitive data in such a file as an extra layer of protection.
I’m very sure their (not FMI) claims are false. As far as I know they replace the existing hash (and a lot of other stuff to make the file openable) with one of their own and give you their password. However, you cannot get into your original file with it. And the file could easily be damaged. AFAIK they only offer this ‘service’ so you can get your data. Not sure if the file format is covered by this but, to reverse engineer the product is a violation of the EULA.
Before you fiddle around with your files using unreliable tools, you'd better have the file "repaired" by me.
You will get back an error free, genuine file. For details please see <fmdiff.com/repairs>.
Please visit my vendor session at Devcon this year.
Mycrypto is only offering to crack double-digit bit keys:
128-bit key would have 2^128 (3.402823669209e+38) total possible combinations. For example, to theoretically crack the 128-bit IDEA key using brute force one would have to:
- develop a CPU that can test 1 billion IDEA keys per second
- build a parallel machine that consists of one million of these processors
- mass produce them to an extent that everyone can own one hundred of these machines
- network them all together and start working through the 128 bit key space
Assuming ideal performance and no downtime, one should be able to exhaustively search the key-space in over 20,000 years.
That's 128-bit. FileMaker is using 256.
AES permits the use of 256-bit keys. Breaking a symmetric 256-bit key by brute force requires 2128times more computational power than a 128-bit key. 50 supercomputers that could check a billion billion (1018) AES keys per second (if such a device could ever be made) would, in theory, require about 3×10^51 years to exhaust the 256-bit key space.
Sorry, that copy-paste is a little hard to read. That would be 3,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years.
Even with the most theoretically efficient processor possible:
"...a 128-bit symmetric key... would theoretically require 2128 − 1 bit flips on a conventional processor. If it is assumed that the calculation occurs near room temperature (~300 K) the Von Neumann-Landauer Limit can be applied to estimate the energy required as ~1018 joules, which is equivalent to consuming 30 gigawatts of power for one year. This is equal to 30×109 W×365×24×3600 s = 9.46×1017 J or 262.7 TWh (more than 1/100th of the world energy production)"
That’s today. Computing power 5 years ago paled.
Nobody thought SSL was crackable, either, until Heartbleed. Even if brute force can’t do it today, using today’s computing power, I’m not comfortable telling a client that something “can’t” be cracked.
True. If computing power is 10x faster than it was 5 years ago, it should now ony take
300,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 (3^50) years to crack.
Except no one's even sure whether we will ever be able to make even one computer that can "check a billion billion (1018) AES keys per second." So we're still daydreaming about the decade we can start cracking those codes in
3,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 (3^51) years.
"In fact, we cannot even imagine a world where 256-bit brute force searches are possible. ...brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space."
Again, if we could capture all the energy from the Sun and use it to power the most efficient computer hypothetically imaginable till the day the Sun died, it would not be enough to brute-force crack AES-256.
No one is every going to need anything stronger than a 256-bit key.
At this point the weakness can only be in how the key is generated allowing "good-guess" attacks or in how it was applied—but such weaknesses are unnecessary.
Here's my problem with telling a customer that something is "never" possible:
That ship could "never" be sunk. Even God couldn't sink her (so said a plaque installed on the vessel). That should be reason enough to say, "Knowing what we know today, it is mathematically infeasible for a brute force attack to be able to crack into this encryption." But that is a long way from "never".
"Never" has a couple of problems:
1) It presumes that no conditions will ever change in ways we can't predict right now. Nobody ever imagined the Internet not so long ago, or how a DDOS attack might harness only minimal computing power from millions of individual computers to attack a single server. How many computers will be on the Internet in 10 years? 20 years? 100 years? How much computing power might be harnessed if someone were able to infect those machines with a virus that was smart enough to attack a single problem, quietly, in the background?
2) Another problem, and a far bigger one, in my view, is complacency. The engineers on the Titanic designed an "unsinkable" ship - but only if certain protocols were followed. Since the ship was "unsinkable", well, why follow those protocols? We're unsinkable!
When people get the idea their security is "uncrackable", they get lazy and complacent. That's dangerous. That's why I shy away from the idea that security is a "done deal", especially around clients who may not understand the notions of mathematical probabilities versus the need for good layered security, ever-evolving and ever-evaluating against the risk and the threats. Overconfidence gets people in trouble. Or cold water. Without a lifeboat.
I emphatically agree about the complacency issue. The better encryption becomes, the less people seem to think they have any personal obligation to help keep files safe.
Another issue with the "low probability" of being cracked is that the mathematical probability is based on a zero-complancey approach to things like password choice as well. It doesn't matter how good the encryption is if the users are still picking their birthdays, spouses' names, and stumpers like "passw0rd" to protect their accounts.
Those mathematical probability statistics assume the highest levels of password complexity, and users simply don't pick those types of passwords. If the password they chose is among the first 100 which the cracker software tries, guess how many nano-seconds it takes to crack that gazillion-year-proof system?
Fair points about complacency and implementation, which I would certainly discuss.
However unlikely, there is at least some unknown whether FileMaker Inc. has actually implemented the encryption improperly.
And how the key is generated, who has it, and where it might be stored is always a weakness in any cryptography.
Anyway, where I have to take this infomation is comparative, since it's to answer comments of FileMaker's file security verus others systems.
In any case, to answer "I don't know if the new version 13 encryption at rest affects this equation at all. Would be interesting to find out.":
I would still say AES-256 file encryption certainly affects the equation, and it's quite likely the world will never find out whether an encrypted file with a good password could ever be recovered without it already having it.
A bit late, perhaps...
One 'flaw' to the encryption theory is the user and the developer who, by law, forces the user to reset their password so that its private and known only to the account user.
Also, the developer who uses the user's names for the account names.
The user will reset that password they were given "x77e3VVnffu" to the name of their dog or to JoeSmith, something they can remember. It doesn't take 10 to the 123rd power years to try JoeSmith or Muffin to score a hit. Web sites publish the to 10 or 20 passwords for the year and movie names score high.
And, if you create accounts Joe W Smith and Joe H Smith and they both know of the other, they can try JoeSmith to open the other guys account...
Passwords, like the best laid military plans, only last as long as the first encounter.
And then the postit note...
And the obvious point that is often forgotten in the zillion years to crack, a lucky hacker could guess it on the first try...
Also, if the data is really sensitive and of high value, then the hacker could buy lists of passwords known to be used by the person in question and try those. Or every bit of data scraped from the internet and look for clues.