Tech Support banner

Status
Not open for further replies.
1 - 4 of 4 Posts

·
Registered
Joined
·
12 Posts
Discussion Starter #1
Excuse my ignorance if this question has been placed in the wrong forum, but I have a question for you all. How would I go about creating a "secure" site? I'm not HTML inclined, though I can learn if somebody could help. An example of a secure site is here: http://www.vatusa.org/staffsecure

This website will ask you for a password, and then will either let you pass or stop you. (Whether or not you know the password.) How might I create one of these sites?
 

·
Registered
Joined
·
1,691 Posts
:coffee:

There is a difference between a secure site (SSL) which is an encrypted page and a password protected directory. If you just want to password protect a directory inside your web you can most likely set up a password protect on that directory within your site by making the proper modifications in your Admin screen of your web-hosting service. Unless your using frontpage to publish then, your web-host must have Front-Page Extensions enabled for you to be able to password protect "sub-webs"(Directory's)

You could also use a Java script as a password protection method, but this is pretty hard to do if your not good with programming, most of the pre-made freeware Java password protect scripts have the password in plain site within the HTML code, which means anyone viewing the source code from the browser can easily see the password. Also Don't bother with the right click disable scripts either, their a joke you can still see the code by going to View > Source.
 

·
Registered
Joined
·
1,481 Posts
Taken from Cramsession -Security insider--

Web Server Authentication Explained - Part 1

I was in a discussion the other day, about how Web browsers can proof the identity of a user to a Web server. Amazing how many different ways there are to accomplish this. For this week's Security Insider, I want to get technical, and explain some of the authentication mechanisms that Web browsers can use when talking to Web servers on the Internet.

First of all, let's define what we mean by authentication. That's the process of proofing your identity (usually symbolized by a user name and password combination) to a server. Authentication is typically used when the Web server has an interest in knowing who you are. This could be because the content is customized for you, or the Web site uses a subscription model, and wants to ensure that you are the same one who paid earlier.

Over the years, many different authentication mechanisms have been developed. Let's have a look at some of them:


1) HTTP Anonymous Authentication

A.k.a no authentication. Not really something to proof here, of course. And the name is a bit of an oxymoron as well, but this is the default behavior of any Web browser. When connecting to a Web site, using HTTP, the browser will always first attempt to connect without any authentication. Good choice, since almost all Web sites out on the Internet allow anonymous connections.

The browser will send out an HTTP GET request, and the Web server will respond with an HTTP 200 code and the requested Web page. 200 is HTTP-speak for OK, indicating that we are good to go.


2) HTTP Web page with user name and password fields

This is very common, and relatively easy to implement. A Web page, built by whoever created the Web site, will appear that asks for a user name and password. After the user has filled in the information and presses a Submit-style button on the page, the user name and password is sent to the Web server. The assumption here is that the Web server has some way of knowing whether the user name and password are the correct combination, and continues from there.

Problem with this approach is that the user name and password is sent in clear-text over the connection. The HTTP POST request, that is sent by the Web browser, will contain literal text as in: USERID=John&Password=Malibu. Anyone who is able to listen in on the connection can obtain the password, and use it. (We will look into combining this with HTTPS, encrypting the network traffic, later.)


3) HTTP Basic Authentication

Basic authentication is defined in 1996, with the introduction of the HTTP/1.0 standard. The idea is that you do not have to create a special Web site with user name and password fields to fill out, but that the Web browser will display a dialog box asking for that information. After you pressed the OK button, the information is sent to the Web server.

The exchange is as follows. The Web browser starts by sending an anonymous HTTP Get request. But this time the Web server does not respond with code 200, but instead sends back HTTP 401, meaning "please authenticate". It also includes a list of possible authentication mechanisms in its response. In this case "Basic" would be in that list. The Web browser then displays the dialog box prompting for information, and subsequently sends the same HTTP Get request again, but now it includes an Authorization header, containing the user name and password, separated by a colon-character.

(I am personally a bit surprised that they call this the Authorization field, and not the Authentication field.)

Because a password may contain characters that do not transport well over HTTP, the "username:password" information is encoded in a special way. Every 3 bytes (24 bits) is split into 4 times 6 bits, each representing a character in the set A-Z,a-z,0-9,+/ (64 characters). This is called Base64 encoding. So the returned Authorization header may look like:

Authorization: Basic Um9uYWxkOm5pY2UtdHJ5IQ0K

Once you know how to decode it back, it's easy to obtain the username:password text from the Authorization header again. In fact, it is so easy, that many authors describe Basic Authentication as sending the user name and password in clear-text.

An attacker who is listening in on the connection can pick up the Authorization header and obtain the password. And, the attacker doesn't even have to hurry. Because HTTP is in principle a stateless protocol, the Web browser will continue to send this Authorization header in every GET request to the same Web site. (Again we will combine this with HTTPS later.)

Note that Basic Authentication has another weakness too. Even if an attacker would not know how to decode the base64 information, the same Authorization header is used on any connection. In other words, this is vulnerable to a replay-attack. If you just record the Authorization header and play it back later, the Web server will accept it as valid credentials.

The next authentication method is able to withstand that.


4) HTTP Digest Authentication

Digest authentication is designed as a replacement for Basic authentication. It is a so-called challenge-response authentication mechanism, which means that every time it is used, the server sends the client a random value first (the challenge), which should be included in the returned result (the response). The net result of this is that the authentication data looks different each time. This limits the possibility of a replay attack.

Digest authentication gets its name from the fact that it calculates a "digest" value or checksum of the password, and sends that back to the Web server, instead of the actual (encoded) password. Assuming that the server knows the password, it calculates the same checksum, and if they match, then the server can conclude that the Web browser started with the correct password. Digest authentication uses the well-known MD5 digest algorithm.

Here's how the exchange goes. The web browser sends an anonymous HTTP Get request. The web server responds with HTTP 401, including the indication that it wants "Digest" authentication, plus it sends back a server-generated random value. This challenge value is often called "nonce". (I like that word, it sounds made up, but contains "once", which describes it rather well.). The Web browser displays a dialog box prompting for credentials and sends back roughly the result of the following calculation, in the Authorization header:

MD5(MD5(username:password):nonce)

Let's continue this discussion next week, and look at why this is chosen, and then we also still have to throw HTTPS (SSL) in the mix.
 
1 - 4 of 4 Posts
Status
Not open for further replies.
Top