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:

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 :)

Peter Beckman Internet Guy [EMAIL PROTECTED] http://www.purplecow.com/

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to