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

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

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.

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

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

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 ?

>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.

>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.

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 ?

>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).

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.

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.

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

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.

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!

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

Firstly, don

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!

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

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.

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")

Dj,

I'll email you my findings on FM security.

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.

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.

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....

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.

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.

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

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.

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

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

Attached is a screen shot.

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

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.

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

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.

Hi Bob

I found this thread an interesting read, and aspects of what you have developed chime in with some of the work I've done in recent years in the development of native FMP encryption systems.

In fact, I have two FMP encryption products (both shareware and both offering native FileMaker encryption) slated for release within the next couple of weeks, each of which provides options which could be seen as complementing what you've offered here.

I have had a look at the latest version of your file and can confirm that the basis and approach of the one-way hash methodology is sound, and has a number of potential applications in the validation of data - not limited only to passwords. Such systems have a good track record in their ability to withstand brute force attack, although there is a theoretical weakness in that hypothetically, more than one string (eg password) can engender the same stored hash sequence. Since this is random, some passwords will be more resistant than others to bfa, and users have no way of knowing when they choose a password, whether it will produce a hash string which is unique to that password or whether there may be numerous other possible passwords which would match the same hash. Being open ended, it is even theoretically possible (though astronomically improbable) that two users might choose passwords that were effectively interchangeable from the point of view of the system.

However the risk is scarecely a practical consideration in this case. In a sense, what you have produced can be viewed as a very sophisticated checksum, and although all checksums inherit that same weakness, the sophistication of yours is such as to reduce the risks enormously. As a result, I believe that the formulation you've arrived at is sufficiently robust that any considerations of this type would be marginalised, and even the least secure passwords your system permits would be offered good protection. As you say, nothing can ever be regarded as absolutely secure - and after all, the aim is to ensure that passwords are sufficiently well protected that they are no longer the 'weakest link in the chain' where security is concerned. I believe the design you've published here offers a substantial step in that direction.

Moreover I like the flexibility your solution affords. I think that there is another advantage of your solution over David McKee's freeware plug-in (and I'm confident that David would agree) in that yours will work across platforms, whereas in its present form, the Protolight plug-in cannot decode cyphers that were encrypted on the alternate platform - so in that sense it is not fully cross-platform, whereas what you have developed is.

That is not an issue with the Troi Coding plug-in which is more truly x-plat. However the other considerations you've already mentioned do apply there also (and price is also a factor...). The format of encryption that both plug-ins offer is, of course, suitable for a range of other purposes that one-way encoding does not lend itself to, so an awareness of all the available options is the best approach.

Your work on this method, and your decision to make it available here helps to raise awareness of security issues, as well as providing part of the means to address them. In both senses, a positive contribution to the FileMaker community!

Ray,

