jspωiki
Web Blog_blogentry_180317_1

2017-03-18#

Typically#

Typically, when we access a Website we do this in an effort to access Data of some type. Perhaps we need to access data about the news or we go to our Financial Institution to access our bank account. The "news" and our bank account are Protected Resources. The news may not requires Authentication to read the news, but we probably can not change the news without Authentication.

When we access the news, the website may not need to Authenticate the user (to read the news). (Even though the website may perform Identification using a cookie or some other method.)

When we access our Financial Institution we will and probably insist that Authentication be performed on the user accessing our bank account.

Use case Copy Password#

We have all probably used these sites or applications. These "Client Applications" allow us to access some Protected Resource. Like our bank account.

Some of these create a "Password Vault" in which you store your passwords to other sites. Hopefully they protect this "Password Vault" well. Then they replay your password to the other sites to access the Protected Resources. (This is impersonation, not delegation). The Protected Resources thinks it is you accessing the resources and has no idea it is "Client Applications".

This use-case also exposes the user's credentials to the "Client Application".

One of the biggest violators I know of is Quicken.

Some other Client Applications may just ask for our credentials to access the bank account in real time and do not use a Password Vault.

In both of these Use cases, the Protected Resource (our bank account) has no methodology to determine that ti was the Client Application accessing the Protected Resource rather than Us. This is impersonation. The Client Application is impersonating us and the Protected Resource has no method of Auditing to say otherwise.

Use Case Enterprise LDAP Authentication #

Many enterprises use a central LDAP for authentication services. Interestingly, this pattern is similar to the Password Vault Authentication Method. When using LDAP for authentication, a Client Application collects credentials directly from the user (in Plaintext) and then replays these credentials to the LDAP server to determine if they are valid. The Client Application must have access to the plaintext password of the user during the transaction; otherwise, it has no way to perform LDAP Authentication.

In a very real sense, both these Use Cases is a form of Man-In-The-Middle attack on the user, although one that is hopefully benevolent in nature.

In a typical Enterprise LDAP Authentication setup, the user's credentials may be exposed to several applications and each of these applications are an exposure to an attacker.

Both of these approaches, the Client Application is impersonating the Resource Owner, and the Protected Resource has no way of distinguishing a call directly from the Resource Owner from a call being directed through a Client Application.

Both of these approaches, are a Password Anti-Pattern of Sharing Your Password

The import differences Delegation vs Impersonation #

More Information#

There might be more information for this subject on one of the following: ...nobody