Three-tier Password Protection HELP!
- Thread starter McKenna
- Start date
G
Guest
Guest
Blastasbird
Giver of great blow jobs
- Joined
- Feb 7, 2003
- Posts
- 5,489
I don't know if this is what you are looking for
"We therefore suggest a three level security system. Categorising users of the system by
1. The administrators
2. The people responsible for maintaining and updating the information
3. The users
"We therefore suggest a three level security system. Categorising users of the system by
1. The administrators
2. The people responsible for maintaining and updating the information
3. The users
Blastasbird
Giver of great blow jobs
- Joined
- Feb 7, 2003
- Posts
- 5,489
sorry I couldnd't be of any more help
ReadyOne
Ready to Rock!
- Joined
- Mar 31, 2003
- Posts
- 2,112
1. Please post when you lean what the prof thinks the answer is.
Guesses..
1--This is marketing hype. It doesn't show anywhere in google except for press releases.
2--A password allows a certain level of access, such as "read", "write", "control". These are 3 common tiers, but obviously there are a couple missing if you want a real life system
3--Unix "owner" "group" "world" access. Again you have tiers, but it's the userid/pass combination that establish which tier you are in relative to the data being accessed.
4--I doubt it referrs to any sort of 3 times encrypted password. There are better ways to save passwords thatn re-encryption, except to protect a global store (i.e. encrypted passwords are stored in a database which is then encrypted.)
Guesses..
1--This is marketing hype. It doesn't show anywhere in google except for press releases.
2--A password allows a certain level of access, such as "read", "write", "control". These are 3 common tiers, but obviously there are a couple missing if you want a real life system
3--Unix "owner" "group" "world" access. Again you have tiers, but it's the userid/pass combination that establish which tier you are in relative to the data being accessed.
4--I doubt it referrs to any sort of 3 times encrypted password. There are better ways to save passwords thatn re-encryption, except to protect a global store (i.e. encrypted passwords are stored in a database which is then encrypted.)
quickfoot
Really Experienced
- Joined
- Jan 4, 2003
- Posts
- 158
More than likely you are looking for three (or third) tier authentication, using a password is one way of authenticating.
The algorithm used to determine good passwords generally isn't used for the actual authentication of the users.
Taken from http://www.educause.edu/ir/library/html/cem993c.html
Three-tier architecture
The Web security module uses a three-tier architecture to provide application security. This approach has a number of advantages:
* It provides for a separation of services that increases the security of the overall architecture.
* It allows for scalability of the system when required.
* It fits the distributed nature of Penn where staff in schools, centers, and departments work independently and deploy applications on many different servers.
* It can be deployed in conjunction with just about any authentication system. (PAS will likely be replaced over the next several years with Kerberos or another more standards-based authentication system.)
The three pieces of the architecture, as shown above, are the application server, the Web security server, and the PAS server.
Application server. Application developers build applications on their own school, center, or department servers or on the central PennWeb server. This is the primary access point for the user. Developers use a variety of languages and approaches to develop their applications, including simple HTML, Java, **********, and CGI-based programs.
Web security (Websec) server. A central, dedicated authentication server maintained and operated by the central university networking group provides secure, encrypted authentication against the common username space and maintains the state of the user’s connection to the application. This server is operated under the most restrictive access rules of any server on campus and performs this authentication function only. It also runs a Secure Socket Layer (SSL) compliant server. Communications between this server and application servers are encrypted using 3DES encryption.
PAS server. Actual queries for username and password pairs are made against a central SQL-compliant database. The PAS and Websec servers communicate over a trusted network. Passwords sent over this link have been hashed before transmission.
The user accesses the application on a Secure Socket Layer (SSL) compliant browser, typically Netscape 3.n or higher.
Application flow using this model
Using the Web security approach, a Web user passes transparently to the central Web security server to access an application. Once authentication has taken place on the Web security server, a token is passed back to the application provider’s Web server, where the application resumes control for the remainder of the session. If the token is valid, the application can be certain that the user has successfully been authenticated. The application may then continue to check the user’s validity (that is, maintain “state”) using the token on each of its pages. Alternatively, the application may wish to use its own mechanism to maintain state. Once the application is done with the Web security token, it explicitly expires (that is, removes) it from the Web security server. Specifically, the steps involved are:
1. The user goes to a Web page where a particular service or application is offered.
2. If the application that the user wishes to use requires authentication, he or she will click on a link provided, which points to an authentication page on the Web security server. This link will contain a string that specifies the application for which the authentication will be taking place.
3. Upon clicking on this link, the user is transferred to the Web security server and presented with a screen to validate him/herself with a PennNet ID and password. He or she has only 45 seconds to do so.
4. The Web security module authenticates the user. If authentication fails, the PennNet ID/password combination is incorrect, or the time limit has been exceeded, a screen is returned indicating the problem and the process stops. The user is given the option to reload the authentication page and start over.
5. If authentication is successful, the next screen, as defined by that particular Web security application, is displayed to the user. Note that all relevant information about the session, including a unique token, has been passed along so that the application is able to validate the session. This unique session token, or Web security token, has been generated by the security module and has been stored, along with other relevant information, in its token database.
6. The user submits the form. The token is passed by the browser to a program representing the first page of the application, located on the application’s server. With software modules provided by the central computing group, the application can check the validity of the token by querying the security module’s token database, located on the Web security server. If the token is valid, the application knows that the user has authenticated him/herself for that application. If it is not valid, either the user has not authenticated him/herself successfully, the token has explicitly been expired, the token has timed out, or the application for which the token was created is not the same as the one asking for information about the token.
7. For each successive page of the application, if the developer of the application wishes to continue to use the token functionality of the security module to maintain “state,” he or she must pass the token back to the Web browser as a hidden field or set a client-side “cookie” containing the token. Upon arrival at each new page, the application must check the validity of the token, following the rules in the above step. If the developers of the application do not wish to continue using the token functionality of the security module, they can develop their own method of maintaining “state,” such that for each operation a user performs, they have the assurance that the user has been authenticated appropriately. This may be the case for applications which launch client-side programs, such as Java applets.
8. Once a user is done with the application or the application is finished with the security module’s token database, it expires (removes) the token from the token database.
The algorithm used to determine good passwords generally isn't used for the actual authentication of the users.
Taken from http://www.educause.edu/ir/library/html/cem993c.html
Three-tier architecture
The Web security module uses a three-tier architecture to provide application security. This approach has a number of advantages:
* It provides for a separation of services that increases the security of the overall architecture.
* It allows for scalability of the system when required.
* It fits the distributed nature of Penn where staff in schools, centers, and departments work independently and deploy applications on many different servers.
* It can be deployed in conjunction with just about any authentication system. (PAS will likely be replaced over the next several years with Kerberos or another more standards-based authentication system.)
The three pieces of the architecture, as shown above, are the application server, the Web security server, and the PAS server.
Application server. Application developers build applications on their own school, center, or department servers or on the central PennWeb server. This is the primary access point for the user. Developers use a variety of languages and approaches to develop their applications, including simple HTML, Java, **********, and CGI-based programs.
Web security (Websec) server. A central, dedicated authentication server maintained and operated by the central university networking group provides secure, encrypted authentication against the common username space and maintains the state of the user’s connection to the application. This server is operated under the most restrictive access rules of any server on campus and performs this authentication function only. It also runs a Secure Socket Layer (SSL) compliant server. Communications between this server and application servers are encrypted using 3DES encryption.
PAS server. Actual queries for username and password pairs are made against a central SQL-compliant database. The PAS and Websec servers communicate over a trusted network. Passwords sent over this link have been hashed before transmission.
The user accesses the application on a Secure Socket Layer (SSL) compliant browser, typically Netscape 3.n or higher.
Application flow using this model
Using the Web security approach, a Web user passes transparently to the central Web security server to access an application. Once authentication has taken place on the Web security server, a token is passed back to the application provider’s Web server, where the application resumes control for the remainder of the session. If the token is valid, the application can be certain that the user has successfully been authenticated. The application may then continue to check the user’s validity (that is, maintain “state”) using the token on each of its pages. Alternatively, the application may wish to use its own mechanism to maintain state. Once the application is done with the Web security token, it explicitly expires (that is, removes) it from the Web security server. Specifically, the steps involved are:
1. The user goes to a Web page where a particular service or application is offered.
2. If the application that the user wishes to use requires authentication, he or she will click on a link provided, which points to an authentication page on the Web security server. This link will contain a string that specifies the application for which the authentication will be taking place.
3. Upon clicking on this link, the user is transferred to the Web security server and presented with a screen to validate him/herself with a PennNet ID and password. He or she has only 45 seconds to do so.
4. The Web security module authenticates the user. If authentication fails, the PennNet ID/password combination is incorrect, or the time limit has been exceeded, a screen is returned indicating the problem and the process stops. The user is given the option to reload the authentication page and start over.
5. If authentication is successful, the next screen, as defined by that particular Web security application, is displayed to the user. Note that all relevant information about the session, including a unique token, has been passed along so that the application is able to validate the session. This unique session token, or Web security token, has been generated by the security module and has been stored, along with other relevant information, in its token database.
6. The user submits the form. The token is passed by the browser to a program representing the first page of the application, located on the application’s server. With software modules provided by the central computing group, the application can check the validity of the token by querying the security module’s token database, located on the Web security server. If the token is valid, the application knows that the user has authenticated him/herself for that application. If it is not valid, either the user has not authenticated him/herself successfully, the token has explicitly been expired, the token has timed out, or the application for which the token was created is not the same as the one asking for information about the token.
7. For each successive page of the application, if the developer of the application wishes to continue to use the token functionality of the security module to maintain “state,” he or she must pass the token back to the Web browser as a hidden field or set a client-side “cookie” containing the token. Upon arrival at each new page, the application must check the validity of the token, following the rules in the above step. If the developers of the application do not wish to continue using the token functionality of the security module, they can develop their own method of maintaining “state,” such that for each operation a user performs, they have the assurance that the user has been authenticated appropriately. This may be the case for applications which launch client-side programs, such as Java applets.
8. Once a user is done with the application or the application is finished with the security module’s token database, it expires (removes) the token from the token database.
Last edited:
ReadyOne
Ready to Rock!
- Joined
- Mar 31, 2003
- Posts
- 2,112
There seems to be some confusion about three tier models.
Generally, the 3 tier model most often referred to is total software architecture, of which security is just one part.
One frequent configuration:
Tier 1 -- User workstations
Tier 2 -- Applications Server
Tier 3 -- Database server
Separating the application and database to separate machines is packaging which escalates the interprocess communications problem.
An application would naturally (internally) separate data management from application logic.
When both part of the program are in the same user space, interprocess communication is straight forward and can use things like in memory semaphores.
When the application programmer uses a separate database program, then you have interprocess communications (IPC) which normally requires operating system assistance since the two user spaces can't overlap.
Now put the database on a different machine, and you have to have a network talking and network protocols. You get into RPCs or messages and such.
Since you don't have the operating system to assist with interprocess communication over the network, you have two general solutions.
The first puts a part of the data base program on the application server so that the application can use IPC to talk to the DB, and the DB can use the network to talk to the DB server, and since both parts (Application server and DB server) are from a common source they can figure out how to talk to each other any way they want and not depend on the network to do more than deliver messages between the parts.
The second attempts to put generic format messages on the network accompanied by a security token to identify the source/destination. Obtaining a certificate from a trusted party and having each message processor validate it has been quite a challenge. Public key encryption is one way to solve this; trusted authorities is another.
A trusted authority makes the 3 tier model structure bend because the message no longer always flow A -> B -> C -> B -> A. A, B, and C are now all talking to the 4th party (trusted authority/security server) and the hierarchy has become a star.
Now get marketing involved. The technically ignorant idiots combine "good security/security server" with "3 tiered application architecture" and coin a new term "3 tiered password", which doesn't have any real world meaning to someone actually writing code.
No wonder you can't find anything technical about "3 tier password" on google!
Generally, the 3 tier model most often referred to is total software architecture, of which security is just one part.
One frequent configuration:
Tier 1 -- User workstations
Tier 2 -- Applications Server
Tier 3 -- Database server
Separating the application and database to separate machines is packaging which escalates the interprocess communications problem.
An application would naturally (internally) separate data management from application logic.
When both part of the program are in the same user space, interprocess communication is straight forward and can use things like in memory semaphores.
When the application programmer uses a separate database program, then you have interprocess communications (IPC) which normally requires operating system assistance since the two user spaces can't overlap.
Now put the database on a different machine, and you have to have a network talking and network protocols. You get into RPCs or messages and such.
Since you don't have the operating system to assist with interprocess communication over the network, you have two general solutions.
The first puts a part of the data base program on the application server so that the application can use IPC to talk to the DB, and the DB can use the network to talk to the DB server, and since both parts (Application server and DB server) are from a common source they can figure out how to talk to each other any way they want and not depend on the network to do more than deliver messages between the parts.
The second attempts to put generic format messages on the network accompanied by a security token to identify the source/destination. Obtaining a certificate from a trusted party and having each message processor validate it has been quite a challenge. Public key encryption is one way to solve this; trusted authorities is another.
A trusted authority makes the 3 tier model structure bend because the message no longer always flow A -> B -> C -> B -> A. A, B, and C are now all talking to the 4th party (trusted authority/security server) and the hierarchy has become a star.
Now get marketing involved. The technically ignorant idiots combine "good security/security server" with "3 tiered application architecture" and coin a new term "3 tiered password", which doesn't have any real world meaning to someone actually writing code.
No wonder you can't find anything technical about "3 tier password" on google!
G
Guest
Guest
Ain't ascared!
