469,327 Members | 1,230 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

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

Secure login tutorial

Hi there,

I'm looking for a secure login script for a sort-of-community site...
(PHP, MySQL, sessions, or maybe something else ... )
I know there are a lot of scripts out there, but none of them really
seem secure, or have other kind of flaws (like IP based login etc.).

Why i'm asking here, is because there's experience out there, and i
hope experience can tell me what my best shot is. I'm aware that i will
very probably have to do some consessions ...
I'm not a PHP-er, but i have some PHP experience ...

Thanks a lot.

Knal.

Jan 5 '07 #1
14 4680
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

knal schrieb:
Hi there,

I'm looking for a secure login script for a sort-of-community site...
(PHP, MySQL, sessions, or maybe something else ... )
I know there are a lot of scripts out there, but none of them really
seem secure, or have other kind of flaws (like IP based login etc.).
Hi,

What's your understanding of secure in this case?
>...

Thanks a lot.
Regards
Stefan
Knal.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)

iD8DBQFFnkWGyeCLzp/JKjARArezAJwLX2nEhqJ04h7281UHY2UuffN4TwCdH3xL
hXdROeUXauPS+htlXBNEUcs=
=C5SZ
-----END PGP SIGNATURE-----
Jan 5 '07 #2
I'd like to keep out unwanted guests. Members that have registered
(stored in MySQL DB) are allowed to login with usern/passw.
Along with that an admin-level is stored wich tells the site how much
rights the user has.

I know i can manage the login via sessions, but i've read only sessions
isn't secure. (Users can even "manually" force their own Session id).
I don't really else know how to explain what i mean with "secure".

Thanks.
On Jan 5, 1:33 pm, Stefan Rybacki <stefan.ryba...@gmx.netwrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

knal schrieb:
Hi there,
I'm looking for a secure login script for a sort-of-community site...
(PHP, MySQL, sessions, or maybe something else ... )
I know there are a lot of scripts out there, but none of them really
seem secure, or have other kind of flaws (like IP based login etc.).Hi,

What's your understanding of secure in this case?
...
Thanks a lot.Regards
Stefan
Knal.-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)

iD8DBQFFnkWGyeCLzp/JKjARArezAJwLX2nEhqJ04h7281UHY2UuffN4TwCdH3xL
hXdROeUXauPS+htlXBNEUcs=
=C5SZ
-----END PGP SIGNATURE-----
Jan 5 '07 #3
knal wrote:
Hi there,

I'm looking for a secure login script for a sort-of-community site...
(PHP, MySQL, sessions, or maybe something else ... )
I know there are a lot of scripts out there, but none of them really
seem secure, or have other kind of flaws (like IP based login etc.).

Why i'm asking here, is because there's experience out there, and i
hope experience can tell me what my best shot is. I'm aware that i will
very probably have to do some consessions ...
I'm not a PHP-er, but i have some PHP experience ...

Thanks a lot.

Knal.
Hi,

Define 'secure login' better.
What do you want to secure?

To name a few:
1)networktraffic-eavesdropper:
Are you afraid somebody is listening to the internettraffic and sees the
username/password?
If so, use https instead of http.

2) Are you afraid somebody goes to restricted pages?
Use a session, or use directory-access (eg .htaccess)

3) Are you afraid somebody can steal a session of somebody else?
make sure you understand HOW you PHP installation handles session.
Eg: (default) Is it storing the sessions in files in a common
temp-directory?
Then wonder if anybody else on the same machine (the server) can see them
and access them.
(PHP sessionfiles are stored with the sessionid in the filename, so anybody
who can get a listing of all files in the sessiondirectory, can steal all
sessions).

While sessions are incredible usefull, they also pose a possible
securityrisk if you do not understand how they work.
The better you understand how sessions work, the better you can think up how
to break them yourself.
Knowlegde = power here.

