Perl Script
dakin999
like
following. Any code help will be really helpful.
1. Reads from a database(oracle) following columns:
Customer_No, Fname, Lname, Password.
2. Encrypts the password in SHA1_Base64 format.
3. Use the perl-ldap add object to create a ldif record with the same
columns (as in step 1, but password in the SHA1_Base64 encrypted
string).
4. Create a CSV file with same columns as in step 1, exculding the
password.
5. Add the ldif data into SUN LDAP directory.
Thanks in advance.
A. Sinan Unur
cd6821...@l28g2000prd.googlegroups.com:
> I am looking for any generic perl script that is doing some thing
> like following.
Sinan
--
A. Sinan Unur <1u...@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
Ron Bergin
Dr.Ruud
> 1. Reads from a database(oracle) following columns:
> Customer_No, Fname, Lname, Password.
>
> 2. Encrypts the password in SHA1_Base64 format.
You have plain passwords in the database?
--
Affijn, Ruud
"Gewoon is een tijger."
dakin999
cartercc
> You have plain passwords in the database?
I do as well for a couple of apps. The reason: a management decision
that when the user forgets his or her password, an event that occurs
often, we are to give the user his old password instead of forcing him
to generate a new password. If we encrypted the passwords in the
database, we couldn't do this.
CC
Andrew DeFaria
cartercc
> That depends on what kind of encryption you use...
This particular database is Postgres. It uses a one way hash. We also
receive social security numbers, which we are required to read into
the database but not required to read out, so we hash these.
Key management is one headache that I don't have. ;-)
CC
szr
It is still infinitely more secure to store passwords in an encrypted
form and reset lost passwords.
--
szr
Andrew DeFaria
On Jun 18, 10:47 am, Andrew DeFaria <And...@DeFaria.com> wrote:
That depends on what kind of encryption you use...This particular database is Postgres. It uses a one way hash.
We also receive social security numbers, which we are required to read into the database but not required to read out, so we hash these.
Key management is one headache that I don't have. ;-)
Andrew DeFaria
Why do banks charge you a non-sufficient funds fee on money they already know you don't have?
Ted Zlatanov
AD> cartercc wrote:
>> On Jun 18, 10:47 am, Andrew DeFaria <And...@DeFaria.com> wrote:
>>> That depends on what kind of encryption you use...
>> This particular database is Postgres. It uses a one way hash.
AD> No, you don't understand. You could encrypt things yourself then
AD> just store the encrypted result in the database. Then, later on,
AD> extract it and reverse the encryption. IOW you're not limited to
AD> just what Postgres (or any other database for that matter) has to
AD> offer.
Usually this is a bad idea, because whoever has the key can also decrypt
all the passwords. It's mildly less dangerous with asymmetric
encryption, but still not a good idea and more complicated.
Hashing passwords is much safer than reversible encryption (regardless
whether it's symmetric or asymmetric). MD5 hashing is popular because
it's fast, but there have been exploits against it so one of the newer
hashing algorithms may be better. Hashing is not reversible so you
can't get the original passwords from the database. You can only check
that the given password hashes to the same value as the one in the
database Thus, "one-way hash".
Usually it's implemented with extra salt, so you hash
"secrettextPASSWORD" instead of just "PASSWORD" as extra protection
against brute-force attacks. It won't help if the attacker has access
to the code and can see what "secrettext" is, but if the attacker can
only see the passwords table it's a decent defense. It makes the
password harder to guess, especially with a longer secret text.
Ted
Andrew DeFaria
AD> No, you don't understand. You could encrypt things yourself then
AD> just store the encrypted result in the database. Then, later on,
AD> extract it and reverse the encryption. IOW you're not limited to
AD> just what Postgres (or any other database for that matter) has to
AD> offer.
Usually this is a bad idea, because whoever has the key can also decrypt all the passwords.
--
Andrew DeFaria
The name is Baud......, James Baud.
cartercc
> > Key management is one headache that I don't have. ;-)
>
> I'd really like to know who you work for - so I can avoid them!
I work for a large public university. 'Management' is mostly academic,
not business. I'd like to avoid them as well, but hey, working
conditions are great and I get a lot of time off, even though the pay
sucks.
As to this entire issue, I don't WANT to be able to decrypt SSNs. I
crypt() them into the database and then delete the input file, and I'm
happy. If I have to match SSNs (which happens on rare occasions) I
just have to match the hash. One of the things on my not-to-do list is
maintain keys. Maintaining passwords in the clear is bad enough, but
I've CYAed myself in that regard.
CC
Martijn Lievaart
> Usually it's implemented with extra salt, so you hash
> "secrettextPASSWORD" instead of just "PASSWORD" as extra protection
> against brute-force attacks. It won't help if the attacker has access
> to the code and can see what "secrettext" is, but if the attacker can
> only see the passwords table it's a decent defense. It makes the
> password harder to guess, especially with a longer secret text.
Actually, IIRC, you just need a different salt for different users. It
doesn't matter to much if the salt is known for a particular user. In
fact, if you know the MD5 hash, you know the salt, as these are stored
together.
What a salt protects against is someone pre-computing the md5 (or
whatever) hash for a dictionary and comparing this pre-computed result
against a password file. Just having a salt, a different one for each
password, known or not, protects against this attack.
One may implement this as a secret salt, the same for all users, as Ted
seems to imply. This is a bad idea, for the reasons he noted. However,
this is not what a salt is about normally.
M4
Martijn Lievaart
But key collisions may be.
I agree with your reasoning, except it may introduce another risk. If the
SSN is just used for an check, so you check it against a known record,
OK, no problem. But if you use it as a search key, there may be a hash
collision.
Probably you mean the former, in which case I didn't say anything.
Cheers,
M4
Andrew DeFaria
On Jun 19, 1:23 am, Andrew DeFaria <And...@DeFaria.com>
I work for a large public university.Key management is one headache that I don't have. ;-)I'd really like to know who you work for - so I can avoid them!
'Management' is mostly academic, not business.
I'd like to avoid them as well, but hey, working conditions are great and I get a lot of time off, even though the pay sucks.
As to this entire issue, I don't WANT to be able to decrypt SSNs. I crypt() them into the database and then delete the input file, and I'm happy. If I have to match SSNs (which happens on rare occasions) I just have to match the hash. One of the things on my not-to-do list is maintain keys. Maintaining passwords in the clear is bad enough, but I've CYAed myself in that regard.
In any event my point still stands - there are ways to use reversible encryption to at least up the level of security a bit.
Andrew DeFaria
Since light travels faster than sound, isn't that why some people appear bright until you hear them speak?
Ted Zlatanov
ML> On Wed, 18 Jun 2008 08:28:49 -0700, cartercc wrote:
>> On Jun 18, 10:47 am, Andrew DeFaria <And...@DeFaria.com> wrote:
>>> That depends on what kind of encryption you use...
>>
>> This particular database is Postgres. It uses a one way hash. We also
>> receive social security numbers, which we are required to read into the
>> database but not required to read out, so we hash these.
>>
>> Key management is one headache that I don't have. ;-)
ML> But key collisions may be.
ML> I agree with your reasoning, except it may introduce another risk. If the
ML> SSN is just used for an check, so you check it against a known record,
ML> OK, no problem. But if you use it as a search key, there may be a hash
ML> collision.
SHA-1 is 160 bits vs. 128 for MD5, so using SHA-1 would definitely avoid
collisions. I'm 99% sure there's no MD5 collisions either for USA-style
SSNs, which are currently 9 decimal digits and thus will fit in 30 bits.
Even at 10 digits (which may happen some day), it's just 33 bits.
On the other hand, this means that without some kind of global or local
salt, every SSN can easily be obtained from the hashed value if one only
precomputes the table of SSN to MD5 or SHA-1 hashes.
Ted
Martijn Lievaart
> ML> I agree with your reasoning, except it may introduce another risk.
> If the ML> SSN is just used for an check, so you check it against a
> known record, ML> OK, no problem. But if you use it as a search key,
> there may be a hash ML> collision.
>
> SHA-1 is 160 bits vs. 128 for MD5, so using SHA-1 would definitely avoid
> collisions. I'm 99% sure there's no MD5 collisions either for USA-style
> SSNs, which are currently 9 decimal digits and thus will fit in 30 bits.
> Even at 10 digits (which may happen some day), it's just 33 bits.
The fun part about a cryptographic secure hash is that you cannot predict
this. The chance of two documents hashing to the same value is very
small, but not zero.
The function of a cryptographic hash is that is is very, very difficult
to come up with another document that hashes to the same document as the
one you want to forge.
But whether there are collisions in this particular key space? You cannot
tell. You are 99% sure. So am I. But it doesn't matter if it's 99% or 1%,
if it is not 100%, it's not usable as a search key.
> On the other hand, this means that without some kind of global or local
> salt, every SSN can easily be obtained from the hashed value if one only
> precomputes the table of SSN to MD5 or SHA-1 hashes.
There is that. Very good point! The key space is not that large that a
brute force without precomputation cannot be ruled out either.
M4
Ted Zlatanov
ML> On Fri, 20 Jun 2008 11:34:01 -0500, Ted Zlatanov wrote:
ML> I agree with your reasoning, except it may introduce another risk.
>> If the ML> SSN is just used for an check, so you check it against a
>> known record, ML> OK, no problem. But if you use it as a search key,
>> there may be a hash ML> collision.
>>
>> SHA-1 is 160 bits vs. 128 for MD5, so using SHA-1 would definitely avoid
>> collisions. I'm 99% sure there's no MD5 collisions either for USA-style
>> SSNs, which are currently 9 decimal digits and thus will fit in 30 bits.
>> Even at 10 digits (which may happen some day), it's just 33 bits.
ML> The function of a cryptographic hash is that is is very, very difficult
ML> to come up with another document that hashes to the same document as the
ML> one you want to forge.
Well, yes, but also the Hamming distance should be optimized. Otherwise
the hash space can be searched with preference for the busier regions.
ML> But whether there are collisions in this particular key space? You cannot
ML> tell. You are 99% sure. So am I. But it doesn't matter if it's 99% or 1%,
ML> if it is not 100%, it's not usable as a search key.
OK, I tested it against all possible SSNs (in the NNNNNNNNN format in
ASCII, so really a 10-byte string). There were no MD5 collisions. I
didn't run it as a 4-byte packed binary format or anything else, it was
too boring :)
Ted