Perl Script

[dakin999]

I am looking for any generic perl script that is doing some thing
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]

I am looking for any generic perl script that is doing some thing
like following.

http://jobs.perl.org/

Sinan

--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

 

[Ron Bergin]

I am looking for any generic perl script that is doing some thing
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.

http://www.rentacoder.com/RentACoder/default.asp

 

[Dr.Ruud]

dakin999 schreef:

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?

 

[dakin999]

dakin999 schreef:



You have plain passwords in the database?

The passwords are in plain text in the database.

 

[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]

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.

That depends on what kind of encryption you use...

 

[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]

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.

It is still infinitely more secure to store passwords in an encrypted
form and reset lost passwords.

 

[Andrew DeFaria]

This particular database is Postgres. It uses a one way hash.

No, you don't understand. You could encrypt things yourself then just
store the encrypted result in the database. Then, later on, extract it
and reverse the encryption. IOW you're not limited to just what Postgres
(or any other database for that matter) has to offer.

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. ;-)

I'd really like to know who you work for - so I can avoid them!

 

[Ted Zlatanov]

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.

Yes but you need to consider the context of the discussion here. What
was being used was *no* encryption at all! Reversible encryption is 100
times better than plain text. That was my point. The rest of your post,
while interesting and correct, was orthogonal to the point I was making
so I will not comment on it.

 

[cartercc]

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]

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. ;-)

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]

I work for a large public university.

And that university would be....?

'Management' is mostly academic, not business.

Demonstrably false. Universities are business too - period.

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.

Screw the time off - I want money! You'd be amazed how little you care
about the other things when you make good money!

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.

Not in my book you're not CYAed...

In any event my point still stands - there are ways to use reversible
encryption to at least up the level of security a bit.

 

[Ted Zlatanov]

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.
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