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 http://operation-scifi.com [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..
tata!
---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
julien@xxxxxxxxxxxxxxxx
www.the-spectrum.org ------oOo---------------oOo------
----- Original Message -----
From: "Bastien Koert" <bastien_k@xxxxxxxxxxx>
To: <beckman@xxxxxxxxxxxxx>; <php-db@xxxxxxxxxxxxx>
Sent: Friday, January 06, 2006 12:36 PM
Subject: RE: 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
Bastien
From: Peter Beckman <beckman@xxxxxxxxxxxxx>
To: PHP-DB Mailing List <php-db@xxxxxxxxxxxxx>
Subject: 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.
Beckman
---------------------------------------------------------------------------
Peter Beckman
Internet Guy
beckman@xxxxxxxxxxxxx
http://www.purplecow.com/
---------------------------------------------------------------------------
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
