|
|
Posted by Gordon Burditt on 01/06/07 02:29
>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.
Navigation:
[Reply to this message]
|