Any reason why you need to have reversible encryption on the password value??

Generally I simply create some hash from the password, using something akin to a MD5 or SHA1 hash of the password string. Or in my paranoid case I use the password string, plus all sorts of replicatable combinations of values such as length of password, username, registration date/time etc plus weird other fixed values I find around the place and environment variables etc, then I hash them..

This is just to help prevent any possible dictionary matching of documented common word hashes that can be found on the net due to my mangling of the original word with many other values to create a very abstract piece of art.

I am completely psychotic so don't mind me, when I was 15 I wrote my Perl driven website [still Perl driven member system and file-system based forum] and I had a real mangler function whereby I would extract each character of the password and hash it, then hash the hash with the other characters, plus the hash of them with said fixed values from server/user account details [age, location etc..] ... It was something in the vicinity of a O(6^n+1)th generation hash by the time I had finished where n is the length of the original password..

As I said.. I'm mangled up in my head and I'm extremely passionate about the evolution of security. Thank you GCHQ of England, thank you Williamson, Clifford Cocks, James Ellison and thank you Whitfield Diffie, Merkle and Hellman.. Thank you Ronald Rivest, Adi Shamir and Leonard Adleman.... Thank you Phil Zimmermann..


---oOo--- Allowing users to execute CGI scripts in any directory should only be considered if: ... a.. You have no users, and nobody ever visits your server. ... Extracted Quote: Security Tips - Apache HTTP Server ---oOo--- ------oOo---------------oOo------ Julien Bonastre [The_RadiX] The-Spectrum Network CEO ABN: 64 235 749 494 [EMAIL PROTECTED] ------oOo---------------oOo------ ----- Original Message ----- From: "Bastien Koert" <[EMAIL PROTECTED]>
Sent: Friday, January 06, 2006 12:36 PM
Subject: RE: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption

CC saving is a bad idea on a web facing server...much better to let the user re-input the data each time. If your network allows it, store the data encrypted (using php's mcrypt/decrypt extension) on an separate extremely limited access, non-webfacing (ie internal) db/server that only allows inserts from the webfacing server. Hacking and the liability of being hacked is something to take very seriously. Also look into PCI & regulatory compliance with regard to storing CC data on a server to be aware of any laws that can govern how you do this.

Passwords: again use mcrypt


From: Peter Beckman <[EMAIL PROTECTED]>
To: PHP-DB Mailing List <>
Subject: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way encryption
Date: Thu, 5 Jan 2006 20:27:57 -0500 (EST)

So I'm thinking about how to save credit card numbers in the DB, for
re-charging cards for subscriptions, new orders, etc.

I'm also thinking about how to save passwords in the DB, not plaintext, but
not one-way encrypted either.

Any suggestions?  How would I secure the database?  I'm thinking some
abstract process in code, or something -- security through obscurity.

Peter Beckman Internet Guy [EMAIL PROTECTED]

PHP Database Mailing List (
To unsubscribe, visit:

PHP Database Mailing List (
To unsubscribe, visit:

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to