Encrypted Custom Login without Plug-in

[BobWeaver]

Here is a sample login system that I discussed here

As presented, it isn't really a complete login system. It's just an example of using a one-way hash function to encrypt passwords. The included notes give a bit more information.

login System.zip

[cjaeger]

Good job. I am not a cryptoanalyst, so don't expect me to crack the password.

[BobWeaver]

BTW, the actual file passwords are 'user' and 'developer' but that shouldn't make any difference. The login user ID's and one of the login passwords are given in the notes file.

[Lee Smith]

Hi Bob,

Thanks for sharing, I love the OS X look of your interface. If Apple and FileMaker ever get everything work harmoniously, I will upgrade someday.

Thanks again,

Lee

[BobWeaver]

Interface is compliments of www.layoutmode.com more or less.

[mse]

It seems make no difference, I am afraid.

The encrypted usernames and passwords are stored and they are easily accessible

6CX765RREI FIWZSS9UE6

JTNTZ1W6UB 4JGSW612MT

7LSKGLC15D 976I1RKO5D

as well as the encryptation algorithm. So...

Am I missing something ?

[cjaeger]

>The encrypted usernames and passwords are stored and they are easily accessible

yes, you can get those with any text editor

>as well as the encryptation algorithm

no, unless you are logged in using the filemaker developer password.

Try to uncover passowrds & reverse engineer algorythm knowing the user password only. Also take into account that malicious third parties usually have to get hold of user password first. That may prove as difficult as getting the dev password since users do not know that password.

[cjaeger]

>The encrypted usernames and passwords are stored and they are easily accessible

yes, you can get those with any text editor

>as well as the encryptation algorithm

no, unless you are logged in using the filemaker developer password.

Try to uncover passowrds & reverse engineer algorythm knowing the user password only. Also take into account that malicious third parties usually have to get hold of user password first.

[mse]

Do you think I've read the Notes.pdf first ?

Nope, it was a net, one minute long, test.

Anything is transparent...developer, user

As to decryptation - do you believe in arithmetic ?

[cjaeger]

>Nope, it was a net, one minute long, test.

>Anything is transparent...developer, user

Does that basically mean you can crack ANY password-protected FileMaker database in a couple of minutes?

Sure you could use a brute force attack on the custom usernames & passwords generating a word list on each. But you still have to test them using FileMaker, and that slows down a lot. (especially if uname/passwords behind 6CX765RREI FIWZSS9UE6 is something like

8DJKSHWZE3 4562GDOWKD).

[mse]

In direct contact with a file: Yes. Unfortunately. And not by brute force attack. That is trouble me.

Meanwhile, I am not a hacker or even an experienced FileMaker developer. Ask DJ for more details.

TMO, there are several scenarios which should be considered:

1. DB is deployed on a distant server, User (hacker) have neither account nor "contact" to it.

2. DB is deployed on a distant server, User have an access to it, but not a "contact" to a files.

3. DB is deployed locally on a workstation, User (hacker) have no account on it.

4. DB is deployed locally on a workstation, User have an access to it.

The last two are related to the developer's intellectual property protection problem.

[BobWeaver]

First of all let me reiterate. This system not fundamentally different than any other custom login system, other than the fact that the user ID's and passwords are encrypted. If you were using a custom system without encrypted passwords, there would be one less obstacle in the way of the hacker. Plus, the unencrypted passwords would be passed over the network where they could be intercepted. Filemaker's own built-in password system is definitely the best method of securing the files. I was just giving this as a method of making a small improvement to custom login systems which tend to be very insecure.

Dj contacted me by email and pointed out a weak point in my system. It doesn't involve decrypting the passwords or user ID's because that is not possible except by a brute force attack (unless someone can find a flaw in the one way hash function). It involves getting access to the files (using documented Filemaker security flaws) and creating a new fake user ID and password, and then signing in with these. This is actually the type of attack that I had been most concerned about. I haven't had a chance to analyze in detail what Dj did yet. It's possible that he may have used an attack of which I'm not aware. I don't claim to know them all. I still need to check out just how much information a hacker would need to have about the files to hack the system this way.

You *should* read the notes file, because it mentions some things that I deliberately did to this example to make it easier for you to experiment with, but also make its security weaker. These things would be removed in the deployed solution.

BTW, in an UN-encrypted custom login system a hacker could use the same methods to directly create a fake user ID and password, and then use that to log in. They wouldn't even need access to the encryption keys used by the hash algorithm since there would be no encryption.

[BobWeaver]

