[EMAIL PROTECTED] wrote: > Thank you Joseph and Motherofperls for your tips, however I need something more than > security through obscurity, as this database is going to store our customers > personal information (real name and contact information) which is absolutely > unacceptable to be stored in such an insecure manner (we cannot risk being sued or > loosing our customers and of course I most definitely cannot knowingly introduce > such a serious vulnerability being responsible for that website). > > I cannot depand on attackers not finding the database password which is stored as > cleartext in a world-readable file while its path is included in the script source > (or even if it wasn't included anywhere, for that matter). > > Even if it is group-readable for a group which the httpd process belongs to, it is > actually not any more secure and only adds one simple step for attacker to access > the file with a CGI script by exploiting any script from any website on the server > or using any user account which can modify any one of those webites, so I'd say it > is basically world-readable on a server where I am not the only one who has a > website. > > What I need is a secure way of doing it and I'd like to know how the experienced > Perl developers solve this common problem. It'd be somehow hard to believe that > people actually store sensitive data in production environments in such a way which > allows full access using the most trivial web attacks and even without any need of > attack at all for everyone with a website on this server, even without the shell > access. > > I hope someone who has developed any real production system could answer my question > or even just tell me to RTFM while kindly pointing me to the right FM, because to my > great surprise I couldn't find anything in perlfaq and any other Perl documentation > or books I've read. > > Thanks a lot. > -Zedgar Z.
Okay. In short, you probably can't do it all in Perl. Somewhere you have to have a compiled object holding your hashing algorithm. Any plian-text algorithm can be cracked. Ultimately, anything can be cracked. Here is the logic for your algorithm: Pne way: Have some large and obscure prime number for a key. Bury this number, offset by a few bytes, deep in a file of garbage. For each character of text to be protected, pick a random number and multiply the key by this number. Do something tweaky, but reversible with the character [perhaps map it through a simple translation table] Add the characters tweaked value to the prime/random product. Store this, offset by a different number of bits than used for the prime key, in some other file of garbage, or in a diffeent offset in the same. To decrypt, get the stored value[ each character probaly stored as some fixed-length, but large integer data.] Take the moduls of each integer value and untweak it to get the original character. The problem of the above is that the password gets decrypted. Another way would not ever require decryption. First tweak all characters, say through a substitution map. Then apply some hashing pattern to the string as a whole. A very simple one would be to multiply a running sum by some number greater than the size of the set of allowable password characters then the tweaked ordinal of the next character. Store the resulting number as the hashed value. Never try to decrypt the stored value. Simply hash each string offered in the same manner, and check to see if it renders the same value. Those are two hand-hacked approaches. Either would make a crackers work difficult. Neither would make it impossible. Another possibility, since this sounds like it involves some money, is to simply buy a third-party RSA encryption application, and have your scripts call this to verify passwords. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
