Jump to content

This topic is 7191 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Can anyone give me an idea of how I can use a calculation field in FileMaker to produce an encrypted password field i.e

The user has to create a password in a normal text field.

The user then has to give a 3 digit number.

Using these two bits of information you calculate an encrypted password that

you store in a normal text field.

i.e. user password x 3 digit number = Password stored in FM

When the user logs back in they have to type in their password and 3 digit number to decrypt the password and give them access to the system.

Not ideal but it might get us out a hole we're in at the moment.

Thanks in advance for any help

Andy

Posted

The function only needs to be able to encrypt, not decrypt. When the user creates the password, your function encrypts and stores it. When the user logs back in, the user enters the same data, and the function encrypts it and then compares the encrypted result with the stored encrypted password. If they are the same, the user gets in. If they are not the same, then obviously the user entered the wrong password. This is the basis of one-way hash functions, and is how Filemaker 7 handles security. It avoids the risk that someone will figure out how to retrieve and decrypt the stored passwords.

You can use the free encryption plug-in from Protolight software to do this, or create a native Filemaker text calculation that thoroughly garbles the input.

Here's a link to a sample file that does this kind of encryption:

http://www.fmforums.com/threads/showflat.php?Cat=0&Number=68165&an=0&page=1#68165

Posted

Thanks Bob I think that might do it. The reason I'm asking the question is we're a UK company that has recently been taken over by a US firm. We have the SOX people auditing us and they weren't happy with the fact the developers (me) and the Systems manager could go into FM and view all the users passwords.

Cheers

Andy

Posted

You may want to do some reading up on Sarbanes-Oxley. For example, the actual law does not even contain the words "password", "encryption", "network", or "computer" in any form. It's all about establishing controls over accounting practices.

Soapbox.gif

Like all attempts to legislate best practices, Sarbanes-Oxley is part good idea, part total screwup. And like all sweeping legislation enacted across entire industries, it has spawned a wealth of misinformation, paranoia, and nonsense, and generated a cottage industry of consultants and "experts" who are happy to paraphrase freely available public information, put it in a pretty binder, and sell it to you for $499.

Despite the spin presented by so-called consultants eager to cash in on the latest Federally-mandated bonanza, Sarbanes-Oxley does NOT require heroic, cutting-edge high-tech solutions. What it does require is policies, and lots of documentation, logging, and reporting to show that the policies are actually followed. If you keep logs of accesses to the database, and the logs are regularly reviewed, that's a much better SOX compliance measurement than the specific technical details of one software package's user authentication method.

The real question is why your auditors were not happy with you being able to see the passwords. Was it because they are concerned that the same passwords might conceivably be used in other places, so your knowing them might give you access to something else? Or was it because they are worried about the developer being able to tamper with the data? If it's the former, setting up a custom login system may help. If they are worried about the latter, a hash is useless, because the developer can simply bypass the code that performs the authentication. For that matter, the developer could insert a keyboard sniffer routine into the program and capture passwords for other applications. With all due respect to the auditors, if you don't trust your developers and network administrators even that much, you have MUCH bigger things to worry about than SOX compliance. crazy.gif

There's nothing unique to FileMaker about this, other developers are facing the same issues. My guess is the auditors are fairly clueless about software development, and are mostly working from a powerpoint presentation and a lecture. You may want to talk to your auditors about "compensating controls." That's a compliance buzzword that basically means there's more than one way to skin a cat.

For example, if your FileMaker database is sitting on a public computer that anyone can walk up and use, and you rely exclusively on FileMaker's built-in security, you've got a huge problem. But nobody does that.

Users should have to log into workstations and servers before they even get to the point where they can launch an application. All of this is loggable and traceable. If your FM database is single-user, and you have to authenticate to a server to get access to the file itself, you've already met the requirements before you even SEE a FileMaker dialog. If you're using FMServer, you can restrict access by IP address, you've got logs to show who connected when, and that's before any more detailed auditing features you add yourself. For more control, you can hide the existence of the files on the FM Server, and create a per-user "loader" file stored in a secure folder that opens the server files. If you can show the auditors that access to the database is limited by other means, and the FileMaker password is simply an additional layer of security, that may calm their fears.

Posted

Thanks for your contributions. The auditors are unhappy for me and the system manager to see all user passwords because they think that we could enter the system appearing to be another user and make changes thus circumventing the audit logging. They don't seem to realise that whatever security I put in place I will always be able to get around it because I have the unlimited access to our FM system. Bob's encryption method is great and could get us out of a hole, but we're looking at another solution that pleases the SOX auditors, but ironically makes our system less secure. We're on a tight schedule to pass the audit so the quickest and dirtiest solution is going to win. After we've passed the audit then we'll have to review our system. I suspect by this time next year we'll be on FM 7.

Thanks for you time.

Regards

