On Fri, 6 Jan 2006, Julien Bonastre wrote:
Any reason why you need to have reversible encryption on the password
value??
No... I just prefer to assume that if someone gets my DB, they might
try
using user/pass pairs on banking sites, or paypal, or other ways, and
if I
can reversible encrypt the password, I can send them an email with
their
password, rather than changing it to something obscure and force them
to
change it again...
Though at this point, I just decided to md5 the password and call it
good
enough. I'll just force them to change it if need be.
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..
A good idea; are you just careful then that you don't accidentally
update
the data without re-hasing your passwords?
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..
*laugh* Awesome! Maybe a bit overkill for password, but still very
cool.
Unfortunately that leaves things unreversable, and if someone got a
hold
of your data AND your code, they could reverse-engineer... It seems
security is only as good as your weakest link -- obscure code,
private
key, etc...
Well, I still consider it irreversable due to the fact that it is an MD5
hash therefore generating the plainttext from a given ciphertext is
fairly slim unless as I mentioned certain dictionary plainttext words
are kept catalogued somewhere they can match too. But with the sheer
randomness of the plainttext this would never have been hashed before.
So even if someone knows my algorithm and has somehow obtained not only
the end result but also has the plainttext password and all the data I
use intermediate to creating my final hash value AND they can recompute
using all this the same final value.
This still does not help them figure out HOW to reverse just a stored
hash value which they do not know any of the values that were used in
its encryption, ie the password or user details.
Put simply: how do you reverse a hash? Its designed to be a one way
function: I give you:
fc3ff98e8c6a0d3087d515c0473f8677
86fb269d190d2c85f6e0468ceca42a20
First MD5 hash is the plainttext of "hello world!" the second is "Hello
world!"
One character difference, and if you do have an understanding of the
inner workings of the MD5 function you will already know the
implications a checksum works on and thereby it only requires a single
one bit of difference [no pun intended] to create a vastly different
checksum hash..
I am happy to place the security of my users within this field of near
impossibility and believe I have done everything in my power to ensure
even with the most simplest dictionary word password to start with, they
end up with a far more complex end hash therefore avoiding the largest
and by far easiest hash cracking method which is brute force dictionary
matching.
Meh, whats it all at the end of the day anyway..
Good questions about the credit card stuff though. I've encountered
similiar issues but decided to simply delegate paypal.com.au's services
to handling subscriptions, credit card payments etc... Their global,
safe, established and it works.
Its not perfect, but it'll do. For example a big problem is you can't
really have variable monthly payments, say your site provides a service
where you are sort of "billed" every month for what features you've
accessed, premium services you've used, how long you used them for etc,
much like your electricity bill or phone bill, well the only feature
paypal provides is its fixed rate subscription system.
Even with the API you can only really retrieve details and transaction
records, you can really edit the rate behind the scenes. The only method
is rather primitive and involves generating a link or form your user
will be displayed on your site which they follow, linking to a
subscription modification page on paypal with the new required values
all entered in.
Sure thats great but now thats the new rate per month. Not good if its a
very variable or fluctuating sort of service you provide with extras or
whatever..
The advantage? Paypal keeps all payment/accounting details on their
systems so its processed automatically. They can provide all the
necessary CC verification and so forth too and handle transactions via
bank/cheque etc..
Whereas the alternative payment system I am using goes through our bank
where we have a client account in which we use XML over HTTPS to submit
requests etc and basically we handle all the transactions, the bank
system simply does the bank work, verifies CC, does scheduled payments
etc, we get all the responses and then perform whatever actions we want
when we want and how much we want behind the scenes..
Anyway... back to work for me :)
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