It is good you care about security, but if you seriously want to secure your
site more, you MUST dive into the details and get a grib on the matter.
It is not rocketscience, but it may take you some time to understand all the
stuff involved. And a lot of testing.
eg: On *nix servers you must understand the meaning of all (well, actually
most) permission-bits for the directory and the files to judge if the
sessionfile are 'safely' stored.

One thing that will surely NOT give you high security is implementing some
script somebody in here throws at you, or you find on the net, without
understanding what security means for eg networktraffic, session, etc..
Been there. :-/

Sorry for the long teacherlike answer, I am just the kid next door, but I
have been there (hacked sites).

Good luck.

Regards,
Erwin Moller
Jan 5 '07 #4
Thanks Erwin,

I don't mind the teacher-like answer, it's good that you emphasize the
importance of understanding the right things in the right way. I've
(tried to) read a lot on this subject, but most of it was PHP-docs.

The security part: i'm "afraid" of points one and two:
1 - if someone listens to my traffic, what use is it to try to secure
anything? (passw, usern. could easily be picked from the traffic)
2 - why would i want to secure something, if i have nothing to
restrict?

Anyway, what it comes to the HTTPS, i know there are a lot of community
sites out there, and i've never encountered one that managed it's
member profiles etc. via https, (this far, only my bank does ;) )

I'm not affraid of the third "argument", but i read upon some other
method where the visitor forces his own Session ID, wich replaces the
generated one. This means he can put in there (in the session info)
whatever he likes.

It's difficult to subscribe the kind of security-tightness i'm looking
for, since i don't know what "levels" of security there are out there.
Of course i'd like to keep hackers out, but i doubt if that's possible.
I'm hoping for a script that i can implement in a site that i'm at the
base of now, but also use it on sites in the future.

Users, passes etc. would "have to be" in a MySQL DB, since i don't want
to manually add every new member to a .htaccess file.

I hope this clears things up ..

Thanks for the help sofar!

On Jan 5, 1:44 pm, Erwin Moller
<since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
knal wrote:
Hi there,
I'm looking for a secure login script for a sort-of-community site...
(PHP, MySQL, sessions, or maybe something else ... )
I know there are a lot of scripts out there, but none of them really
seem secure, or have other kind of flaws (like IP based login etc.).
Why i'm asking here, is because there's experience out there, and i
hope experience can tell me what my best shot is. I'm aware that i will
very probably have to do some consessions ...
I'm not a PHP-er, but i have some PHP experience ...
Thanks a lot.
Knal.Hi,

Define 'secure login' better.
What do you want to secure?

To name a few:
1)networktraffic-eavesdropper:
Are you afraid somebody is listening to the internettraffic and sees the
username/password?
If so, use https instead of http.

2) Are you afraid somebody goes to restricted pages?
Use a session, or use directory-access (eg .htaccess)

3) Are you afraid somebody can steal a session of somebody else?
make sure you understand HOW you PHP installation handles session.
Eg: (default) Is it storing the sessions in files in a common
temp-directory?
Then wonder if anybody else on the same machine (the server) can see them
and access them.
(PHP sessionfiles are stored with the sessionid in the filename, so anybody
who can get a listing of all files in the sessiondirectory, can steal all
sessions).

While sessions are incredible usefull, they also pose a possible
securityrisk if you do not understand how they work.
The better you understand how sessions work, the better you can think up how
to break them yourself.
Knowlegde = power here.

It is good you care about security, but if you seriously want to secure your
site more, you MUST dive into the details and get a grib on the matter.
It is not rocketscience, but it may take you some time to understand all the
stuff involved. And a lot of testing.
eg: On *nix servers you must understand the meaning of all (well, actually
most) permission-bits for the directory and the files to judge if the
sessionfile are 'safely' stored.

One thing that will surely NOT give you high security is implementing some
script somebody in here throws at you, or you find on the net, without
understanding what security means for eg networktraffic, session, etc..
Been there. :-/

Sorry for the long teacherlike answer, I am just the kid next door, but I
have been there (hacked sites).

