How secure is login with session variables?

[RichardODreamweaver]

I'm using email address as primary key and propogating $MM_Username on login with user authentication.

I've also obviously got "Password and $MM_UserGroup.

How secure is this sytem against hacking?

I know it doesn't appear in the address bar but is it possible to alter session variables using code in the address bar or any other way?

I've set up UserGroups for new registrations that only allows own account viewing (page restrictions) and I don't want anyone else under data protection act (unless specified) to be able to access other records.

Thanks

[Newsgroup_User]

"RichardODreamweaver" <webforumsuser@macromedia.com> wrote in message
news:eutfnq$bcs$1@forums.macromedia.com...
> I'm using email address as primary key and propogating $MM_Username on
> login
> with user authentication.
>
> I've also obviously got "Password and $MM_UserGroup.
>
> How secure is this sytem against hacking?

As secure as you make it. :)
If the user logs in over plain HTTP, then people could potentially listen in
on the traffic. Over HTTPS, at least the login is encrypted. Still, what's
more important is the security on the web server itself. If someone can
break in there, then it doesn't matter what kind of security you've got on
your web site.

>
> I know it doesn't appear in the address bar but is it possible to alter
> session variables using code in the address bar or any other way?
>

Only if you let it happen. For instance, not validating user input before
storing it in the session. Users cannot force something into the session,
though. Barring an exploit that allows arbitrary code, but if they've found
one of those, then adding to the session is probably the last thing on their
minds. 🙂 Again, it goes back to keeping the server secure by choosing
appropriate settings, keeping all of your components up to date, etc.

> I've set up UserGroups for new registrations that only allows own account
> viewing (page restrictions) and I don't want anyone else under data
> protection
> act (unless specified) to be able to access other records.

Your best bet is to use integrated Windows authentication under Active
Directory. That would restrict your users to IE, though, and I believe
you'd have to run IIS as well. Over ordinary connections from any browser,
your session-based logins are the best you're going to do. Just invest in a
certificate so you can use HTTPS when appropriate.

> Thanks
>

[RichardODreamweaver]

Thanks for this Lionstone - I feel much happier.

The validation code is in the index page (Session starts first) with page restrictions on everything else other than login failed.

One concern is your point on https. I'm running a php site on http and don't know if it's possible to convert to https

I can only rely now on our L.A.M.P. hosting provider!

[Newsgroup_User · Accepted solution]

"RichardODreamweaver" <webforumsuser@macromedia.com> wrote in message
news:eutk47$gqa$1@forums.macromedia.com...
> Thanks for this Lionstone - I feel much happier.
>
> The validation code is in the index page with page restrictions on
> everything
> else other than login failed.
>
> One concern is your point on https. I'm running a php site on http and
> don't
> know if it's possible to convert to https
>
> I can only rely now on our hosting provider!
>

The server-side scripting you use doesn't have any effect on that.
Your host likely provides HTTPS with a shared certificate for a yearly fee.
Some do, some don't; more do these days, but you'll have to ask them. 😉