As you have pointed out, the main theoretical problem with this system is that two legitimate passwords could generate the same hash code. Since the hash function generates a 10 character code using a 36 character set, the number of possible codes is 3.66x10^15. Hence, the chance of creating a password that has the same hash as an existing one is 1 in 3660000000000000. And, since both the password and user ID/password combination are hashed to produce two 10 character codes (total of 20 characters), the chance of creating duplicate set of hash codes is actually one in 1.34x10^31, which should prompt the hacker to look for an easier way to get in. (This assumes that the hash function has an equal probability of generating every code. I don't have the mathematical skills to test this though.)

In any event, when the user creates or changes his/her password, the script could confirm that the hash code doesn't already exist in another record, and if it does, prompt the user to select a different one. A nondescript message like "Sorry that password is not secure; please select another," could be displayed without alerting the user to the actual situation. If a user accidentally did select the same password as another user, this would not necessarily be a problem anyway. It would hash to the same result as the other user's password, but the combination hash code generated from the password and the user ID would be different for each user. So, there would be no confusion as to who is logging in, or what access priviliges the user has.

The biggest practical risk is still having someone use the hash function to create a bogus password and somehow create a new user record with it, or replace the hash in an existing record. I believe that I have sealed up those cracks in the last version that I posted. While it won't withstand an attack with a hex editor as Dj showed, neither will FileMaker's built-in password system.

Hi Bob,

Let me first say that I agree with the general thrust of what you are saying - ie that the number of combinations is large enough to reduce the probability of failure to levels which are acceptable. And more to the point, to cause hackers who do their sums to give up and look for security weaknesses elsewhere.

In light of that, my comments are not a critique of the technique your file exemplifies, but are directed at the larger questions about security and secure methods of deployment, which I think will come to be of increasing interest and relevance with changes to FMs security architecture in future versions (assuming the the folks at FMI have been listening to various public debates on the subject...).

Interestingly, the issues we've touched on about the theoretical flaw with one-way encoding is not quite as you've described it in your previous post. Ie, the probability that a password shares its hash with other passwords is not able to be extrapolated from the number of combinations that the system permits, and is considerably higher than those figures would suggest.

Whereas there is only one hash for any given password (which is why the system works), there can be anything from zero to millions of possible passwords that match a given hash. This has two implications:

1. There may be many possible hash combinations for which there are no possible passwords (thus reducing the number of hashes that can be generated from entering a password to an indeterminate number which is less than the number of possible has combinations). This number can be determined using a recursion based on exponent reduction theory. Although I confess I haven't actually done the sums on your system, based on other such systems I've seen, I'd expect the number to fall out somewhere around half (which is still enough to frighten hackers into looking elsewhere...).

2. Since the relationship between hash strings and passwords is close to random (ie it is sufficiently complex to engender 'threshold' behaviour as described in chaos theory) there will be a distribution of hashes (from among those for which there are matching passwords) between those which have a small number of matching passwords to those that have very many, with a relatively small number of hashes matching to quite large numbers of possible passwords.

The practical implications of this theoretical analysis are that:

A) the probability that a user will choose a password which happens to be associated with a hash string for which there are a very large number of other possible passwords is low, and

in the unlikely event that a user has unwittingly chosen a password that is one of those referred to in A above, the probability that a brute force attack on that user's account will yield a matching password is much (!) higher than the probability across the system as a whole.

In other words, the security of the system is not equally distributed across all passwords. Some passwords are much more secure than others and this 'bumpiness' is not visible to the users (nor one might add, to the hacker, which is something that one can take some comfort from ). If one takes the view that the security of the system is only as great as that of the weakest possible password, then one would have to account it as being many orders of magnitude less than 3.66x10^15. I don't take that view, exactly (I think that is being overly purist). But its security is not 'face value' either, and I think that is something to be aware of.

If it were possible to conduct a recursion analysis on the fly in order to deny passwords for which the corresponding hash had more then a given number of other associated passwords (or better still of someone were able to come up with a modelling device to do this), then the total number of hashes available would be reduced (as would the number of possible passwords), yet the overall security of the system would be improved. Strange, but true.

For my own part, I consider one-way encoding techniques to be an important tool, and have used it in conjunction with other techniques in my own work. As I said before, this has been an interesting thread, and I've enjoyed looking at what you have accomplished here. Thanks!

Not to get off the subject of your tool bob, but could you give a explanation as to how a plug-in like the Crypto Tool provides encryption? Does this tool encrypt the data that is transmitted to a database shared over the internet to and from the client? I am new to the encryption process and in process of learning about it.

Chris