I've decided to revise and repost this sample file. It is not fundamentally different from the original, but I made a few small changes which should prevent the type of hack that Dj did on the original file. BTW, thanks Dj for taking the time to analyse/hack it. I haven't included the developer password in this post. I will post it in a few days, after giving the hackers time to have a go at it.

For those who want to try to break in, the goal is to get the file to think that you have legitimately logged in by getting the dialog box that says so (not the pseudo dialog box on the main menu layout), or by determining one of the existing passwords. While you can possibly do other things with the file to gain information, it won't necessarily be significant, because this isn't a complete solution. There is no actual data to protect. And that brings up an important point. There is no use having a very secure Login file when the rest of the files in your solution have security flaws that allow hackers to attack them directly without even going through the login procedure. Therefore, everything in the solution needs to be carefully designed with security in mind.

Have fun.

login system.zip

[mse]

No difference. Breaking in a server hacker grabs a master password to a Login.fp5 file (s...i...i), opens the file by linking to script, and recovers stored User ID's, Passwords (from a User List)

8VZNHKDH4H 0L12ELFEH9

0GJKCI97W7 2KXVVV9RCO

3P62OLJFXW EOM74QL27X

as well as the encryption algorithm. Point.

[BobWeaver]

Okay, now that you have 8VZNHKDH4H 0L12ELFEH9, what can you do with it? You can't decrypt it, and you still can't log in. If you can, then do it! Point!

[BobWeaver]

I suppose I should follow up my last flippant remark with a bit more discussion, because there seems to be a misunderstanding here. I had never assumed that it would be difficult to get the encrypted passwords out of the file. That is the very reason that it was encrypted in the first place. By encrypting it, it becomes useless to the hacker. MSE assumes that by getting this data, and knowing the algorithm that was used to generate it, that it is a trivial matter to create an inverse function to decrypt it. Not so! That is the whole point behind one way functions. They have no inverse. I didn

[mse]

Firstly, don

[BobWeaver]

No offence taken, but mathematicians much smarter than either of us have based the entire theory of secure internet connections on one-way functions. You don't have to believe me. There is a lot of well respected literature out there that covers this subject. One-way functions do exist.

And, I don't mean to say that the hash function I put into the sample file is unbreakable, but I don't think anyone on this forum (unless there are some professional cryptographers lurking in the wings) would be able to break it. And yes that is a challenge. If someone can break it, I would like to hear about it. This is the only way that you can really test the security of any system, post it for everyone to see and let them try to break in.

Recommended reading: Applied Cryptography by Bruce Schneier, a very interesting book which is not aimed at mathematicians.

P.S. I enjoy a good argument!

[djgogi]

Hi Bob,

I didn't have time to play around with your files, anyway here is an "solution" I've decide to post since it's implementation (and creation) in real hosted solution could be, in some cases, very difficult.

There is, also, an other solution that I won't post here.

To login use just any name and password (except empty values)

Scripts Unlock and Abort are enabled now.

Until next update

Dj

Broken.zip

[BobWeaver]

Dj:

Very interesting. I see that you managed to get inside the login script and change

"Status(CurrentFoundCount)=1"

to

"Status(CurrentFoundCount)=1"

It seems that Filemaker security is an oxymoron. After the discussion with MSE, I decided to do a bit of experimentation to see just how secure Filemaker's *own* built-in password system is. It took me about an hour to set up a sample file and then retrieve its encrypted passwords. It took about another hour to figure out their encryption scheme, and then only a few minutes to work out a technique determine the original password. I won't say any more than that, but I highly recommend that anyone sharing Filemaker databases over a network, should make sure they have a good firewall, and that anyone with access within the organization is trustworthy.

[djgogi]

The general problem with interpreted languages.

Add the fact that FM is "transfering" entire file structure (data + metadata) from host to client...

The result : All your scripts, calcs etc are open source.

Now that I see that you see (remember CuCMe) , let me add something else:

Given an valid IP number and valid file name, there is nothing that could prevent ( firewall a part) the opening of hosted file (using only FM) even if it's hidden by server.

Dj

PS

Check also

PatternCount(Status(CurrentGroup),"one")

that became

PatternCount(Status(CurrentGroup),"one")

[BobWeaver]

Dj,

I'll email you my findings on FM security.

[kennedy]

Given an valid IP number and valid file name, there is nothing that could prevent ( firewall a part) the opening of hosted file (using only FM) even if it's hidden by server.

Not sure what you said... but I am concerned about what I think you meant!

Are you saying that if you are on a network, with no direct access to the FileMaker files, but access to an FMServer that is serving those hidden files, that you can get a complete copy of those files?? Or are you saying that you can break FMServer's security and gain full access via FMServer?