Good luck.

Regards,
Erwin Moller
Jan 5 '07 #5
knal wrote:
I'd like to keep out unwanted guests. Members that have registered
(stored in MySQL DB) are allowed to login with usern/passw.
Along with that an admin-level is stored wich tells the site how much
rights the user has.

I know i can manage the login via sessions, but i've read only
sessions isn't secure. (Users can even "manually" force their own
Session id). I don't really else know how to explain what i mean
with "secure".
So basically, "secure" as in "trusted".

I've created a method that stores the user's IP address and user agent
string in session variables. Users behind the same public IP address as
the original user may be able to forge the session ID, though.
http://dev.bd0.net/test/sessions_trusted.phps

--
Kim André Akerĝ
- ki******@NOSPAMbetadome.com
(remove NOSPAM to contact me directly)
Jan 5 '07 #6
..oO(knal)
>The security part: i'm "afraid" of points one and two:
1 - if someone listens to my traffic, what use is it to try to secure
anything? (passw, usern. could easily be picked from the traffic)
That's what SSL (HTTPS) is for.
>I'm not affraid of the third "argument", but i read upon some other
method where the visitor forces his own Session ID, wich replaces the
generated one. This means he can put in there (in the session info)
whatever he likes.
That's not possible. Manipulating the data that's stored in the session
would only be possible if you made really bad errors in your script. The
session data is stored on the server and can't be accessed directly from
the client side. Of course a user can fake his session ID, but that's
not really a problem - he just gets a new and fresh session. Trying to
guess another user's session ID in order to hijack it can be considered
impossible, unless you use network sniffing or some other dirty tricks.

Micha
Jan 5 '07 #7
In article <11**********************@v33g2000cwv.googlegroups .com>,
kn******@gmail.com (knal) wrote:
Users, passes etc. would "have to be" in a MySQL DB, since i don't want
to manually add every new member to a .htaccess file.
In that case one thing you *must* block is a "sql injection attack". If
you don't already know about this please google for it, there's a lot of
information out there.

Almost every example login script ignores it. It can give an attacker
complete control of your database, and in extreme cases the ability to run
arbitrary system commands.

--
To reply email rafe, at the address cix co uk
Jan 5 '07 #8
I'm aware of the SQL-injection danger. But by using
mysql_real_escape_string() in all queries (on wich the visitor has any
influence) i should be safe AFAIK ...

Thanks for the mention.

On Jan 5, 2:27 pm, nos...@see.sig.to.reply (Rafe Culpin) wrote:
In article <1168002079.875499.106...@v33g2000cwv.googlegroups .com>,

knalp...@gmail.com (knal) wrote:
Users, passes etc. would "have to be" in a MySQL DB, since i don't want
to manually add every new member to a .htaccess file.In that case one thing you *must* block is a "sql injection attack". If
you don't already know about this please google for it, there's a lot of
information out there.

Almost every example login script ignores it. It can give an attacker
complete control of your database, and in extreme cases the ability to run
arbitrary system commands.

--
To reply email rafe, at the address cix co uk
Jan 5 '07 #9
Michael Fesser wrote:
.oO(knal)
>>The security part: i'm "afraid" of points one and two:
1 - if someone listens to my traffic, what use is it to try to secure
anything? (passw, usern. could easily be picked from the traffic)

That's what SSL (HTTPS) is for.
>>I'm not affraid of the third "argument", but i read upon some other
method where the visitor forces his own Session ID, wich replaces the
generated one. This means he can put in there (in the session info)
whatever he likes.

That's not possible.
Hi Misha,

I think he is refering to 'session fixation' when he writes about 'forcing a
sessionid on another user'.

A link on php.net is provided on:
http://nl3.php.net/manual/en/ref.session.php
under the chapter 'Sessions and security'.

Regards,
Erwin Moller

