|
|
Posted by knal on 01/07/07 14:41
** 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.
Navigation:
[Reply to this message]
|