Web-Based Infrastructure within HTTP Access Authentication

Theodore Cacciola Copyright 2014 TCacciola LLC January 15, 2014

Chapter 1: Captive Portals

Web-Authentication (Also Known as Captive Portal) is an easy way for network administrators to provide guest-user access to a network. Essentially, think of a Boolean and an integer combined. A Boolean is a simple programming code for a switch which is also an integer labeled zero or one. If the Boolean or Switch detects an unauthorized user within a said network most commonly a VPN or Wi-Fi hot-spot they are redirected to a web-authentication log-in page.

This authentication is explained further when we go into integers. An integer can assign access levels based on any number possible. Within common programming zero is really one and one is really two but for all intensive purposes well use one through four along with the pre-defined Boolean switch. The switch is there to essentially show in Boolean fashion to determine what the concurrent integer is. When a user has already logged in before and their browsing history or in 2014 fashion their Google or Microsoft account indicates they already have been assigned an integer then they will be automatically logged in. As soon as a user and his machine enter a network this is detected but there are some facets which can be changed outside of auto-authentication and auto-user-login.

The people who program these encrypted networks use programming code which is most commonly used today being either dot net which displays on the page as for example, index.aspx or the language PHP which displays on the network as PHP. That being said programming languages are more commonly not being shown due to the emergence of hackers. For example say you log-into a web-portal and see ?=user_level=2 within your browser window. This would indicate that the authentication type is being hidden but you are a level two user. Lets say youre a level 2 user for Seeking Alpha, you will see this line of code in your browser bar along with your user name. Something like user_level=2 and user_id=1156. This would be shown in some order but in many cases only your user ID will be shown and not your user level. To the point, a level 2 user is Web-Based Infrastructure within HTTP Access Authentication | Theodore Cacciola Page 1 of 5

typically a contributor, or author. They have different access to what a User level of 1 has. If you have no credentials but you can log-into a web portal you are almost definitively a user level of 1 or zero if the language starts at zero. These contributing users have no administrative rights and typically your user level would have to be 4 or 5 at the most in order to manage the content and privileges of other users.

The main benefits of this solution come from not requiring additional customer knowledge. For example you as a user who is deemed active by the network server are only viewing front-end technologies. What the level four or five user wants you to see. You may have access to change things like your password or profile picture if you were a user in a social network but you have no administrative privileges unless, in most cases you are a level 3 but sometimes level 2 user.

If you are a user who is Active or more commonly put Turned On you are typically able to quickly and easily access the network or network information if you are a higher-level user. In todays Web 2.0 spectrum this ease of access has become so prevalent that once you are active within one device you are typically active among all your devices from your smartphone, to your tablet, to your personal computer.

Web-Based Infrastructure within HTTP Access Authentication | Theodore Cacciola

Page 2 of 5

Chapter 2: Client Authentication

To summarize what well be talking about within the Client Authentication Chapter. Client Authentication creates two facets, the front-end interface between the client and user to a server on the web. The Administration Interface sometimes known as the back-end interface is comprised of things such as C-Panels, File Transfer Protocols, and Secure Socket Layers, which we will go over later in this chapter.

The client generally interacts with the server using an HTTP or HTTPS request. An HTTP Request stands for Hypertext Transfer Protocol. This HTTP request is typically used over networks using TCP, FTP, or SSL. HTTP but regardless of how the information is requested the client or user front or back end must provide an authentication token or authenticator with each request.

There are many technologies which assist in the computation process as well call it such as Java, Dot Net, Tel & Active X, these are flexible forms of client authentication computation & these technologies assist within the computation process. Although languages like Java are built into many Web 2.0 operating systems such as Android where Java is pre-installed along with Flash in common day technologies in the year 2014 languages such as Flash are not always available for the computation process. For example on the Apple Store for iPhones Flash & Active X are both not pre-installed within the system configuration and the endusers must buy the configuration assistants from their Apple Phones store in order for the computation process to occur. Although these computation assistants are, in fact becoming more and more lightweight while Apple struggles with licensing for flexible forms such as Flash & Active X these computation assistants are being built-into almost every browser available. The two most common are Mozilla Firefox, which is available on Mozilla.org and Google Chrome, which youre probably familiar with but an operating system which aggregates Mozillas technologies and in-puts in-browser technologies to assist with the computation process. Web-Based Infrastructure within HTTP Access Authentication | Theodore Cacciola Page 3 of 5

The aggregate summation of data entries such as encryption processes in passwords within HTTP Basic Authentication is too large in storage space to store for example within a MySQL database. The end-users browser can only store information which is associated with realms and the conversion assistant from browser to server became hard years ago with limited storage space available and prior to the implementation of the large-scale SQL database and other associated Microsoft Databases in which case the commonly known Cookie was established. Instead of storing passwords using Basic Authentication cookies allow a server to store a value on the client within the FTP model. Within an HTTP request the cookie is known to be as it is, stored within the system and instead of storing the aggregate information of the user that information is essentially zipped and sent to the users local host (or the hard drive on the computer). The server then stores the cookies in a time-sensitive manner and the server or database controls how long cookies are kept and to which servers they are sent. That is how for example, when many users use Chromes commonly used Incognito Mode or any form of private browsing the cookie is discarded immediately. So, in essence, rather than having the host user or server store large quantities of information in the form of Basic HTTP Authentication the information is stored on the end-users local host and cookies have become the most widely deployed mechanism for maintaining the client state.

The concept of Granularity refers to the FTP model and how users are identified throughout their presence within a local machine. Some servers identify individual users throughout a session while others identify users only throughout their first request. In most instances within 2014s Web 2.0 users are identified throughout their entire sessions while in some remaining cases they are not. The example we will use is password protected web infrastructures. In many password protected cases still today the user is only identified through their first request. Instances in many cases are through modern day niche social networks where only instance pages are deemed by administrators suitable for indexing or the process of being listed on search engines.

Web-Based Infrastructure within HTTP Access Authentication | Theodore Cacciola

Page 4 of 5

Chapter 3: Hardware Authentication

Here, we discuss the concept of multiple authentication modes. Web 2.0s infrastructure has created two different nodes or partitions which have become a requirement for post-data within the front-end user interface but in (somewhat) recent years simply the password along with technological expansion has created to facets, to nodes, to authenticators which have made the end-user although still prone to becoming hacked, once the end-user becomes aware of web-based malware two forms of authentication have been established as the benchmark, the age-old password and now the emergency authenticator.

This is becoming more & more common within social networks. With phones becoming so wide-spread not only on Facebook for example are you required to provide a password to accompany your e-Mail but also in most cases a phone number. Upon expansion of this topic there are three primary modes of authentication being e-Mail, password, and phone number with at least password and e-Mail as two of the three key authenticators. Emergency authenticators are expanded with personal questions such as Name of your first car or Name of your first pet.

The three authenticators are commonly known as something you know, something you have, along with something you are. The problem that is arising is that the facet of something you are is becoming more and more widely-spread among the general webs disbursement of information. These are known as biometric indicators which authenticate users based upon physical characteristics such as voice recognition. For example, in Google Moto X phone your voice controls Google Now. You do not have the pre-configured option to just say OK Google Now but Googles phones are now authenticating things like your voice and your fingerprints for more absolute recognition.

Web-Based Infrastructure within HTTP Access Authentication | Theodore Cacciola

Page 5 of 5