This is kinda a dead old thread. The Crypto plugin requires a 'key' to form an encrypted string of differing strength depending upon what your require. RC4, the lowest level is pretty effective. In order to decrypt it, you would have to use the same 'key' that it is encrypted with. For example, you could make up a key of 'C1h2r3i4s5' (always a good idea to mix letters and numbers. If you took the same information and changed one of the characters in the key, the result would be totally different. If you attempt to decode a string with a

different key than was originally used, the result will be garbage, not just a differnt result.

RC4 returns 2 characters for everyone in the original string. The Crypto plugin can also return RC6 (I assume 3 chars for everyone input)and DES which successively return stronger encrypted strings. I believe that the DES is 128 bit excryption, but I'm not positive.

Just remember that you'll need the same key at both ends or you'll get garbage.

Steve

Thanks for the response Steve! I understand 90% of it, the 10% I don't get is the "key" part. Where does this "key" reside? Is this the password creation? How does one set this up? Thanks again!

Chris

Before you try to encrypt a string, there is a call to the plugin called

"SetKey" and it looks like: External ("crypt-SetKey", "C1h2r3i4s5"). If you're going to encrypt multiple strings in the same session, you only need to call "SetKey" once (unless you want to change the key). So, everytime you start up, call the version paramter, call SetKey, and then whichever encryption strength you want. It's easier to do than it appears.

Steve

I realize that this thread is old, however, I would be interested in hearing what Bob and Ray think of the new security in FM7, as it relates to the issues brought up in this thread.

I found a program that will decode FM7 passwords, rather quickly.

Passkey systems makes a program that does this. The demo version only returns the first character, however, it does it like it's reading it, so I'm guessing the whole password would be available quickly.

In FM7, it provides the user name as well.

Thanks for the heads up on all of this stuff.

One such FMP 7 password cracker was discussed a couple of months ago.

This particular program could not "decode" FMP 7 passwords because only the #hash# of the password is stored in the file -- not the password itself -- and the hash has been strongly encrypted.

Reports stated that the "demo" and the full versions operated quite differently. It appears that the full cracker uses a brute-force method whereby it blindly over-writes parts the FMP 7 file data to replace the hashed password with the hash of a known password, then opens the file with the known password. This is not the same as "decoding" a password. It isn't picking the lock; it's knocking down the door and erecting another door fitted with a lock that we have the key for.

So yes, such a program may allow the file to be opened. However it cannot "decode" or extract any passwords from the file, and it may damage the file in the process.

Is is a very different situation from FMP 6, where it was apparently relatively easy to extract passwords from files.

One last comment though: password cracking of both FMP 6 and FMP 7 databases requires *physical access to the files*. If people do not have file-level access to the databases they cannot crack them using these tools. Removing file-level access is as simple as hosting them on a FM Server running FMP or FMS.

Thanks Vaughan,

Makes me feel better about using server.

What about security in a bound runtime solution? Would this require that I copy my solution, remove the all access password, and then compile it? Is the security issues discussed apply to these solutions as well?

Thanks again!

Vaughan wrote:

One last comment though: password cracking of both FMP 6 and FMP 7 databases requires *physical access to the files*. If people do not have file-level access to the databases they cannot crack them using these tools. Removing file-level access is as simple as hosting them on a FM Server running FMP or FMS.

Hi Vaughan,

While this may be true in relation to some specific cracker tools, it is not a safe assumption in respect of FileMaker 6 files. Ie it *is* possible to retrieve and reconstruct the passwords of a FileMaker 6 solution which is remotely hosted. I don't propose to explain how on a public forum, but suffice to say it has been done.

The same is not true, however, of FileMaker 7 files - and AFAIK there is no vulnerability of this type with v7.

Munchie wrote:

What about security in a bound runtime solution? Would this require that I copy my solution, remove the all access password, and then compile it? Is the security issues discussed apply to these solutions as well?

Hi Munchie,

Yes the issues discussed above do apply equally to stand-alone and runtime solutions.

At the very least, a runtime solution should have developer access removed - and this is an option provided during the binding process, by the FileMaker Developer application. However this may protect the developer's copyright (at least as far as the code goes) but does not protect the data from intrusion using cracker tools.

Other steps should be taken in development to secure a solution, where the data is valuable. These would include systematic scripted security, internal encryption of sensitive data and the use of third party tools and techniques to enhance security.

I've never made a runtime. Others will have more direct knowledge.

But what security do you mean? Protecting your intellectual property (as developer) with regard to the solution's programming; or the end-user's data?

Would you recommend something like Troi's Coder plugin? Or would it be better to learn the types of encryption that Bob was demonstrating at the beginning of this thread?

I'll be honest, I've become paranoid about my data ever since I read this thread.

I

Thanks for the clarifaction Ray!

What are the Patriot and Gramm Bliley acts?

What are the Patriot and Gramm Bliley acts?

Without saying what I think about the acts; The Patriot Act parts that I a concerned with have to do with making positive identification prior to doing any kind of "Financial" transaction. Financial referring to Mortgages, securities sales, ect.

The Gramm Bliley Act is a privacy act. If procedures to protect personal information are too loose, the government will come down on the violator with a giant fine.

How that applies to what we are talking about, is to conform to the Patriot Act, we have to keep some ultra sensitive data in the file. For Gramm Bliley, we have to protect that sensitive data from intrusion.

This link with take you to info about the patriot act from the ACLU