469,081 Members | 1,805 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,081 developers. It's quick & easy.

secure login system

Hi group,

I need a login system for some 'private' pages.
Users should be pulled from a mysql DB.

Now, i've read a lot on login systems, and somehow there's _always_
the discussion with sessions (hijacking), dynamic IPs/Proxies.
One hand sessions on itself aren't secure (if in default tmp folder)
on the other hand, validating by IP would lock out a lot of users.

Now, what i wonder is, WHAT SHOULD I DO? I really don't know
where to start anymore because there are so much do's and dont's
on this ...

Frizzle.

May 4 '06 #1
8 1739
In article <11**********************@y43g2000cwc.googlegroups .com>,
ph********@gmail.com (frizzle) wrote:
I need a login system for some 'private' pages.
Users should be pulled from a mysql DB. Now, what i wonder is, WHAT SHOULD I DO? I really don't know
where to start anymore because there are so much do's and dont's
on this ...


First of all, google "SQL injection attack" and make certain that you
understand what this is and how to block it. This attack would not only
let anyone read all the passwords, it might (depending on your setup) let
them trash your database.

--
To reply email rafe, at the address cix co uk
May 4 '06 #2

Rafe Culpin wrote:
In article <11**********************@y43g2000cwc.googlegroups .com>,
ph********@gmail.com (frizzle) wrote:
I need a login system for some 'private' pages.
Users should be pulled from a mysql DB.

Now, what i wonder is, WHAT SHOULD I DO? I really don't know
where to start anymore because there are so much do's and dont's
on this ...


First of all, google "SQL injection attack" and make certain that you
understand what this is and how to block it. This attack would not only
let anyone read all the passwords, it might (depending on your setup) let
them trash your database.

--
To reply email rafe, at the address cix co uk


AFAIK using mysql_real_escape_string deals with that in all cases
if i parse any input through that... Thanks for reminding though how
important that is!

What i mean, is *globally* what path to walk to get where i want, what
system
/structure to use, because as i said, there are so much do's and
dont's.

E.g. should i use and sessions, ip validating, cookies (remember me)
and
mysql table with logged users, or what?

Frizzle.

May 4 '06 #3
frizzle wrote:
Rafe Culpin wrote:
In article <11**********************@y43g2000cwc.googlegroups .com>,
ph********@gmail.com (frizzle) wrote:
<snip> AFAIK using mysql_real_escape_string deals with that in all cases
if i parse any input through that... Thanks for reminding though how
important that is!

<snip>

PHP saints are moving away from mysql_real_escape_string() to
prepared statements
<http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html>

