[nycphp-talk] Encrypt/Decrypt without MCrypt
jon baer
jonbaer at jonbaer.net
Mon Dec 1 11:33:38 EST 2003
while you probably already found a solution for this, the most secure method
will no doubt be using an offline private key for decryption (or hidden
file) ...
there is *suppose* to be a GnuPG extenion library designed to make this
easier: http://www.gnupg.org/related_software/gpgme/
which would allow for embedding PKI into PHP much easier but I have not seen
or heard any updates to whether this library will be out with PHP 5 (or
compiled for PHP < 5) ... does anyone know?
- jon
----- Original Message -----
From: "Jeff Siegel" <jsiegel1 at optonline.net>
To: "NYPHP Talk" <talk at lists.nyphp.org>
Sent: Monday, December 01, 2003 10:46 AM
Subject: Re: [nycphp-talk] Encrypt/Decrypt without MCrypt
> Let me explain the situation in a bit more detail...this may help to
> clarify what I'm trying to accomplish.
>
> I'll be storing 50,000 PIN numbers for phone cards. People will receive
> a card that has an alphanumeric code. They'll enter the code number into
> a form and receive an email that has a special URL attached. They'll
> click on the URL and then the associated PIN number will be displayed on
> the screen. My intention is to do all of this via SSL.
>
> My concern is the encrypting/decrypting of the PIN numbers. I can't use
> one-way encryption since I need to decrypt the data. The alphanumeric
> codes will also be stored in an encrypted form.
>
> Jeff
>
> Christopher R. Merlo wrote:
>
> > On 2003-12-01 09:40 -0500, Brian Pang <bpang at bpang.com> wrote:
> >
> >
> >>Finally, write the code for this particular piece in the most cryptic
> >>manner that you can and don't comment the code. Don't use easy to follow
> >>var names like "sEncoded" Use single letters or other nonsense or
> >>random strings for var names, and put in lots of other useless code just
> >>to make it hard to interpret should anyone get a hold of it.
> >
> >
> > This sounds like a recipe for disaster. If anyone *does* break in to
> > your server, you'd get toasted this way.
> >
> > Also, remember: if it's hard for the attacker to interpret, it will be
> > hard for you to interpret next month.
> >
> > Now I don't know if this helps, but on my site, users type in their
> > password, and I compare it with an MD5 sum already in my DB. If the
> > sums match, that means that the user typed in the correct password,
> > and they're authenticated. This way, no cleartext password gets
> > stored anywhere.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > talk mailing list
> > talk at lists.nyphp.org
> > http://lists.nyphp.org/mailman/listinfo/talk
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>
More information about the talk
mailing list