Encrypted Custom Login without Plug-in

[CobaltSky]

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!

[BobWeaver]

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.

[CobaltSky]

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!

[cdr-dev]

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

[SteveB]

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

[cdr-dev]

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

[SteveB]

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

[Munchie]

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.

[Vaughan]

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.

[Munchie]

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!

[CobaltSky]

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.

[Vaughan]

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?

[Munchie]

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

[Vaughan]

Thanks for the clarifaction Ray!

What are the Patriot and Gramm Bliley acts?

[Munchie]

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

[CobaltSky]

Would you recommend something like Troi's Coder plugin?

Hi Muncher,

That would be one option, but there are a few others including one which is commercially available from my own web site.

I didn't respond to this thread with a view to trying to sell you anything - but since you asked...

[Computer Geek]

I've recently been told by another fM developer that with FM 7v3, it is no longer possible for the programs like passaware to use the brute force method to overwrite the passwords. Does anyone know if this is true?

[CobaltSky]

I've recently been told by another fM developer that with FM 7v3, it is no longer possible for the programs like passaware to use the brute force method to overwrite the passwords. Does anyone know if this is true?

Hello Computer Geek,

The way you've phrased your question appears to confuse two disparate concepts.

'Brute force', in the context of cracker tools, generally refers to a process of trying all possible password combinations in an effort to find a password that works. Overwriting the passwords, on the other hand, is a technique that a cracker tool may use in order to avoid resorting to brute force.

I believe you will find that the program you refer to is provided in a free demo version which uses a brute force approach, but is limited to passwords of two characters, whereas the registered version works on an entirely different principle by overwriting the password hash. Both versions 'work' (to the extent that one might regard either method as working) on 7.0v3 files.

But leaving the details aside, and however one interprets your question, I'm afraid that the answer is still going to be the same - ie no, it is not true...

[Computer Geek]

Ray,

Thanks for the clarification on question. I suspected that passaware still worked on version 3 ... disappointed ... not surprised.