[10138] in Perl-Users-Digest
Perl-Users Digest, Issue: 3731 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Sep 16 18:07:14 1998
Date: Wed, 16 Sep 98 15:00:20 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 16 Sep 1998 Volume: 8 Number: 3731
Today's topics:
Re: A Better PERL for Mac? <westmj@esvax.dnet.dupont.com>
and? or? (logical operator question) <dejah@DejahsPrivateIce.com>
Re: Gratuitous warning: Deep Recursion (Chris Nandor)
Re: Help with Perl problem (Tad McClellan)
Re: how safe is xor encryption ? beyret@my-dejanews.com
Re: how safe is xor encryption ? (Abigail)
Re: how safe is xor encryption ? beyret@my-dejanews.com
Re: how safe is xor encryption ? <dejah@DejahsPrivateIce.com>
Re: how safe is xor encryption ? (Abigail)
Re: how safe is xor encryption ? beyret@my-dejanews.com
Re: how safe is xor encryption ? <eashton@bbnplanet.com>
Re: how safe is xor encryption ? <eashton@bbnplanet.com>
Re: how safe is xor encryption ? (Abigail)
Re: how safe is xor encryption ? <uri@camel.fastserv.com>
Re: how safe is xor encryption ? <fsg@newsguy.com>
Re: how safe is xor encryption ? beyret@my-dejanews.com
Re: MD5 or SHA as Perl functions? (brian d foy)
Re: MD5 or SHA as Perl functions? <merlyn@stonehenge.com>
newbie DATE question <cg@cgiworx.com>
Re: Perl & Java - differences and uses <dalke@bioreason.com>
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 16 Sep 1998 20:28:59 GMT
From: Mike West <westmj@esvax.dnet.dupont.com>
Subject: Re: A Better PERL for Mac?
Message-Id: <6tp72b$6fd@topgun.es.dupont.com>
In article <35FFD9E5.6F95@DejahsPrivateIce.com>
Mary E Tyler, dejah@DejahsPrivateIce.com writes:
>One that might actually *find* the stray ( or {
I use BBEdit and the "Balance" command (apple B).
A great trick I was taught was to put a } or )
at the very end, then balance that block, and it
highlights up to the previously unbalanced
{ or (.
Yet, I wonder if I would get a benefit from using
Perl under MPW? Are there advantages?
------------------------------
Date: Wed, 16 Sep 1998 15:01:56 -0500
From: Mary E Tyler <dejah@DejahsPrivateIce.com>
Subject: and? or? (logical operator question)
Message-Id: <36001932.1329@DejahsPrivateIce.com>
Here's a question about how the logical operators work and if a specific
piece of code will do what i expect it to in perl... pardon me for
digressing a moment.
in c the expression a&&b is true if an only if both a and b are both
true, otherwise it is false... a||b is true as long as a and b are not
both false.
here's what i want to do:
open (SLOG, ">>$MyLog") and open (CLOG, ">>$MyComments") or die"etc";
will this do what i think it will do... it will try to open the two
files and if either one fails, it will die? or will it evaluate the
first open and then say "i'm successful" and not evaluate the second
open?
i guess what i mean is does the "and" in perl work like the && in C
where if the first operand is true then the second is evaluated, if it
is false then the whole thing is false and it doesn't bother. at least,
that is what i think i am asking.
maybe what i really want to know is: will this work?
ak.
dejah, hey Matthew, I'm trying for the max number of non-dumb questions
i can get in a day.
--
i trust i make myself obscure, i have need of obscurity now- robert bolt
a heated exchange of unread mail would be welcomed by all- christensen
Skating Fiction. Featuring the highly acclaimed serial On The Edge!
http://www.DejahsPrivateIce.com
------------------------------
Date: Wed, 16 Sep 1998 15:54:13 -0400
From: pudge@pobox.com (Chris Nandor)
Subject: Re: Gratuitous warning: Deep Recursion
Message-Id: <pudge-1609981554130001@192.168.0.77>
In article <6tk75m$fa1@news.euro.net>, hansmu@xs4all.nl wrote:
# It would be nice if perl provided a mechnism for selectively
# turning off errors. In fact, such a mechanism is being
# considered for inclusion in perl 5.006 (whenever that may be).
You may even be able to find a patch to add lexical warnings to whatever
perl you are running:
http://www.cpan.org/authors/id/PMQS/
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: Wed, 16 Sep 1998 14:46:32 -0500
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: Help with Perl problem
Message-Id: <oi4pt6.na3.ln@metronet.com>
mike@debtware.co.uk wrote:
: Can anyone kelp me please.
I otter be able to help.
: I am trying to write a perl program where I
: pass two arguments on then command line. The first is the input file
: the second is the output file.
: The command line reads:
: perl myprog.pl filename1 filename2
: In the code I have:
: $file1 = @ARGV[0]
: $file2 = @ARGV[1]
^^^^^^^^
Those are array slices (one element long).
You probably want to be accessing a single scalar instead.
Semicolons are used to terminate statements in Perl.
$file1 = $ARGV[0];
$file2 = $ARGV[1];
or
$file1 = shift;
$file2 = shift;
: open (InFile, $file1);
You should always, yes *always*, check the return value from
open() calls.
: open (OutFile, $file2);
You should always, yes *always*, check the return value from
open() calls.
: When I run it OutFile will not open.
It might actually be opening. Can't tell because you didn't
check the return value...
If it did open, however, it would be for reading, since that
is what you asked for.
If you want it opened for writing, then you should ask for
it to be opened for writing.
:I am running perl 5 under dos.
Sorry to hear that. ;-)
: Any suggestions please.
I would suggest that if you want to open a file for writing,
you do it similar to the way described for the open() function
in the docs that come with the perl distribution (perlfunc).
--
Tad McClellan SGML Consulting
tadmc@metronet.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 16 Sep 1998 19:51:37 GMT
From: beyret@my-dejanews.com
Subject: Re: how safe is xor encryption ?
Message-Id: <6tp4s8$orf$1@nnrp1.dejanews.com>
> Your assumptions are dangerously ignorant. I am offended by anyone who
> puts CC data onine without SSL or better and thinks that it is
> sufficient. As someone who has been in some distress over the failing of
> system security, I would suggest having a much closer look at what is
> the weakness in your proposition. I think it should be obvious. Personal
> CC data is not to be taken lightly. Would you give your CC number
> on-line given your script? I think not.
>
> e.
oops. something i did not write explicitly maybe. That scenario will already
take place in a SSL secured environment with secure servers and so on. The
machine is a linux redhat 5.1, with redhat secure webserver installed
(apache-ssl based). so transactions will already happen in SSL environment.
The point of my mail was related to "storage of CC numbers safely" not
transaction, since we already assume the SSL transaction as a secure
environment.
Many merchants store CC#'s in bare format. Since i do not take CC data
lightly, in your words, i care to search for an encyrption/decryption scheme
to protect the right of property of the CC owner. The merchant will not even
now the credit card numbers. only programs will know how to decrypt it and
only when the user wants and supplies the necessary secret key. and secret
key will not be stored anywhere.
in any case, i do not want to store bare CC numbers nor i want to store
encrypted numbers and keys. both are equally stressfull for a system admin.
ersin beyret
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: 16 Sep 1998 20:01:00 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: how safe is xor encryption ?
Message-Id: <6tp5ds$jap$1@client3.news.psi.net>
Mark-Jason Dominus (mjd@op.net) wrote on MDCCCXLII September MCMXCIII in
<URL: news:6touoo$5j0$1@monet.op.net>:
++
++ I still think `xor' is probably a poor choice.
"The next step up in complexity for the cryptographer is to use a key
longer than the plaintext, making the above attack useless. In fact,
constructing an unbreakable cipher is easy. First choose a random bit
string as the key. Then convert the plaintext into a bit string, for
example by using its ASCII representation. Finally, compute the
EXCLUSE OR of these strings, bit by bit. The resulting ciphertext
cannot be broken, because every possible plaintext is an equally
probable candidate. The ciphertext gives the cryptoanalyst no infor-
mation at all. In a sufficiently large sample of ciphertext, each
letter will occur equally often, as will every digram and every trigram."
Andrew S. Tanenbaum: "Computer Networks". Prentice/Hall. 1981.
ISBN 0-13-164699-0. pp 392-393.
Abigail
--
perl -e '$a = q 94a75737420616e6f74686572205065726c204861636b65720a9 and
${qq$\x5F$} = q 97265646f9 and s g..g;
qq e\x63\x68\x72\x20\x30\x78$&eggee;
{eval if $a =~ s e..eqq qprint chr 0x$& and \x71\x20\x71\x71qeexcess}'
------------------------------
Date: Wed, 16 Sep 1998 19:59:22 GMT
From: beyret@my-dejanews.com
Subject: Re: how safe is xor encryption ?
Message-Id: <6tp5aq$p7p$1@nnrp1.dejanews.com>
In article <1dffalg.xn7an31ktucowN@bay1-474.quincy.ziplink.net>,
rjk@coos.dartmouth.edu (Ronald J Kimball) wrote:
> <beyret@my-dejanews.com> wrote:
>
> > I am about to write a simple script to encrypt/decrypt credit card numbers
> > using xor and a key supplied by credit card owner. I wanted to learn your
> > thoughts about it:
>
> What exactly is your Perl question?
> If I'm not mistaken, xor encryption could be implemented in any
> programming language. Thus, this is not a Perl issue at all. Try a
> security or encryption newsgroup.
well, yes I guess so. But I will implement this in some perl scripts so I
thougt that was the right place to mail to get some initial advices not to
fall into some perl specific pitfalls.
ersin
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: Wed, 16 Sep 1998 14:11:48 -0500
From: Mary E Tyler <dejah@DejahsPrivateIce.com>
Subject: Re: how safe is xor encryption ?
Message-Id: <36000D6B.6B4F@DejahsPrivateIce.com>
Mark-Jason Dominus wrote:
>
> In article <35FFB32E.6F33@gecm.com>, Jim Michael <jim.michael@gecm.com> wrote:
snip
> >However, CC#s have a common beginning number sequence which
> >identifies the CC type (MC, Visa, etc.), do they not?
>
> Yes, but I think it's only one digit long. Perhaps someone can confirm?
>
the first 4 refer to the clearing house(for lack of a better term). the
second four refer to your bank. the third four are a reference internal
to your bank. the fourth are your account number. or so i have been
told.
it's really the last 8 that are important and the last 4 that are
crucial.
think what i might do is take the password they provide and use it as a
seed to your random number generator and encrypt with the number
produced... then you can easily reproduce the decryption key (unless i
misunderstand how RNGs work). if the password is submitted securely and
stored securely (remember the easiest way to make something safe on the
internet is to unplug the network connection... LOL)
am watching this closely, being at a point in a project where i need
some moderate protection on passwords and files, but nothing
incredible...
dejah
ps- would someone be so kind as to remind me via email what the heck xor
does and how you encrypt/decrypt with it. we just moved and my
programming books are locked away. i used it once a few years ago and
haven't needed it since... forgot how the hell it works.
--
i trust i make myself obscure, i have need of obscurity now- robert bolt
a heated exchange of unread mail would be welcomed by all- christensen
Skating Fiction. Featuring the highly acclaimed serial On The Edge!
http://www.DejahsPrivateIce.com
------------------------------
Date: 16 Sep 1998 20:19:40 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: how safe is xor encryption ?
Message-Id: <6tp6gs$k0k$1@client3.news.psi.net>
Elaine -HappyFunBall- Ashton (eashton@bbnplanet.com) wrote on MDCCCXLII
September MCMXCIII in <URL: news:360000B8.259600FD@bbnplanet.com>:
++ Mark-Jason Dominus wrote:
++
++ > If the key is intercepted, it is not very useful to the snooper. They
++ > can use it to authorize purchases from you, but not from anyone else.
++
++ How so? If I can get the key, I can get the CC# and then I can make
++ purchases anywhere I want.
No. You need the key *and* the encrypted number.
++ > If the entire database is stolen, it is not useful to the thief
++ > without a database of decryption keys, and no such database exists.
++
++ You presume that the key length is sufficient to render the decryption
++ impractical or impossible. Also, too, that the customer has chosen a
++ totally random key which, in my experience at least, is all too rare an
++ occurance.
Impossible is the right answer. The beauty of XOR encryption is that even
if you brute force try all keys, and you hit the right one, you have
absolutely no idea it is the right key.
For instance, I might give you the encrypted text "t^R][S". You might
try keys, and find out that XORring with "123456" gives "Elaine". However,
XORring with "5-:)4=" will give you "Ashton". And a key of "<?16>!" will
give you "Hacker". For any 6 character string, there will be a unique,
6 character key that, when applied to the encrypted text, gives you the
target text.
Abigail
--
perl -wle 'print "Prime" if (1 x shift) !~ /^1?$|^(11+?)\1+$/'
------------------------------
Date: Wed, 16 Sep 1998 20:14:57 GMT
From: beyret@my-dejanews.com
Subject: Re: how safe is xor encryption ?
Message-Id: <6tp680$qa9$1@nnrp1.dejanews.com>
In article <35ff839e.21743886@news.interport.net>,
allan@interport.net (Allan Peda) wrote:
> As a first guess... look into calling crypt() on a key generated by a
> call to rand(). Save the encrypted key in another database, perhaps
> on another machine? There is also a module called Crypt.
>
> In any event it's a heck of a lot better than XOR
yes but i also want to decrypt it. crypt puts it into a not-easily-decryptible
form, am i wrong?
ersin
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: Wed, 16 Sep 1998 20:20:01 GMT
From: Elaine -HappyFunBall- Ashton <eashton@bbnplanet.com>
Subject: Re: how safe is xor encryption ?
Message-Id: <36001B0D.706BB38D@bbnplanet.com>
beyret@my-dejanews.com wrote:
> oops. something i did not write explicitly maybe. That scenario will already
> take place in a SSL secured environment with secure servers and so on. The
> machine is a linux redhat 5.1, with redhat secure webserver installed
> (apache-ssl based). so transactions will already happen in SSL environment.
> The point of my mail was related to "storage of CC numbers safely" not
> transaction, since we already assume the SSL transaction as a secure
> environment.
I'm not sure that RedHat would be my first choice for a host storing
sensitive data, encrypted or not due to the number of exploits that
currently exist for it and are proliferating everyday. Perhaps I have
been a bit obtuse as well. My point in all of this is that one must
consider all of the options if one truly wants to make a secure
e-commerce solution.
> Many merchants store CC#'s in bare format. Since i do not take CC data
> lightly, in your words, i care to search for an encyrption/decryption scheme
> to protect the right of property of the CC owner. The merchant will not even
> now the credit card numbers. only programs will know how to decrypt it and
> only when the user wants and supplies the necessary secret key. and secret
> key will not be stored anywhere.
I wasn't criticising the encryption idea, but the confidence it seems to
evoke. What if someone added a few lines of code to your script and
mailed all of the customers info at the time of sign-up to an email
address? You cannot always prevent things such as this, but dreaming up
ways to compromise your site and considering them in the solution is
important.
> in any case, i do not want to store bare CC numbers nor i want to store
> encrypted numbers and keys. both are equally stressfull for a system admin.
I'll second that :)
e.
"All of us, all of us, all of us trying to save our immortal souls, some
ways seemingly more round-about and mysterious than others. We're having
a good time here. But hope all will be revealed soon." R. Carver
------------------------------
Date: Wed, 16 Sep 1998 20:30:49 GMT
From: Elaine -HappyFunBall- Ashton <eashton@bbnplanet.com>
Subject: Re: how safe is xor encryption ?
Message-Id: <36001D95.FC206F90@bbnplanet.com>
Abigail wrote:
> No. You need the key *and* the encrypted number.
Correct. But, if I can get the key, I can probably get on the machine
and find the database. Unless, of course, I missed something.
> Impossible is the right answer. The beauty of XOR encryption is that even
> if you brute force try all keys, and you hit the right one, you have
> absolutely no idea it is the right key.
Well, brute force is an ugly way to go about spending a Sunday
afternoon, but I don't know that impossible is the correct term.
> For instance, I might give you the encrypted text "t^R][S". You might
> try keys, and find out that XORring with "123456" gives "Elaine". However,
> XORring with "5-:)4=" will give you "Ashton". And a key of "<?16>!" will
> give you "Hacker". For any 6 character string, there will be a unique,
> 6 character key that, when applied to the encrypted text, gives you the
> target text.
This is true and I may be dead before I could break it, but then again,
I could get lucky. Modern cryptanalysis is making great strides and with
more computing power than ever before. I never like to say that anything
is impossible, just improbable...for now. They broke purple without a
cray didn't they?
e.
"All of us, all of us, all of us trying to save our immortal souls, some
ways seemingly more round-about and mysterious than others. We're having
a good time here. But hope all will be revealed soon." R. Carver
------------------------------
Date: 16 Sep 1998 20:31:06 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: how safe is xor encryption ?
Message-Id: <6tp76a$k0k$2@client3.news.psi.net>
Mark-Jason Dominus (mjd@op.net) wrote on MDCCCXLII September MCMXCIII in
<URL: news:6tp0qo$61r$1@monet.op.net>:
++ In article <6totbc$fb7$1@client3.news.psi.net>,
++ Abigail <abigail@fnx.com> wrote:
++ >Xorring with a key as long as the message is the strongest encryption
++ >possible.
++
++ Yes, but it's not clear that you can trust the user to select a 53-bit key.
But what keeps you from selecting one for them? At one point in time,
you need a secure transaction line - at the time they send their
encrypted numbers. (You cannot send both the encrypted number and the
key over a potential insecure line, as that would give a snooper the
credit card number). Once you have the secure line, send them the key
(which of course, you will not store), they send the encrypted number,
and keep the key. Next time, when they use the potential insecure line,
they send the key.
++ In the absence of such a guarantee, there might be attacks other than
++ simple brute force that would be moer successful against xor than
++ against some other method.
++
++ >++ Encrypting the numbers in the database, and transmitting only the
++ >++ decryption key, rather than the actual number, seems prudent to me.
++ >++ Is there some problem I'm overlooking?
++ >
++ >
++ >If your database is potentially insecure, how secure are your transmission
++ >lines?
++
++ Comparing the relative security of two unrelated entities is silly.
++ The database might be compromised. The transmission lines might be
++ compromised. Just because one is compromised does not mean you have
++ to give up on the other one. It would be like saying `If your front
++ door lock is insecure, how secure is your burglar alarm?'
Well, there is a problem. The database is safe, but the transmission
line isn't. You call the company, introduce yourself as Mark-Jason and
send your key. If I can snoop that transmission, what's keeping me from
calling the company, introducing myself as Mark-Jason, and order some nice
toys using your credit card number, that I unlock by sending your key?
It's true that I won't be able to snatch your CC# number that way, but
I can still use your number.
Abigail
--
perl -wle 'print "Prime" if (1 x shift) !~ /^1?$|^(11+?)\1+$/'
------------------------------
Date: 16 Sep 1998 16:51:53 -0400
From: Uri Guttman <uri@camel.fastserv.com>
Subject: Re: how safe is xor encryption ?
Message-Id: <saraf3z93x2.fsf@camel.fastserv.com>
>>>>> "A" == Abigail <abigail@fnx.com> writes:
A> Mark-Jason Dominus (mjd@op.net) wrote on MDCCCXLII September
A> MCMXCIII in <URL: news:6touoo$5j0$1@monet.op.net>: ++ ++ I still
A> think `xor' is probably a poor choice.
A> "The next step up in complexity for the cryptographer is to use a
A> key longer than the plaintext, making the above attack useless. In
A> fact, constructing an unbreakable cipher is easy. First choose a
A> random bit string as the key. Then convert the plaintext into a bit
A> string, for example by using its ASCII representation. Finally,
A> compute the EXCLUSE OR of these strings, bit by bit. The resulting
A> ciphertext cannot be broken, because every possible plaintext is an
A> equally probable candidate. The ciphertext gives the cryptoanalyst
A> no infor- mation at all. In a sufficiently large sample of
A> ciphertext, each letter will occur equally often, as will every
A> digram and every trigram."
A> Andrew S. Tanenbaum: "Computer Networks". Prentice/Hall. 1981.
A> ISBN 0-13-164699-0. pp 392-393.
this is the well known one time pad technique and it is considered
unbreakable. you distribute a pair of pads which have the same sequence
of random numbers, one pad at home and one pad to the remote
spy. messages are encrypted using xor or something similar (a plain
letter substitution will work with random integers) with the next pad
sheet for each message (or part). only if you know the random sequence
can you break it. the problem is the secure distribution of the two
copies of the pad.
the resulting ciphertext has same the entropy of the random sequence and you
can't deduce when you have decoded it.
i hate to admit it, but dear abby is right here. xor is all you need
provided you have a random key and it is secure at both ends.
uri
--
Uri Guttman Speed up your web server with Fast CGI!
uri@fastengines.com http://www.fastengines.com
------------------------------
Date: Wed, 16 Sep 1998 13:12:13 -0700
From: "Felix S. Gallo" <fsg@newsguy.com>
Subject: Re: how safe is xor encryption ?
Message-Id: <6tp5s3$127@enews2.newsguy.com>
Mark-Jason writes:
>[...]
>If the customer-selected key phrases have at least 53 bits of entropy,
>then a brute force search will fail utterly. A CC# is about 53 bits
>long, so with a 53-bit key phrase you are doing one-time pad, and the
>result of your brute-force search is nothing more than a list of every
>possible credit card number.
What M-J said is basically correct. But as a novitiate crank pedant,
I earn valuable Usenet points towards my next advancement by
pointing out that some of his language here tends towards the
careless: there's a difference between a '53-bit key phrase' and
a key phrase with 53 bits of entropy, normally, especially if the
phrase is 'customer-selected' -- and with a 53-bits-of-entropy key
phrase you are not doing 'one-time pad', but rather you are
ensuring that every bit in the plaintext is subject to possible entropic
change. Since the customer may reuse the key phrase, there are
dangers that don't exist with real one-time pads. But as far as
most of the readers of this post will ever need to know, Mark-Jason
is spot on.
Now that I have discharged my pedantic duties, I now go for the
bonus round by adding to the conversation.
Anyone keeping a database of credit card numbers on a
computer accessible to the Internet is asking for trouble,
no matter what their security implementation is. If a hacker
can get on that computer, then she can download the
decryption algorithm code or install a debugger.
One way to start being secure is to remove all network
interfaces from your credit card database box and
install a serial cable. Write some special software
for the box which answers queries only, and does not
permit download of the whole database. Insert trap
credit card numbers. Make sure the query box is
extremely secure, including tripwire, firewalling,
signalling, and of course more hacker traps.
The inconvenience to you is zero compared to
what you'd go through if the database were stolen.
The customer might not be extremely put out --
after all, the credit card company makes certain
anti-theft-loss guarantees -- but the buck has to
stop somewhere, and you're the obvious target.
Felix
------------------------------
Date: Wed, 16 Sep 1998 20:52:49 GMT
From: beyret@my-dejanews.com
Subject: Re: how safe is xor encryption ?
Message-Id: <6tp8f0$ssp$1@nnrp1.dejanews.com>
> - - The programmer is terribly naive about users if he thinks
> that asking them for a string the length of their CC # + expiration
> data is a workable solution. How are they going to remember it?
> If he stores the key on the machine the encryption is useless.
yes, i do not, and will not store keys in anywhere.
the key I was planning to ask from credit card owner does not have to be at
the same length of their CC #+expiration data. then all the scheme would be
useless. the main point of storing CC# into database is not to make user be
have to enter again and again their CC# at every shopping but just enter the
secret key, which is easy to remember. if s/he forgets the secret key, there
is no way to find it, since it is not stored anywhere. but that is not a
problem, s/he just need to register again.
if the secret key is not an easy to remember key, than all these are useless.
that's why i did not want its length to be restricted with CC#+expiration. if
a shorter secret key is supplied, then the script will generate the other
parts from the supplied one.
CC#: 123412341234 1234
key: merhaba
the perl script must be able to generate the remaining part of the key from
the supplied one :"merhaba".
actually, this would me more secure than having 16 digits of long phrase.
because, users will give meaningfull phrases to make it easy to remmember.
but that increases the vulnerability to a dictionary attack. but instead of
16 characters, if user enters (or restricted to enter) say 10 characters and
remainig part is generated by an algorithm which will make dictionary
attackers job difficult by generating meaningless combination of characters,
i think that would make it safer.
the algorithm however, should generate the same combination everytime the same
phrase entered.
than that final string will be xored with CC# and stored.
you may say that since cracker has the source code s/he can also generate
this combination but s/he does not now how long the real phrase is. again,
only CC# owner knows about it. well maybe i am wrong. s/he can just run
her/his all words + generated combination for each of them and try. the
dictionary must be a real good one though.
in any case, if you were a cracker, would you attack to a system if you knew
that even if you could reach to the database, you still have to deal with
each CC# uniquely. or would you go for other system where credit cards are
available in chunks, either because they are stored as clear text or keys are
also stored in system or there is one key for all.
btw, i am not a professional programmer, thus my approach to the issue is as
good as my logic allows.
thanks
ersin beyret
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: Wed, 16 Sep 1998 16:26:33 -0400
From: comdog@computerdog.com (brian d foy)
Subject: Re: MD5 or SHA as Perl functions?
Message-Id: <comdog-ya02408000R1609981626330001@news.panix.com>
Keywords: from just another new york perl hacker
In article <mike.elness-1609981040450001@stealthmac.lmms.lmco.com>, mike.elness@lmco.com (Mike Elness) posted:
>In article <comdog-ya02408000R1609981239400001@news.panix.com>,
>comdog@computerdog.com (brian d foy) wrote:
>>
>> what's wrong with just using the modules? if you don't like the
>> interface provided by the module, write a subroutine to act as
>> a wrapper.
>The reason I can't use the modules is that I can't build them. I want to
>use a message digest function to protect cookies from end-user alteration
>in a web-based application. The web-based app is comprised of Perl CGI
>scripts, but it is deployed on the web server of an ISP who does not even
>allow a shell login, much less access to developer tools for building
>stuff.
simple solution - change ISPs. the market is too competitive to not
get what you want.
have you asked the admins to install it for you? becoming friendly
with these people often makes life easier :)
--
brian d foy <comdog@computerdog.com>
CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
Perl Mongers needs volunteers! <URL:http://www.pm.org/to-do.html>
------------------------------
Date: Wed, 16 Sep 1998 20:40:37 GMT
From: Randal Schwartz <merlyn@stonehenge.com>
Subject: Re: MD5 or SHA as Perl functions?
Message-Id: <8c1zpbkczz.fsf@gadget.cscaper.com>
>>>>> "Mike" == Mike Elness <mike.elness@lmco.com> writes:
Mike> The reason I can't use the modules is that I can't build them. I want to
Mike> use a message digest function to protect cookies from end-user alteration
Mike> in a web-based application. The web-based app is comprised of Perl CGI
Mike> scripts, but it is deployed on the web server of an ISP who does not even
Mike> allow a shell login, much less access to developer tools for building
Mike> stuff.
So, just submit a CGI script that does this:
use CPAN;
install "SHA";
:-)
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
------------------------------
Date: Wed, 16 Sep 1998 20:57:53 GMT
From: Bryan Ingram <cg@cgiworx.com>
Subject: newbie DATE question
Message-Id: <360027B0.F2FE342F@cgiworx.com>
Hi ..
I'm a C programmer, just getting around to learning Perl ..and I love
it! ;)
I'm working on an a program where I need to take the current date and
increment it by 1 day. Is there a nifty routine to do this in Perl, or
must I do all the checking myself? e,g ..must I manually code the logic
to determine if the day has exceeded the max for the current month, etc?
Thanks,
Bryan Ingram
------------------------------
Date: Wed, 16 Sep 1998 15:40:40 -0700
From: Andrew Dalke <dalke@bioreason.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <36003E68.B2A63F34@bioreason.com>
Not sure why I'm getting involved in a language war, but ...
Zenin <zenin@bawdycaste.org> asked:
> Please show *any* Python or Java code that when translated to Perl
> would be done uncleanly by default. *Any* code.
As I recall, regular expressions in Perl are not first class
elements. For example, you cannot make a list of regular
expressions.
I have an interactive system for doing re searches against
a string (actually, Prosite pattern searches against protein
sequences). I want to register a set of patterns, read a
string, and search it.
Eg (written on the fly so there are probably errors):
import re
patterns = []
def add_pattern(pat, name):
patterns.append( (re.compile(pat), name) )
# returns number of matches found
def search(str):
count = 0
for pat in patterns:
m = pat[0].search(str)
if m:
# could put more info here, like start&end pos, match text
print "Found", pat[1]
count = count + 1
return count
The closest I can think of in Perl is to construct some perl
code and eval it dynamically, like:
$patterns = '';
sub add_pattern {
my($pat, $name) = @_;
$patterns .= "if (\$str =~ /$pat/) { \$count++;
print 'Found $name\n'; }\n";
}
sub search {
my($str) = $_[0];
my($count) = 0;
eval $patterns;
return $count;
}
They are about the same size, but (IMHO, YMMV) the Perl code
looks "unclean" becuase of the dynamic code construction, the
"$" escapes, and the requirement that "add_pattern" know the
local variable names used in "search".
As long as I'm here, there's what I consider to be the number one
bug in Perl code that deals with files -- how do you read from the
file " spaces " (with the leading and trailing space characters).
According to the perl manual, you should do:
$file =~ s#^\s#./$&#;
open(FO, "< $file\0");
which means some of the standard Perl libraries have bugs in
them, like File/Compare.pm's "compare".
sub compare {
croak("Usage: compare( file1, file2 [, buffersize]) ")
...
} else {
open(FROM,"<$from") or goto fail_open1;
binmode FROM;
$closefrom = 1;
$fromsize = -s FROM;
}
Here's an example (with perl5.004_04, but I just downloaded the
5.005_2 and checked its libraries).
bioreason8> cat > " space1 "
This is a test
bioreason8> cat > " space2 "
This is a test
bioreason8> perl -e 'use File::Compare; if (compare(" space1 ",\
" space2 ") == 0) { print "Equal\n";}'
bioreason8> rm " space1 " " space2 "
bioreason8> cat > space1
This is a test
bioreason8> cat > space2
This is a test
bioreason8> perl -e 'use File::Compare; if (compare("space1",\
"space2") == 0) { print "Equal\n";}'
Equal
(My cursory search also found bugs in:
ExtUtils/Command.pm "eqtime"
ExtUtils/Command.pm "touch"
ExtUtils/MM_Unix.pm "fixin"
and I just sent all this to perlbug.)
It's a minor nit, but it means perl code you write that can take
any filename as input must escape spaces as shown above, which to
me is, if not unclean, then ungainly.
But remember, I'm not trying to say perl is bad or that you shouldn't
use it. I'm only showing that there are at least two cases where
an implementation in perl is not as "clean" (in my definition of
clean) as the equivalent Python code.
(*Sigh*, why do I feel like I'll be flamed regardless of this
comment?)
Andrew Dalke
dalke@bioreason.com
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 3731
**************************************
