I'm not sure of the complete extent of applications written in Omnis, but from what I understand, it's a multi-platform Rapid Application Development environment. Essentially, from what I understand (having no personal experience with the product), you create one program in Omnis, and it's portable to Win, Mac, and Linux. I am admittedly rather uninformed of the full uses of Omnis, but what I do know is that it can provide a interface to databases of differing formats, including ODBC connections. Please, some of what I say is speculation based upon facts that I do have about the software, if someone can shed more light on the subject, do so. Sadly I have little time to really work with the Omnis application point. One of the features that Omnis provides for attaching to the database is the ability to encrypt fields, and obscure them from prying eyes. In actuality, this encryption is extremely weak, and I /accidentally/ discovered the encryption technique in attempting to help a company that develops with Omnis strengthen their program security wise. The specifics of the weakness of this encryption is discussed at the end of my post. For the past two weeks, I've been helping Clients and Profits (C&P), developer of a job tracking and billing system targeted to marketing corporations, to fix a security bug in their program wherein any user with access to the database (which was any person who was allowed to log in to the database, as well as potentially others) could gain the passwords of all users, including the managerial accounts, thus exposing vital information such as job estimates and employee salaries. It was only recently that C&P divulged to me that they used Omnis to develop their application, and thus my lack of experience with Omnis. Details of the C&P vulnerability are at the end of my post. A week ago I put in a request to Omnis for technical support on this issue, so that I could help them come up with a more effective encryption technique for encrypting data before storing to the database. As of yet, I have not even received a "Thank you for your request" email. -----The Omnis problem----- The technique used by Omnis to "encrypt" data is weak enough that it can easily be decrypted with a hand calculator, and for those with extensive hexadecimal experience, and good ASCII knowledge, performed in your head. Just for a bit of fun, bugtraq readers may find it enjoyable to see how quickly they can figure out the encryption technique before reading the rest of my post, call it Eric's game of the day. Here is a password: encrypted Here is its encrypted form: bec4b3b9d2c6c4acbd If you want to play with that, don't read any farther until you've figured it out (it won't take you long) It is almost immediately noticeable that the encrypted password is actually a hexadecimal sequence, or very likely that it is. There are no letters above E, and especially, none above F. If you break it down by hexadecimal pairs, and line up each with a letter of the original password, you get e n c r y p t e d BE C4 B3 B9 D2 C6 C4 AC BD Seems to be a good match for the number of letters. Let's get numeric values for each now: 101 110 99 114 121 112 116 101 100 190 196 179 185 210 198 196 172 189 If you're reading this with out having tried to decrypt it, you should almost at this point have accidentally decrypted it. If you take the difference of each of those value pairs, you get 89 86 80 71 89 86 80 71 89 or 89 - (3 * ((charpos - 1) mod 4)) To confirm that this wasn't just a fluke, I got ahold of three other encrypted passwords to which I did not have the original value, and successfully decrypted all three to their original values. According to those with whom I've spoken on this matter which know more about Omnis than I do, this is the only encryption option available. -----The Clients and Profits Problem----- The C&P vulnerability exists because core functionality of all versions of their software aside from the most expensive SQL version (which attaches to Oracle) requires a shared network path wherein the database sits, and this is how all clients access the shared database. Users must have full read/write access to the database (which is in and of itself a very weak design, there is no client/server role here) in order to access it. Any user with a hex editor needs only open the database and conduct a search for the username for which they wish to gain access. The password will be contained within about 500 characters, and will easily stand out, unless a very clever password is used. In all versions prior to 4.02, the password will be contained in plain text. 4.02 and later versions will have the password encrypted in the method described above, making even the most clever password easily distinguishable. I had been working closely with Clients and Profits up until nearly the same time that I attempted to communicate with Omnis regarding this issue. At that point, all my C&P contacts stopped responding to my via email or phone. -Eric Stevens hope this helps