[Fwd: failure notice]

Could someone from the department of clue enforcement please tell
Rachakonda Muralikrishna to unblock his mail account?
If his account blocks mails, he won't be able to unsubscribe.

Alexander

-------- Original Message --------
Subject: failure notice
Date: 25 Oct 2006 08:16:02 -0000
From: bounce@rediffmail.com
To: alexander@foken.de



Hi. This is the qmail-send program at rediffmail.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
You have been blocked by the recipient

--- Enclosed is a copy of the message.

Subject:
Re: DBD-Oracle: nmake fails on Windows
From:
Alexander Foken
Date:
Wed, 25 Oct 2006 10:18:25 +0200

To:
rachakonda muralikrishna
CC:
dbi-users


1. Stop spamming this group.
2. Send an empty mail to dbi-users-unsubscribe@perl.org and follow the
instructions returned to you.

Alexander

On 25.10.2006 06:54, rachakonda muralikrishna wrote:
Im unable to unsubscribe from this group.

Can anybody help me.

Thanks,
Murali


--
Alexander Foken
mailto:alexander@foken.de http://www.foken.de/alexander/

Re: [Fwd: failure notice]

Alexander Foken wrote:
> Could someone from the department of clue enforcement please tell
> Rachakonda Muralikrishna to unblock his mail account?
> If his account blocks mails, he won't be able to unsubscribe.

Normally we like to let these lusers suffer a little and work it out
themselves, but since you asked so nicely, clue enforcemnt has been
delivered and the subscription terminated with extreme prejudice.

Thanks,
David

--
Much of the propaganda that passes for news in our own society is given
to immobilising and pacifying people and diverting them from the idea
that they can confront power. -- John Pilger

Best authentication methods for CGI <- PERL -> DBI

Hello Dist,
What are some best practices on an initial form taking a PW/ID from a
user to login. Right now one method which seems to be really unsecured,
is to take them, check them against the PW/ID stored in the database and
permit/deny against that. And for passing this info - or a token -
between pages, using URL via the URI path and/or using hidden 'post'ed
variables.

Anyone who would like to email me offline on details, you're welcomed.

Thanks In Advance,

--
Email: louis.gonzales@linuxlouis.net
WebSite: http://www.linuxlouis.net
"Open the pod bay doors HAL!" -2001: A Space Odyssey
"Good morning starshine, the Earth says hello." -Willy Wonka

Re: Best authentication methods for CGI <- PERL -> DBI

On Thu, 26 Oct 2006 14:36:41 -0400, louis gonzales wrote:

Hi Louis

> What are some best practices on an initial form taking a PW/ID from
> a user to login. Right now one method which seems to be really
> unsecured, is to take them, check them against the PW/ID stored in

How about storing a cyptographic hash - a digest - of the password in the
database?

A module like Javascript::SHA1 can embed the hashing code in the HTML form,=
and
then you only transmit the digest across the internet (when the form is
submitted).

This is a large and fascinating topic.
--
Cheers
Ron Savage, ron@savage.net.au on 27/10/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: Best authentication methods for CGI <- PERL -> DBI

louis gonzales wrote:
> Hello Dist,
> What are some best practices on an initial form taking a PW/ID from a
> user to login. Right now one method which seems to be really
> unsecured, is to take them, check them against the PW/ID stored in the
> database and permit/deny against that. And for passing this info - or
> a token - between pages, using URL via the URI path and/or using
> hidden 'post'ed variables.
>
> Anyone who would like to email me offline on details, you're welcomed.
>
> Thanks In Advance,
>
Well, this is a very complex topic! I have spent considerable time
working out a solution that appears secure.

There are several decisions you must make up front:

How does the the database store passwords? Either plaintext, encrypted,
or hashed. Plaintext or known key encrypted allows the program to
automatically email passwords to end users -- who always forget their
passwords. Hashed keys are one way, and are useless to intruders other
than to verify that the password hashed by the client code (javascript)
= the database password. If the password is encrypted, where are the
keys? If a hacker can look at the server code, they can find the key,
and decrypt every password. This is important to realize if you are
going to store sensitive information (ie national id numbers, credit
card, etc). Encryption is only strong if the key is protected.

