Authentication = Alert/data Integrity & PII protection

Windows integrated authentication is the authentication option of choice for web applications in an intranet environment where users have domain accounts. There is a direct tie to Active Directory and security measures used within Active Directory. It also allows for a single sign-on capability where IIS authenticates the user against Active Directory based on the user’s credentials used to access the PC. In contrary Forms Authentication is an independent simplistic authentication method based on tickets/cookies and specific data prompted for (username/password), passed to the system, and compared with a corresponding value in a database. Alternatively it can be developed to extract a value from the client system to substitute as a username/password, but the authentication process remains the same, ex. EDIPI. Forms Authentication is much less secure and adds risk like data manipulationand inaccuracies in extracted data used in place of a username/password. It does not allow for a single sign-on nor a true PKI/CAC authentication capability, and has added overhead in maintaining separate access.

Windows vs. Forms Authentication:

Windows Authentication: Highly Secure!

Forms Authentication: Not Secure!

  • This authentication relies on code written by a developer, where credentials are matched against a database. Credentials are entered on web forms, and are matched with the database table that contains the user information.
  • It reliant upon the use of tickets concealed with cookies and all vulnerabilities that are associated with such. They are passed/negotiated between the server and client and stored on the client for a particular time period specified in IIS. While the cookie and/or ticket is still within it’s time to live access will be allowed.
  • There is no direct tie to windows authentication nor a users’ authorization to the network or domain.
  • It should not be considered as PKI/CAC authentication referred to by Microsoft as Certificate Authentication or Client Certificate mapping to windows user accounts. Because a user does not have to enter a username/password does not mean the system is using CAC authentication. It typically means they’ve developed a means to extract data that can be used in place of a username/password and match it against data that is prepopulated in the same database. It does not mean the certificate itself is being used and more importantly validated against Active Directory, another Certificate Authority, or a Certificate Revocation List.

Other Mass Notification System’s approach to CAC authentication when using forms based authentication typically includes extracting an EDIPI for the user’s certificate stored locally in the certificate store and matched against the same value that has be populated into a local databased (ex. SQL database).

Ex. C=US, O=U.S. Government, OU=DoD, OU=PKI, OU=CONTRACTOR, CN=DOE.JANE.P.1234567899

This introduces several concerns:

  • The code developed to extract the EIDPI is static and can be flawed in uniquely identifying a user with like entries within their certificate. Ex. If a number is added be (Per above) to distinguish two like names. If the process is designed to extract the EDIPI from a certain location in the string, users with like numbers (2 in this example) could be recognized as the other user. One user could be receiving another’s alert or worse accessing and updating each other’s PII information (ex. Phone numbers, email, first/last name, etc.)
  • The static approach to extracting an EDIPI from a local certificate store can lead to users not being able to connect and receive alerts or operators that are unable to log on to publish alerts. Common causes are expired certs that have not been removed from the local computer, or other users certificate stored in the certificate store as a result of dual logon (normal/admin CAC) or a second user needing to also insert their CAC into a computer to access things like web based IA training. If you own a system that uses Forms Authentication with EDIPI simply check your event logs for unknown user’s or unrecognized user’s. You will notice hundreds or thousands of such entries! This bodes poorly during an emergent event as legitimate and valid users will not be alerted!
  • This method requires that the EDIPI being populated in the database so there is something to compare to during logon. Whether accidental or intentional a user in the system that has an EDIPI entered that matches another user’s EDIPI within the certificate would allow that user access to the system potentially with elevated system permissions not associated with the user account! ex: A basic end-user can have access to the system as a system administrator! The results could be disastrous.
  • This method of authentication does not allow everyone on a network that should be receiving alerts to connect and receive them. If CAC authentication is selected as the authentication method for users, only those users that have logged into a workstation with a CAC can connect. Users still using username and password to access the network will not be allowed to connect and receive alerts.
  • Research on the web and you will find that this method is considered by most as a basic workaround to Certificate Revocation List, Online Certificate Status Protocol to validate a certificate during authentication.
  • Per EDIPI should not be used for client to user mapping because A). It is not in External Certificate Authority certs and B). Introduces significant security concerns.

Desktop Alert Video