Manipulating the data that's stored in the session
would only be possible if you made really bad errors in your script. The
session data is stored on the server and can't be accessed directly from
the client side. Of course a user can fake his session ID, but that's
not really a problem - he just gets a new and fresh session. Trying to
guess another user's session ID in order to hijack it can be considered
impossible, unless you use network sniffing or some other dirty tricks.

Micha
Jan 5 '07 #10
Yes Erwin, i meant 'session fixation', but couldn't recall the term...

On 5 jan, 09:58, Erwin Moller
<since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
Michael Fesser wrote:
.oO(knal)
>The security part: i'm "afraid" of points one and two:
1 - if someone listens to my traffic, what use is it to try to secure
anything? (passw, usern. could easily be picked from the traffic)
That's what SSL (HTTPS) is for.
>I'm not affraid of the third "argument", but i read upon some other
method where the visitor forces his own Session ID, wich replaces the
generated one. This means he can put in there (in the session info)
whatever he likes.
That's not possible.Hi Misha,

I think he is refering to 'session fixation' when he writes about 'forcing a
sessionid on another user'.

A link on php.net is provided on:http://nl3.php.net/manual/en/ref.session.php
under the chapter 'Sessions and security'.

Regards,
Erwin Moller

Manipulating the data that's stored in the session
would only be possible if you made really bad errors in your script. The
session data is stored on the server and can't be accessed directly from
the client side. Of course a user can fake his session ID, but that's
not really a problem - he just gets a new and fresh session. Trying to
guess another user's session ID in order to hijack it can be considered
impossible, unless you use network sniffing or some other dirty tricks.
Micha- Tekst uit oorspronkelijk bericht niet weergeven -- Tekst uit oorspronkelijk bericht weergeven -
Jan 5 '07 #11
..oO(Erwin Moller)
>I think he is refering to 'session fixation' when he writes about 'forcing a
sessionid on another user'.
[...]
OK. Interesting reading.

Micha
Jan 6 '07 #12
>The security part: i'm "afraid" of points one and two:
>1 - if someone listens to my traffic, what use is it to try to secure
anything? (passw, usern. could easily be picked from the traffic)
Not if it's encrypted with SSL.
>2 - why would i want to secure something, if i have nothing to
restrict?
Why do you want your users to log in at all? They might have private
profile information (e.g. email address, private messages, credit
card numbers) that they don't want public. You may want to prevent
users from doing something in the name of someone else (e.g. post
in another user's name). Or you might not. It depends on what the
site is for.
>Anyway, what it comes to the HTTPS, i know there are a lot of community
sites out there, and i've never encountered one that managed it's
member profiles etc. via https, (this far, only my bank does ;) )
E-commerce sites and banks usually use https. It's a bit overkill
for just email or social networking, unless, of course, you regularly
receive missile launch orders in your email box.
>I'm not affraid of the third "argument", but i read upon some other
method where the visitor forces his own Session ID, wich replaces the
generated one. This means he can put in there (in the session info)
whatever he likes.
You can force your own Session ID trivially (edit a saved cookies
file for your browser). This is pointless unless you happen to
guess (or otherwise find out, say, by sniffing traffic) the Session
ID of another active session. Knowing a Session ID does *NOT* give
you the ability to change the $_SESSION[] data associated with that
ID, except by going through the PHP code, so, for example, the
chances of finding a session ID with $_SESSION['logged_in'] = 1
(another session in use) are extremely low. Session IDs are typically
generated using large random numbers that require much more guessing
than anyone's lifetime. The programmer can reduce the problem
further by timing out old, abandoned sessions, and users can reduce
the problem by using the "LOGOUT" button.
>It's difficult to subscribe the kind of security-tightness i'm looking
for, since i don't know what "levels" of security there are out there.
Of course i'd like to keep hackers out, but i doubt if that's possible.
There are some easy ways to keep hackers out, but there are costs to
these:

