Password protecting a website
I work at a website design company. We are currently developing a site that requires a password-protected Member section. A site done at this company before I started working here has a page that is password protected in theis manner: The page is a ColdFusion template with an HTML form that requires you to enter a username and password. The username and password are checked by querying a database that contains the usernames and passwords. If the the username and password entered in the form match both fields in a given record in the database, the template writes a cookie on the client machine and allows them to continue to browse the site. Is this a secure way of implementing password protection? All of the information I have seen regarding this talks about HTTP Authentication, which is obviously not employed in this scheme. Any information appreciated, thanks.
June 14th, 2001, 06:50 AM
most obvious way
most obvious way is to use SSL. That is, let the user go to a form that asks for username and password, and when the form gets submitted the action is https:// based. This will give you a reasonably sound level of security. Without SSL, you'll basically have any credentials entered in the clear which is open to sniffing and spoofing, etc.
Free small footprint web server for Windows
PHP, P2P file-sharing, transcoding and more
June 14th, 2001, 10:05 AM
So HTTP Authentication is basically worthless?
June 15th, 2001, 10:04 AM
HTTP Authentication isn't really worthless because it will keep your basic Internet user out of areas they don't belong, but on the other hand a knowledgable person could bypass this without much effort. Although these passwords are encrypted, they are transmitted in base64 format which is not difficult to decrypt.
Apache with SSL is not real difficult to set up, so if you are looking for a more sound form of security, then SSL is the way to go.
June 18th, 2001, 10:57 PM
SSL vs Non SSL
http -> form submit is clear text [post and get]
so if a user cannot see a password on his own client machine
because the input field is "password" vs "text" then when it
is submitted the password is in clear text.
https -> does some encryption so the submitted fields are not
clear text in the packets.
The strength of the cipher 128 vs 40 or none and the hope
someone is not collecting all your packets is part of the problem/
At work for the "Boss" I setup one of these packet catchers
[ big brother company is watching you ]
and I could see all web and email traffic in plain text
[ you have to look at the packet headers and such also].
But soon You only see the messages and the sites people are visiting.
If the traffic was https then decoding would be needed but it is not for most.
Foot in Mouth ver 1.2.5 Onion