Andy

Posted

I let the SOX consultant have a read of your view point (hope that's ok, and I agree with what you're saying) this is what he had to say:

"I'm attaching a couple of articles. The first addresses one of the items the author of the email brought up. It's true that the Sarbanes-Oxley Act is a few sentences; encryption isn't mentioned. But SOX isn't about encryption, or any other technology (as the article points out). It is about security. Security at ****** will be quite different than it is at HSBC; or the military. It will take judgment on how much is enough, or how to obtain it....for ******.

Security can involve detection and prevention of wrongdoing. If a person is denied access to an application; that's prevention. A log does you no good if they're not reviewed, and even then, that's detection. But if you miss the item on the log, and one might because of volume, then the wrongdoing isn't detected or prevented.

The second describes the scrutiny we're all under. Companies are under scrutiny by auditors, and auditors are under scrutiny from PCAOB (Public Company Accounting Oversight Board) to perform responsible audits. And PCAOB is probably scrutinized by the Security Exchange Commission. The implication of a failed audit is that the company must disclose, in their annual report, the fact that their external auditor found material weaknesses. That disclosure would affect investors in a very negative way."

Posted

This is a perfect example of why auditing of specialized environments by people with only superficial understanding of the subject is always problematic.

The auditors are operating under a serious misconception. They appear to believe that passwords in FileMaker establish identity. This is NOT true. Passwords as implemented in FileMaker 6 and earlier do not verify identity, they ONLY control access. There is no connection between a FileMaker 6 username and a FileMaker 6 password. In other words, the FileMaker password does not determine WHO you are. It only determines WHAT you're allowed to do.

Mary can log in as user Mary with one password, perform a task, log out, log in again, still as user Mary, but with a different password, and get a different set of rights. User JOHN can log in with either of the same passwords, getting the rights that go with the password. Multiple people can log in with a single password at the same time. Calling them passwords is something of a misnomer, because they don't work like passwords in most applications. They are really more like security keys than passwords.

One thing you really need to point out to the Auditors is that your ability to manage the passwords is a critical part of managing the system, because it is ONLY through the use of these passwords that user rights can be controlled. You have no other way to manage rights.

Telling a FileMaker admin that they can't administer passwords is functionally equivalent to telling a network administrator that they cannot assign rights to users. Furthermore, in a multi-file solution, only a person in an administrative role can properly manage FM passwords. FM users cannot effectively manage their own passwords because each file maintains its own password set. Scripts can be used to automate password management, but again, this MUST be implemented by an administrator, so you're still back to having to trust someone.

Consider a business that only has one employee. Clearly it's absurd to require that one employee not to know his own password. Therefore, alternative control mechanisms MUST exist.

As previously mentioned, FM7 replaces this rather weird security model with a much more "normal" system, with actual user objects that have distinct passwords assigned to them. Users can change their own passwords without invoking scripts, administrators don't need to see passwords, and so forth. FM7 also incorporates other features to improve security in general, such as SSL encryption of network traffic, better encryption of data in the database files, etc. However FM7 involves a major shift in the file format, with changes to the basic design philosophy behind the program as well, and is not something that should be rushed into.

There is no reason why your FileMaker solution cannot be made SOX-compliant through the use of appropriate controls and policies. Your auditors are wrong about one other point. Sarbanes-Oxley is not about security. It's about accountability.

> "But if you miss the item on the log, and one might because of volume, then the wrongdoing isn't detected or prevented."

Of course, perfection is unachievable. But the purpose of these controls is not to demand perfection, but to minimize the impact of mistakes and make deliberate abuse difficult. You might miss an entry on the log, but the log itself is still there for review. If the log simply isn't there in the first place, that's an order of magnitude more serious.

For a "quick and dirty" solution, consider this:

The developers maintain a separate development copy of the database stored in a separate location, and are prohibited from using the production database at all (easily enforced by firewall, server configuration, leather whips, etc.) All changes are done on the development copy of the database. When changes must be rolled out to the production server, the developer does so under the auspices of a production database user and under direct supervision. Segregating production and development systems like this is a perfectly reasonable control.

If the need arises for the developer to work directly on the production system, he must first inform a manager of this need, get permission, log entry into and exit from the system, and provide a mechanism for a third party to monitor his activity.

> The implication of a failed audit is that the company must disclose,

> in their annual report, the fact that their external auditor found

> material weaknesses.

But that's the whole point. They aren't material weaknesses if they are compensated for by additional controls. There's nothing dodgy about what I'm describing, it's perfectly reasonable. See ISO 17799, Cobit, etc.

You may want to visit the ISACA web site.

https://www.isaca.org

You can create a basic account for free, which will give you access to a fair number of publications, including the COBIT Security Baseline, without having to pay for a membership.

I wish you lots of luck.

smile.gif

This topic is 7191 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.