Javascript Password protection/domain check 1

[scaifea]

I have built a small website for a community project, the project currently has no funds for proper website domain hosting, so we are hosted by a free host with no CGI.

We need a members only section, I have a small javascript that provides user id and password protection, but once into the members section, its possible for members to bookmark the protected page and come back at a later date (not very secure!), whilst we do not need heavy security, I need some protection.

Anyone any ideas on:

1) A small script that can check someone came from the members page from our domain (if not they will have to enter their user id and password)

2) Forces members to enter user id and password after a period of inactivity (say 1 hour).

Many thanks in advance.

 

[trollacious]

This is a common question here. There is NO really secure way to have a password-protected area on a website without using server-side scripting. There are ways to check logins and passwords against hash values, and only have the hash values stored on the page, but even that isn't overly secure. If this group has something that important to limit viewers on, they need to understand that there's a cost for the security. It'd be like allocating an amount for security locks for a building when you have things you want to protect. If you're serious about protecting those things, you will put out the extra funds for good locks and some real security rather than rely on makeshift, cobbled together, pretend security.

On old boss of mine used to say, "Free is always nice, but often that's what it's worth."

Lee

 

[spewn]

here's what i would do...

manipulate the code from post thread216-1041413, and then:

- create a text file for each user, in that text file have their password, then create another text file using their id again, but this time add a '2' to the end...ie, if user name is 'donuts', then first file is DONUTS.txt and second is DONUTS2.txt...in DONUTS2.txt you have the string 'notLoggedIn'...

then when each user goes to your login page, they will enter their user name and id. when they click 'login' button, your script takes their user id, opens the file that the id matches, and check the contents (password) against password the user entered.

if the passwords match, then open file 2 (DONUTS2.txt) and save the string 'loggedIn' in that file, then send them to your member page, for example membersPage.html?login=DONUTS...

now on your membersPage.html page, you have a script that you run on page load. the script will first check to ensure that there is a value after the '?' in url string. you do this by splitting the url string at the '?' and checking the length of the array. if less that 2, you send them directly to the loginPage.html.

if there is something after the '?', then your script further checks the value/pairs after the '?', (login=DONUTS), takes that value and check to make sure a files exists for the login value. if not, send them back to loginPage.html.

if there is a file with that name, check the 2nd file you created, (DONUTS2.txt) and get that value. if value is loggedIn, do nothing and page will proceed normally. if the value is notLoggedIn, send them right to loginPage.html.

this is rather complex, but it (in theory) will keep a visitor from just viewing membersPage.html, because they would have the neccessary info following the '?'. it will also accomodate multiple users.

remember, this all can be sidestepped by viewing the actual .txt files, but you could also go a step further and use 'bootleg encryption' for the password in file (DONUTS.txt) as shown in the password post thread from above...

let me know what you think.

- g

 

[spewn]

or, i just thought about this...

once they log in you can set a cookie on their desktop. this is good for two reasons...

on your membersPage.html:

1. you won't need the ?login=DONUTS in the url
2. you can check on page load (membersPage.html and any other 'member' page) if that cookie exists, and if not, they get sent to loginPage.html, no way around it
3. you can set an expiration date for the cookie, (an hour or whatever)

go the cookie route.

- g

 

[cLFlaVA]

cookies. definitely not the safest route in terms of security...considering i can email my cookie to anyone i want.

*cLFlaVA
----------------------------
[tt]a frickin' twelve-gauge, what do you think?[/tt]
[URL unfurl="true"]http://www.coryarthus.com/[/url]

 

[kaht]

donuts and cookies, yummmmmm

-kaht

Do the chickens have large talons?

 

[Sheco]

If the private site is not really related to the public side then just host it somewhere else...

Security by obscurity baby!

 

[Sheco]

I am Bill Gates and I approve of this message.

 

[spewn]

mmm...donuts.

well, as far as emailing yourself a cookie...i don't know. if you're doubtful about cookies, just go with my original post.

- g

 

[cLFlaVA]

i'll just stick with server-side validation, thank you very much.



*cLFlaVA
----------------------------
[tt]a frickin' twelve-gauge, what do you think?[/tt]
[URL unfurl="true"]http://www.coryarthus.com/[/url]

 

[spewn]

i'm voting for operator assisted site login through ip validation.

- g

 

[trollacious]

I don't have any idea what that means, but if you say it real fast, it sounds really neat, so I vote for whatever it was spewn said. #

Lee