EAR password not working

[Nico Kobes]

When I take a backup file from the server where all the databases are encrypted (EAR) the encryption password does not work. The password is the right one because it opens the server databases.

I copied the file to my own computer and try to open it with filemaker 17 and the password doen not work. Also tried to open the file on our test filemaker server 17 and also the password does not work.

Can anyone explain why this does not work?

[Fitch]

Caps lock?

[Nico Kobes]

This is what I did with the encryption process: 

- I did the encryption of all the databases

- I noted the encryption password in a file (temporary)

- After the encryption I opened all the databases on the Filemaker Server and checked the keychain box (easy for opening all the databases)

- Then I saved the encryption password in our own database online.

- I closed all the databases on the Filemaker Server

- Then I copied the password from our online database and opened all the databases on the server again, the admin app wants to have the encryption password and now I pasted the password from our online datbase -> WORKED!!

- OK, a couple days after that I cleaned up the encryption folder because everything is working

 

Now, months after, I want to open a backup file. Of course the database wants to have the encryption password, I go to our online database, I copied it and pasted it in the backup file. And now the password is WRONG!!

 

What I now found out on the server, when I close one database, I open it again, it asks for the encryption password, I put in a random password, it accepts it and opens the database !!!!

It looks like the keychain takes over the opening process..... 

 

The problem now is that I don't have the encryption password anymore ......  Is there a possibility to get it out of the keychain somehow?

Edited November 7, 2018 by Lee Smith
Please use the default font when posting your questions.

[Fitch]

I don't believe the encryption password is managed by any keychain. It's not clear where exactly the server stores it but AFAIK it's not the OS keychain. I have not heard of any way you can recover the password. That would defeat the whole purpose of it. Sorry.

[Greg Hains]

Good afternoon,

I know this post is getting old, but I was wondering if anybody has been able to reset or remove the encryption password from a solution that was hosted in Filemaker Cloud?  I understand if it's not a user-servicable thing and Filemaker themselves need to do it.

Greg

[OlgerDiekstra]

Being able to remove the encryption password without the password kinda defeats the purpose of having EAR. So I would say that it is not possible, probably not even for FM.

The only way to create a copy would be to manually copy tables, layouts, scripts and whatnot from the DB into a new DB. Or maybe you can create an XML export of the schema and scripts, and recreate your DB that way. And then import the data from the old DB.

What might be possible is to brute force the password, but that means creating an app that can invoke the DB, detect the password dialog, and enter passwords. It would probably take a long time.

[Greg Hains]

Hi Olger,

You're right about being able to disable it and how it would defeat the purpose, but I thought maybe FM had a tool to reverse it - unless it is a one way process - which would make it extremely secure.
The host needed rebooting due to some update it had to apply and since then the host cannot start the solution as it reports the encrypted password to be wrong. If I could open it locally I would manually copy everything across to a new file locally then upload it again. I'm almost (not entirely I admit) certain that I used the same encryption password thatI used on the other files but unless that password can become corrupted or I've simply used something else, then I'm stuck.
I've tried uploading it to my local FMS17 server where there is an option in Developers Tools to save a solution and remove/reset the EAR, but you require the original one to do that - makes sense too I guess.

Very frustrating. Most likely my fault though I'm thinking. Just painful to do the whole lot again.

Greg

Edited April 17, 2019 by Greg Hains
Clarification

[OlgerDiekstra]

15 hours ago, Greg Hains said:

Hi Olger,

You're right about being able to disable it and how it would defeat the purpose, but I thought maybe FM had a tool to reverse it - unless it is a one way process - which would make it extremely secure.

I would not be happy (and a lot of people with me) if that were the case. If FM had a tool to reverse it, it would only be a matter of time before hackers (or the NSA...) have duplicated the tool. This is what the entire encryption discussion is about (the encryption law in Australia, and law enforcement in other countries) wanting access to encrypted data, so called for protection of the public against terrorisme etc, but overlooking the fact that no crim or terrorist in their right mind would use any encryption that the government has access to. With all the open source code out there, they can easily create their own encryption the government cannot crack.

Unfortunately, without the right password, there's no way to gain access to the file again afaik. That's the trade off with EAR. It ensures no one can read your data, but if you loose the password, you're stuffed unless the DB is still running on your server. I'm sure you're not the first to be bitten by this. It would be nice to have a way to gain access again, perhaps using a similar method like with security questions, or perhaps sending a message to a preconfigured mobile or email.

[Greg Hains]

Hi Olger,

I completely agree with you re the security - no problem with that at all. Just be nice if there was a method to recover or reset it.
I rarely forget or misplace passwords, but I'm only human after all - unless this is a file corruption thing.

Problem was after FMI rebooted (required updates) the file wouldn't even open up on the host - reporting that the encrypted password was wrong. All other files were fine. FMI did report errors after that reboot and said that some service wasn't running and it took a minute or so before it worked - I was worried at that point!.  The files that were open prior to the reboot all came back up automatcially, but just not this one - so I am not sure what went wrong.
The file was open and working prior to the restart of FMI, it just wouldn't open up afterwards.
I'm not suggesting it was FMI's fault, but something broke during that process for it not to open it. Something in FMI must be looking at the encryption password in the solution to see it as incorrect/wrong - so the point of reference (FMI) and/or the solution must have changed for it to break.
This is the question I have put to FM. They have been really helpful and are looking into it.

Cheers,
Greg

[Josh Ormond]

On 4/17/2019 at 10:37 PM, Greg Hains said:

I completely agree with you re the security - no problem with that at all. Just be nice if there was a method to recover or reset it.
I rarely forget or misplace passwords, but I'm only human after all - unless this is a file corruption thing.

If there was a way to decrypt the file, it would severely weaken the security provided by the encryption in the first place. Because, essentially anyone could reset it then. It is obviously not a one-way process. Just nearly impossible without the password. 

Now, corruption. That could be a possibility. Is there anything running on the server that hits the live files? Backup utility, Anti-Virus, 3rd party file sync utility?

Di you have the backups from when you originally turned on the EAR? Does the password work with those files? Does someone else have access to open the file with FMPA? Either in the server with Full Access or direct physical access to the server?

[Greg Hains]

Hi Josh,

Thanks for responding.
Yes, I understand how that any tool that can break the encryption password may defeat the purpose, but thought that FM may offer a service. I cannot categorically 100% say that it is corrupt, but it was only a problem after an update on FMI/AWS. That instance does not allow any other tools that may interfere so I am at a loss as to why it happened.
The encryption occurred early in the solution development when I uploaded the file to FMI and has not been closed until this update occurred, so the backups that are there also fail to open. As the file worked until the closing and update process, it points more towards the password I supplied being wrong - as opposed to a FM fault. Either way, it is frustrating and wish there was a way around it.
I thank everybody for their comments on this. I've mostly redeveloped the solution (with improvements!  ) so let's look at dark clouds with silver linings.

Cheers,
Greg