FWIW, For login system
<news:11**********************@z14g2000cwz.googleg roups.com> (
http://groups.google.com/group/comp....fad0eef59415a? )

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

May 6 '06 #4
R. Rajesh Jeba Anbiah wrote:
frizzle wrote:
Rafe Culpin wrote:
In article <11**********************@y43g2000cwc.googlegroups .com>,
ph********@gmail.com (frizzle) wrote:


<snip>
AFAIK using mysql_real_escape_string deals with that in all cases
if i parse any input through that... Thanks for reminding though how
important that is!


<snip>

PHP saints are moving away from mysql_real_escape_string() to
prepared statements
<http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html>

FWIW, For login system
<news:11**********************@z14g2000cwz.googleg roups.com> (
http://groups.google.com/group/comp....fad0eef59415a? )

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/


Some are, some aren't. Just another way of doing things.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
May 6 '06 #5

Jerry Stuckle wrote:
R. Rajesh Jeba Anbiah wrote:
frizzle wrote:
Rafe Culpin wrote:

In article <11**********************@y43g2000cwc.googlegroups .com>,
ph********@gmail.com (frizzle) wrote:


<snip>
AFAIK using mysql_real_escape_string deals with that in all cases
if i parse any input through that... Thanks for reminding though how
important that is!


<snip>

PHP saints are moving away from mysql_real_escape_string() to
prepared statements
<http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html>

FWIW, For login system
<news:11**********************@z14g2000cwz.googleg roups.com> (
http://groups.google.com/group/comp....fad0eef59415a? )

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/


Some are, some aren't. Just another way of doing things.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================


Wow, made my temperature rise there, but as i understand from the
comments, (in my case) mysql_real_escape_string is safe. Pfew.
AFAIK it wasn't some way of handling things as Jerry implies ...

I will look at your links later R. Rajesh Jeba Anbiah, thanks in
advance!

Frizzle.

May 7 '06 #6
frizzle wrote:
Jerry Stuckle wrote:
R. Rajesh Jeba Anbiah wrote:
frizzle wrote:
Rafe Culpin wrote:
>In article <11**********************@y43g2000cwc.googlegroups .com>,
>ph********@gmail.com (frizzle) wrote:

<snip>

AFAIK using mysql_real_escape_string deals with that in all cases
if i parse any input through that... Thanks for reminding though how
important that is!

<snip>

PHP saints are moving away from mysql_real_escape_string() to
prepared statements
<http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html>

FWIW, For login system
<news:11**********************@z14g2000cwz.goog legroups.com> (
http://groups.google.com/group/comp....fad0eef59415a? )

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/


Some are, some aren't. Just another way of doing things.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Wow, made my temperature rise there, but as i understand from the
comments, (in my case) mysql_real_escape_string is safe. Pfew.
AFAIK it wasn't some way of handling things as Jerry implies ...

I will look at your links later R. Rajesh Jeba Anbiah, thanks in
advance!

Frizzle.


Frizzle,

I didn't mean to make your temperature rise. My comment was strictly related to
Rajesh's comment that "PHP Saints" are moving towards prepared statements.

He indicates that all so-called "PHP Saints" think prepared statements are the
way to go. My only response is that the most experienced PHP people think
prepared statements are ONE way to go. Not necessarily the ONLY way.

Just like almost everything else, there are advantages and disadvantages to
using them.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
May 7 '06 #7

Jerry Stuckle wrote:
frizzle wrote:
Jerry Stuckle wrote:
R. Rajesh Jeba Anbiah wrote:

frizzle wrote:
>Rafe Culpin wrote:
>
>
>>In article <11**********************@y43g2000cwc.googlegroups .com>,
>>ph********@gmail.com (frizzle) wrote:

<snip>

>AFAIK using mysql_real_escape_string deals with that in all cases
>if i parse any input through that... Thanks for reminding though how
>important that is!

<snip>

PHP saints are moving away from mysql_real_escape_string() to
prepared statements
<http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html>

FWIW, For login system
<news:11**********************@z14g2000cwz.goog legroups.com> (
http://groups.google.com/group/comp....fad0eef59415a? )

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/
Some are, some aren't. Just another way of doing things.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

Wow, made my temperature rise there, but as i understand from the
comments, (in my case) mysql_real_escape_string is safe. Pfew.
AFAIK it wasn't some way of handling things as Jerry implies ...

I will look at your links later R. Rajesh Jeba Anbiah, thanks in
advance!

Frizzle.


Frizzle,

I didn't mean to make your temperature rise. My comment was strictly related to
Rajesh's comment that "PHP Saints" are moving towards prepared statements.

He indicates that all so-called "PHP Saints" think prepared statements are the
way to go. My only response is that the most experienced PHP people think
prepared statements are ONE way to go. Not necessarily the ONLY way.

Just like almost everything else, there are advantages and disadvantages to
using them.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================


Sorry, i messed up the reply. Rajesh made it rise.
You (and some background info) cooled it down again ;)

Frizzle.

May 8 '06 #8
Jerry Stuckle wrote:
He indicates that all so-called "PHP Saints" think prepared statements are the
way to go. My only response is that the most experienced PHP people think
prepared statements are ONE way to go. Not necessarily the ONLY way.


I'm afraid the PHP Jihadis don't undersand pluralism very well.

May 8 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by ojorus | last post: by
6 posts views Thread by Sarah Tanembaum | last post: by
reply views Thread by Holly | last post: by
6 posts views Thread by sintacks | last post: by
14 posts views Thread by knal | last post: by
8 posts views Thread by Harris Kosmidhs | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.