, new problem here I've got a html form submitting a username,
password, and realm to a perl script. this is fine and dandy, but the
one MAJR problem i noticed is that it passes on variables (username &
realm) in the address bar. I don't know why i'm just thinking of this,
i know this. but still is there any way that I can keep these from
showing?
Example:
WHAT IS PASSED CURRENTLY--
but anyone who knows a valid user in that realm, could change
information a gain full access by going to--
So temp solution can i get rid of the form input from showing in
the address bar? perm solution no idea THIS WULD HELP!!!
Cookies? I have no idea I turn to you once again groups!!!

Tim wrote:
I've got a html form submitting a username, password, and realm to a
perl script. this is fine and dandy, but the one MAJR problem i
noticed is that it passes on variables (username & realm) in the
address bar.

<snip>

So temp solution can i get rid of the form input from showing
in the address bar? perm solution no idea THIS WULD HELP!!!
Cookies?

Yes, a cookie might be a solution. Changing the script so it makes PST
requests instead of GET, and pass the info on via hidden input tags, is
another option.

Tim (callmetimmay@comcast.net) wrote:
: , new problem here I've got a html form submitting a username,
: password, and realm to a perl script. this is fine and dandy, but the
: one MAJR problem i noticed is that it passes on variables (username &
: realm) in the address bar. I don't know why i'm just thinking of this,
: i know this. but still is there any way that I can keep these from
: showing?

: Example:
: WHAT IS PASSED CURRENTLY--
:

: but anyone who knows a valid user in that realm, could change
: information a gain full access by going to--
:

: So temp solution can i get rid of the form input from showing in
: the address bar? perm solution no idea THIS WULD HELP!!!
: Cookies? I have no idea I turn to you once again groups!!!

Use PST method when submitting form data that should not be shown in the
address bar.

Use a password in addition to a username so that the username by itself is
not enough to login.

Currently I am using PST, but it posts to a page, then redirects so
i have to pass arguments by doing frame.cgi?username=xxxxx,realm=xxxxx.
If I add in password to the query string, i risk password security
anyone walking by could look and see their password.

if you can send me an e-mail, i could send you the address and
specifics to show you exactly what's going on

I don't think hidden tags would work isn't that hidden in HTML
still when you post, you would be posting that value into the address,
right?

Tim wrote:
if you can send me an e-mail, i could send you the address and
specifics to show you exactly what's going on

I'd be surprised if Malcolm did that. Usenet is not a free helpdesk, so
you'd better make efforts in explaining your problem properly.

Also, you may find the advices in this document helpful:
http://www.catb.org/~esr/faqs/smart-questions.html

i c it's just i know since i am a beginning perl programmer, I know
there are millions of loopholes i need to work out. I just wanted to
restrict a single ip to the page so I'm not posting a url publicly. i
hope you understand
sorry

"Tim" <callmetimmay@comcast.netsaid:
>Currently I am using PST, but it posts to a page, then redirects so
>i have to pass arguments by doing frame.cgi?username=xxxxx,realm=xxxxx.
>If I add in password to the query string, i risk password security
>anyone walking by could look and see their password.

, does the page receiving the username&password PST action have a reason
to redirect? I guess it has -- but it could do other things along with
the redirect, namely create a session identifier and pass on that instead
of the username&password. Data of this session id should be as random as
you can manage, and it should be stored into some kind of store of session
information. In the store there could also be some kind of timestamp as of
when the session was last accessed, so that timed-out sessions can be purged.

All future pages visited during the session would then need to check the
session id passed from the browser against the session id store.

The session id can either be passed as a query argument (at least I wouldn't
expect anyone to memorize 20-or-so characters of gibberish at a glance), or
it can be passed as a cookie (if the users browser has cookies enabled).

I also had this problem. At first I had 3 different logins for 3
different section of my site

was for our clients, one was for our agents, and one was for the
staff. The would have to go to the correct login page to login to
thier account.

Latter down the line I wanted to remove all the separate logins so I
could put the login in one place right on the home page. so I
added a drop-down that lets them select which section to login to the
user_name, password, and section are posted to a single login page.
This page checks thier login and redirects them to the main page of the
correct section.

However, I found, as you did, that upon redirection the variables were
also passed in the address bar.

What I had to do was this.
1. Check the user_name, password in the DB
2. Update a field in the database with a random number.
3. Put this same random number, along with the user_name in a cookie.
4. each page check the user name and the random value in the cookie
against what is in the database.
5. log-out or time-out, erase the random value in the DB.

course that was just my solution (and I was already using random
numbers before in my logins)

Good luck

Actually another thought is to use md5 (or any other equivalent)
encryption on the fields then all that is passed in the address bar is
gobbly gook that only you know what it means

Christopher F. Falzone said the following on 11/22/2005 17:02 +0200:

Actually another thought is to use md5 (or any other equivalent)
encryption on the fields then all that is passed in the address bar is
gobbly gook that only you know what it means

Encryption is not my forte, but AFAIK md5 is a checksum, not an
encryption. I guess md5 is not strong enough to protect data.

My bad, MD5 isn't encryption but it's more than just a checksum (a
checksum being something that is added to a string to ensure that the
string is valid like a CRC). MD5 can be used as a checksum but
that is not it's only purpose they are much better ways to compute
checksums.

md5 is a Message Digest that uses a 128-bit hash, meaning that the
whole string is hashed into something compleatly different and that no
2 strings are hashed to the same value (well almost but it's
theorettically improbable).

A few years ago some geeks put together a super computer that could
break MD5 it took this super computer weeks to break it.

My theory is if someone wanted into your site, and they have the
resources and time to break md5, there are much better methods to break
into you site, so what's the point of worrying about it If you are
that worried about it go buy yourself an SSL like we did, to
protect you're customer's data and don't do stupid stuff like
passing the username and passwork in the address bar :)

Christopher F. Falzone said the following on 11/23/2005 14:55 +0200:

My bad, MD5 isn't encryption but it's more than just a checksum (a
checksum being something that is added to a string to ensure that the
string is valid like a CRC). MD5 can be used as a checksum but
that is not it's only purpose they are much better ways to compute
checksums.

K, this I didn't know, but checksums aren't my forte as well.

md5 is a Message Digest that uses a 128-bit hash, meaning that the
whole string is hashed into something compleatly different and that no
2 strings are hashed to the same value (well almost but it's
theorettically improbable).

Interesting.

A few years ago some geeks put together a super computer that could
break MD5 it took this super computer weeks to break it.

Which machines today will probably break in far less time.

My theory is if someone wanted into your site, and they have the
resources and time to break md5, there are much better methods to break
into you site, so what's the point of worrying about it []

It's better to protect yourself with multiple layers than just one.
Because there are other attack vectors doesn't mean things like this are
not important.

[] If you are
that worried about it []

I'm not, well, a little, I just had a problem with calling md5 an
encryption which might give people a false sence of security.

[] go buy yourself an SSL like we did, to
protect you're customer's data and don't do stupid stuff like
passing the username and passwork in the address bar :)

course I don't! :)

And this is far better advise!