As an owner of a database with sensitive data in it, this is obviously of great concern to me. Thanks for clarifying.

[BobWeaver]

Caveat: I'm walking a fine line here. I don't want to give out information that will help hackers break into other people's files, but I want to let you know how secure or insecure the system is. Pretty much everything I say here is information that can be obtained from FMI's own website (albeit with some reading between the lines).

Filemaker Server is a thin server. It doesn't perform any database functions. It just serves raw file data to the clients. So, if you are running a client copy of Filemaker Pro, or something else that pretends to be Filemaker Pro, FM Server will happily send you a list of all the files (including hidden ones, in an unencrypted format) that it is hosting. So, it's quite easy to get a list of all files that are on the server.

If your client then tries to open one of those files, FM Server will happily send you all of that file's passwords so that your client copy can verify the user's login. FM Server sends the passwords in a 'sort of' encrypted format, but the encryption is very weak. It took me a couple of hours to figure out the encryption algorithm, and another hour and a half (over the next couple of days) to sort out all the other details such as how to retrieve the complete set of passwords from any Filemaker database whether it's on a server or on a local computer. It's actually easier to get the info from a server.

Scary, isn't it?

PS. It was only the discussion on this thread that got me started on experimenting with this a few days ago. I think most FM savvy people know that there is a program floating around the internet that will retrieve the passwords from FP3 files. Since there was nothing available to get the passwords from FP5 files even though Filemaker 5/6 has been out for a few years, I assumed that FMI had improved their encryption technique so that it was too difficult to do. I guess I was wrong.

[kennedy]

Scary, isn't it?

Pathetic, actually. That definitely seals FMP's fate as a bottom-rung database platform.

And it also seals my current thinking that my customer-accessible systems will be on a separate network from my business systems... so that I have OS X authentication and security between customers and my FMS! Sheesh.

Hmmmm....

[Lee Smith]

Hi Bob,

On another list, someone posted a link to an application that will retrive passowrds from FM5 now. The good news is, you have to have a Windows Machine, and thank goodness not many people own one of those.

[BobWeaver]

Ha ha, yes hardly anyone uses windows.

Well, today I wrote a Mac application that retrieves FM5 passwords, but I won't be posting it anywhere.

[kyle]

hi, bob ! can you email me your email address ? i like to send you a file for some test. my email address is listed.

regards,

kyle

[BobWeaver]

I've sent you an email. You can send me a file if you like, but if it looks like it contains anything valuable, I can't give you any information about it. I think you'll understand that I have to do this unless you can somehow prove that the file truly belongs to you.

[kyle]

hi, bob ! of course. it's got nothing in it other than few words which if you get inside you will be able to see it.

regards,

kyle

[BobWeaver]

Well it was valuable. I think you owe me lunch.

Attached is a screen shot.

[kyle]

hmm... i thought you could do it. i thought there was a little detail in that and i wanted to see how good it was. now i know it is nothing.

thanks,

kyle

[flowe]

Bob,

I enjoyed this discussion and am new to software security. I thought about implementing your HASH solution. I was wondering can one provide the simplest programming solution and include it in the runtime executible without supplying the .fp5 file with passwords to be exposed.

[SteveB]

There is another alternative to Bob's solution: A free encryprion plugin exists and can be downloaded from www.protolight.com (David McKee's web site). The plugin can do RC4 and RC8 encryption. So long as users can't look at the encryption/decryption scripts and you don't store the key in a field, they will have a very hard time breaking in.

Steve

[BobWeaver]

Flowe, The point of using a hash function is that the passwords are never exposed, even if someone gets into the file by various illicit means. You can only ever see them in their encrypted form which doesn't do anyone any good. The unencrypted password only exists in the owner's head.

Steve, David McKee's plug-in is excellent, but I don't see that it offers any advantage over what I have posted here, for the simple reason that the keys have to be stored in the file, and a hacker could extract them. Of course you could use the plug-in to encrypt the main database data itself.

Remember, nothing is completely secure; you just have to try to make it as secure as you can, and as difficult as possible for hackers.

BTW, I never gave the full password for the updated sample that I loaded. It is "shinigami" if anyone is still interested. For your amusement you might want to compare its scripts to the ones in dj's hacked version that he posted, and try to find the differences.

Also, the sample that I posted has a script that creates new user accounts. In a full implementation of this, I would remove that script and create a separate administrator file that resides only on the administrator's computer (not on the server). That would prevent a hacker from triggering the account creation script using applescript etc. The separate admin file is the method recommended by Moyer and Bowers in their book.