- Don't power up the system.
- Don't connect the system to a network.
- Make your site absolutely READ-ONLY: no forms, logins, search, or anything
like that. Makes a boring site, though.
- Don't let *ANYONE* log in. Sorta defeats the purpose, probably.

Consider: What *DO* you want authorized users to be able to do?
(e.g. log in, change their password, post messages in their name,
read private messages to them) What do you want them to NOT do?
(e.g. post messages in someone else's name, read private messages
of other people, change someone else's password) What do you NOT
want *UN*authorized users to be able to do? (e.g. post messages
at all)

Setting up multiple levels of authorization is fairly easy, given
an existing login system. The username they give refers to a
database entry which has the password (encrypted or whatever) and
some stuff that indicates what privileges they have. Then you just
have to add checks all over to make sure they have the privileges
required before they are allowed to use them. (e.g. admin level is
required to change someone else's password).

What threats are you concerned about? Traffic sniffing may be a
risk if your wife or parents are snoopy or government agencies are
involved. Are you worried about brother and sister, who use the
same computer, stealing each other's passwords? Are you worried
about "session hijacking" when someone goes to lunch while logged
in and someone else sits down at his computer? Or maybe you just
want a simple, "keep honest people honest" password setup.
>I'm hoping for a script that i can implement in a site that i'm at the
base of now, but also use it on sites in the future.
>Users, passes etc. would "have to be" in a MySQL DB, since i don't want
to manually add every new member to a .htaccess file.
Jan 6 '07 #13
Check out the session_regenerate_id function. This could help you out
with session fixation.

See: http://php.net/session_regenerate_id

On Jan 5, 8:36 am, "knal" <knalp...@gmail.comwrote:
Yes Erwin, i meant 'session fixation', but couldn't recall the term...

On 5 jan, 09:58, Erwin Moller

<since_humans_read_this_I_am_spammed_too_m...@spam yourself.comwrote:
Michael Fesser wrote:
.oO(knal)
>>The security part: i'm "afraid" of points one and two:
>>1 - if someone listens to my traffic, what use is it to try to secure
>>anything? (passw, usern. could easily be picked from the traffic)
That's what SSL (HTTPS) is for.
>>I'm not affraid of the third "argument", but i read upon some other
>>method where the visitor forces his own Session ID, wich replaces the
>>generated one. This means he can put in there (in the session info)
>>whatever he likes.
That's not possible.Hi Misha,
I think he is refering to 'session fixation' when he writes about 'forcing a
sessionid on another user'.
A link on php.net is provided on:http://nl3.php.net/manual/en/ref.session.php
under the chapter 'Sessions and security'.
Regards,
Erwin Moller
Manipulating the data that's stored in the session
would only be possible if you made really bad errors in your script. The
session data is stored on the server and can't be accessed directly from
the client side. Of course a user can fake his session ID, but that's
not really a problem - he just gets a new and fresh session. Trying to
guess another user's session ID in order to hijack it can be considered
impossible, unless you use network sniffing or some other dirty tricks.
Micha- Tekst uit oorspronkelijk bericht niet weergeven -- Tekst uit oorspronkelijk bericht weergeven -
Jan 6 '07 #14
** QUOTE **
Consider: What *DO* you want authorized users to be able to do?
(e.g. log in, change their password, post messages in their name,
read private messages to them) What do you want them to NOT do?
(e.g. post messages in someone else's name, read private messages
of other people, change someone else's password) What do you NOT
want *UN*authorized users to be able to do? (e.g. post messages
at all)
** QUOTE **

This roughly describes what i want. I don't expect any missile-orders
any time soon, so that's out of the consideration.
What i'm building is a DJ-community sites. With blog functionality etc,
but i also want to protect some files based on level of authorization.

I was sort of hoping to get an idea of how most programmers structure
their login-systems ...
I know there's always a right type for the right job, but right now, i
don't really know what's safe at all ...

I'm not affraid of people messing in my Sessions folder, but of course
i'd like to keep the system as tight as relevantly possible (?).
I'm not sure if people here are familiar with Expression Engine, but i
think i'm looking for that kind of safety...
Don't really know how to put it in words.

Thanks.

On 5 jan, 21:29, gordonb.zo...@burditt.org (Gordon Burditt) wrote:
The security part: i'm "afraid" of points one and two:
1 - if someone listens to my traffic, what use is it to try to secure
anything? (passw, usern. could easily be picked from the traffic)Not if it's encrypted with SSL.
2 - why would i want to secure something, if i have nothing to
restrict?Why do you want your users to log in at all? They might have private
profile information (e.g. email address, private messages, credit
card numbers) that they don't want public. You may want to prevent
users from doing something in the name of someone else (e.g. post
in another user's name). Or you might not. It depends on what the
site is for.
Anyway, what it comes to the HTTPS, i know there are a lot of community
sites out there, and i've never encountered one that managed it's
member profiles etc. via https, (this far, only my bank does ;) )E-commerce sites and banks usually use https. It's a bit overkill
for just email or social networking, unless, of course, you regularly
receive missile launch orders in your email box.
I'm not affraid of the third "argument", but i read upon some other
method where the visitor forces his own Session ID, wich replaces the
generated one. This means he can put in there (in the session info)
whatever he likes.You can force your own Session ID trivially (edit a saved cookies
file for your browser). This is pointless unless you happen to
guess (or otherwise find out, say, by sniffing traffic) the Session
ID of another active session. Knowing a Session ID does *NOT* give
you the ability to change the $_SESSION[] data associated with that
ID, except by going through the PHP code, so, for example, the
chances of finding a session ID with $_SESSION['logged_in'] = 1
(another session in use) are extremely low. Session IDs are typically
generated using large random numbers that require much more guessing
than anyone's lifetime. The programmer can reduce the problem
further by timing out old, abandoned sessions, and users can reduce
the problem by using the "LOGOUT" button.
It's difficult to subscribe the kind of security-tightness i'm looking
for, since i don't know what "levels" of security there are out there.
Of course i'd like to keep hackers out, but i doubt if that's possible.There are some easy ways to keep hackers out, but there are costs to
these:

- Don't power up the system.
- Don't connect the system to a network.
- Make your site absolutely READ-ONLY: no forms, logins, search, or anything
like that. Makes a boring site, though.
- Don't let *ANYONE* log in. Sorta defeats the purpose, probably.

Consider: What *DO* you want authorized users to be able to do?
(e.g. log in, change their password, post messages in their name,
read private messages to them) What do you want them to NOT do?
(e.g. post messages in someone else's name, read private messages
of other people, change someone else's password) What do you NOT
want *UN*authorized users to be able to do? (e.g. post messages
at all)

Setting up multiple levels of authorization is fairly easy, given
an existing login system. The username they give refers to a
database entry which has the password (encrypted or whatever) and
some stuff that indicates what privileges they have. Then you just
have to add checks all over to make sure they have the privileges
required before they are allowed to use them. (e.g. admin level is
required to change someone else's password).

What threats are you concerned about? Traffic sniffing may be a
risk if your wife or parents are snoopy or government agencies are
involved. Are you worried about brother and sister, who use the
same computer, stealing each other's passwords? Are you worried
about "session hijacking" when someone goes to lunch while logged
in and someone else sits down at his computer? Or maybe you just
want a simple, "keep honest people honest" password setup.
I'm hoping for a script that i can implement in a site that i'm at the
base of now, but also use it on sites in the future.
Users, passes etc. would "have to be" in a MySQL DB, since i don't want
to manually add every new member to a .htaccess file.
Jan 7 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Bennett Haselton | last post: by
6 posts views Thread by Sarah Tanembaum | last post: by
2 posts views Thread by H | last post: by
1 post views Thread by sharp2037 | last post: by
reply views Thread by Holly | last post: by
4 posts views Thread by 2good2b | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.