The next problem you need to deal with is state tracking. After a user
authenticates, how do you track them from page to page (keep them
"logged in"?

Your choices determine what you can do, and the limitations you will face.

Here's the solution I use for http:// style access to web enabled
database apps. I assume the connection is prone to sniffing. I assume
that users will forget passwords. Passwords are reset to random values,
and emailed to the address I've collected at account creation.

Upon first connect to website, Apache sets unique session cookie (as
defined in httpd.conf) which we'll call SC for short

Apache2 config:
# User tracking cookies
CookieTracking on
CookieName SC
CookieDomain .domain.com
CookieStyle Cookie
CookieExpires "8 hours"

The use is not logged in at this point. Next, the use clicks something
that asks for a usename and password, be it a form, or some AJAXy
thing. The client javascript code takes the password and MD5 sums it,
and sends that as the password along with the cleartext username. The
MD5 javascript code can be found online. The dojo.crypto.md5 code works
as well, but be aware that you may have to strip off the "==" at the end
of the string at the server side code.

On the server, the code receives two ARGS, the username and password.
Here's where you can go two ways, depending on how paranoid you are. If
the web app can read the user credentials table (that you built), all
you need to do is retrieve the stored password hash (you are using MD5
to store passwords), and see if they match. If they do, the user knows
the correct password.

Another approach is to MD5 sum the SC, and the password on the client,
and not trust the web app account to access passwords stored in the
database. Use a stored procedure with definer rights to create a
function that takes the hashed password concatenation from the client,
the current session key from the apache request object, and returns true
or false if the database computed hash matches. In this case, you can
store the passwords in plaintext. The stored procedure(s) that the web
application use to access the user table prevent the password from ever
being disclosed to the application, even though they aren't encrypted.

Assuming that the user authenticated, now you need to track this user as
"logged in". Create two new cookies. One cookie is the record id of
the user in the database, let's call this ID. The second cookie is used
to protect against someone setting a "logged in" ID cookie to any value
they wish. This cookie is formed as follows. Take the ID value, SC,
browser string, and first two octets of the IP address A.B (from
A.B.C.D), along with a long 32 character secret string that only the
application knows. Hash this string using SHAxxx and store the result
in the in a key called MAC or something.

Now, for each page that a user visits, if there's an ID and MAC cookie,
take the ID, SC, browser string, A.B, and your secret and compute the
MAC. If the user provided MAC matches, then you know that the ID is
valid, and you can use that as a primary key for looking up user privileges.

This method works through proxies, since the IP address of multiple
proxies is unlikely to change the first two octets of the client IP (if
it does in your case, drop the A.B from computing the MAC).


I have another case where user passwords are stored in LDAP. Therefore,
I need the plaintext password from the user. The only solution I have
found is to use https:// to send the data. This worked for me, since
most of the data in the database was personal to begin with. A solution
to not use https (SSL) would be public key encryption. I haven't found
a good implementation of PKE in javascript for the client as of yet.
PKE is needed, because you can't safely send the encryption key to the
client, since the channel you send it is insecure.

Hope this helps.

Andrew Baumhauer
n-Capture Consulting

Re: Best authentication methods for CGI <- PERL -> DBI

Andrew/Ron(Savage),
I appreciate both of your feedback! Many of the concerns you've pointed
out are the exact ones I want to address. I think that https: with
SSL/TLS is probably the first and foremost step to safeguard, secondly,
using some form of hashed password. I'm always interested in ideas and
methods.

Thanks very much!


Andrew Baumhauer wrote:

> louis gonzales wrote:
>
>> Hello Dist,
>> What are some best practices on an initial form taking a PW/ID from a
>> user to login. Right now one method which seems to be really
>> unsecured, is to take them, check them against the PW/ID stored in
>> the database and permit/deny against that. And for passing this info
>> - or a token - between pages, using URL via the URI path and/or using
>> hidden 'post'ed variables.
>>
>> Anyone who would like to email me offline on details, you're welcomed.
>>
>> Thanks In Advance,
>>
> Well, this is a very complex topic! I have spent considerable time
> working out a solution that appears secure.
>
> There are several decisions you must make up front:
>
> How does the the database store passwords? Either plaintext,
> encrypted, or hashed. Plaintext or known key encrypted allows the
> program to automatically email passwords to end users -- who always
> forget their passwords. Hashed keys are one way, and are useless to
> intruders other than to verify that the password hashed by the client
> code (javascript) = the database password. If the password is
> encrypted, where are the keys? If a hacker can look at the server
> code, they can find the key, and decrypt every password. This is
> important to realize if you are going to store sensitive information
> (ie national id numbers, credit card, etc). Encryption is only
> strong if the key is protected.
>
> The next problem you need to deal with is state tracking. After a
> user authenticates, how do you track them from page to page (keep them
> "logged in"?
>
> Your choices determine what you can do, and the limitations you will
> face.
>
> Here's the solution I use for http:// style access to web enabled
> database apps. I assume the connection is prone to sniffing. I
> assume that users will forget passwords. Passwords are reset to
> random values, and emailed to the address I've collected at account
> creation.
>
> Upon first connect to website, Apache sets unique session cookie (as
> defined in httpd.conf) which we'll call SC for short
>
> Apache2 config:
> # User tracking cookies
> CookieTracking on
> CookieName SC
> CookieDomain .domain.com
> CookieStyle Cookie
> CookieExpires "8 hours"
>
> The use is not logged in at this point. Next, the use clicks
> something that asks for a usename and password, be it a form, or some
> AJAXy thing. The client javascript code takes the password and MD5
> sums it, and sends that as the password along with the cleartext
> username. The MD5 javascript code can be found online. The
> dojo.crypto.md5 code works as well, but be aware that you may have to
> strip off the "==" at the end of the string at the server side code.
>
> On the server, the code receives two ARGS, the username and password.
> Here's where you can go two ways, depending on how paranoid you are.
> If the web app can read the user credentials table (that you built),
> all you need to do is retrieve the stored password hash (you are using
> MD5 to store passwords), and see if they match. If they do, the user
> knows the correct password.
>
> Another approach is to MD5 sum the SC, and the password on the client,
> and not trust the web app account to access passwords stored in the
> database. Use a stored procedure with definer rights to create a
> function that takes the hashed password concatenation from the client,
> the current session key from the apache request object, and returns
> true or false if the database computed hash matches. In this case,
> you can store the passwords in plaintext. The stored procedure(s)
> that the web application use to access the user table prevent the
> password from ever being disclosed to the application, even though
> they aren't encrypted.
>
> Assuming that the user authenticated, now you need to track this user
> as "logged in". Create two new cookies. One cookie is the record id
> of the user in the database, let's call this ID. The second cookie is
> used to protect against someone setting a "logged in" ID cookie to any
> value they wish. This cookie is formed as follows. Take the ID
> value, SC, browser string, and first two octets of the IP address A.B
> (from A.B.C.D), along with a long 32 character secret string that only
> the application knows. Hash this string using SHAxxx and store the
> result in the in a key called MAC or something.
>
> Now, for each page that a user visits, if there's an ID and MAC
> cookie, take the ID, SC, browser string, A.B, and your secret and
> compute the MAC. If the user provided MAC matches, then you know that
> the ID is valid, and you can use that as a primary key for looking up
> user privileges.
>
> This method works through proxies, since the IP address of multiple
> proxies is unlikely to change the first two octets of the client IP
> (if it does in your case, drop the A.B from computing the MAC).
>
>
> I have another case where user passwords are stored in LDAP.
> Therefore, I need the plaintext password from the user. The only
> solution I have found is to use https:// to send the data. This
> worked for me, since most of the data in the database was personal to
> begin with. A solution to not use https (SSL) would be public key
> encryption. I haven't found a good implementation of PKE in
> javascript for the client as of yet. PKE is needed, because you can't
> safely send the encryption key to the client, since the channel you
> send it is insecure.
>
> Hope this helps.
>
> Andrew Baumhauer
> n-Capture Consulting



--
Email: louis.gonzales@linuxlouis.net
WebSite: http://www.linuxlouis.net
"Open the pod bay doors HAL!" -2001: A Space Odyssey
"Good morning starshine, the Earth says hello." -Willy Wonka

Re: Best authentication methods for CGI <- PERL -> DBI

---- louis gonzales wrote:
> Hello Dist,
> What are some best practices on an initial form taking a PW/ID from a
> user to login.

Personally and professionally, I prefer to maintain my account structure in an external database, such as LDAP, and let the webserver do the actual authentication (session based authentication, doesn't get lost from page to page). I then only have to manage authorization and access control (using $ENV{REMOTE_USER}). Fact is, I've so far managed to avoid having to write my own authentication scheme, but wouldn't anyway, since there are so many good modules[1] out there...

There are many tools[2] for letting users manage their own LDAP account details, which you can wrap in a form of your liking. It is also possible to put together an page that would allow them to reset their password with knowledge of a "secret" question/answer passphrase. It's a bit of a classic, but it's a good classic, one the works...

1) http://www.modperl.com/
2) http://ldap.perl.org/

HTH,
amonotod

--

`\|||/ amonotod@ | sun|perl|windows
(@@) charter.net | sysadmin|dba
ooO_(_)_Ooo____________________________________
_____|_____|_____|_____|_____|_____|_____|_____|