When authentication is not really an authentication- just identity. We'll talk about a design flaw.
Identity is just identification of entities such as a person, object etc- who they are. But when it comes to prove that who they are, the entities must supply some sort of credentials, such as passwords, certificates etc to prove their identity claim.
Let's consider a hypothetical app which is thick client and 2-tier (which is never a good idea), but let's think about it. It has got following design:
1.The UI is protected by a login screen which requires AD (Windows) authentication of logged in user. The login screen is a separate exe.
2. Once the user is authenticated, a separate UI exe is launched with the logged in user's privilege.
3. The same login screen also provides details of the DB to be connected by this app once the authentication is successful.
What risks we see here apart from the traditional 2-tier risks such as decompiling, business logic at client side, sensitive info in memory etc etc.
From the architectural point of view, we can list down the below risks:
The login exe first accepts logged in user's supplied password and 'authenticates' him/ her with AD. Once successfully authenticated, the login UI launches the the main UI withe logged in user's privilege. Now since they are two different UIs and first one launches the 2nd one, the first one really authenticates the user and the second one just check the id of the logged in user to fetch the relevant privileges to launch the UI.
The noticeable thing here is the second UI is just launched with the privilege of logged in user's id. It really does not perform any authentication on its own, only the the first UI does and once it decides it's valid user, it launches the second UI with the logged in user's id. If we somehow try to invoke the second UI directly, there's no use of authentication, we can still fetch the UI and privilege using logged in user's id. So if we go to second UI's properties to fetch the command and directly executes it to launch the 2nd UI, we are bypassing the authentication screen and using the identification of logged in user.
If an app is designed like that we can easily bypass the authentication, which gives false sense of security that the user has to supply passwords in order to access the second UI.
Another issue with this architecture is, windows auth to the db. It's quote possible to directly connect the db using any other sql client and bypassing the business layer.
Identity is just identification of entities such as a person, object etc- who they are. But when it comes to prove that who they are, the entities must supply some sort of credentials, such as passwords, certificates etc to prove their identity claim.
Let's consider a hypothetical app which is thick client and 2-tier (which is never a good idea), but let's think about it. It has got following design:
1.The UI is protected by a login screen which requires AD (Windows) authentication of logged in user. The login screen is a separate exe.
2. Once the user is authenticated, a separate UI exe is launched with the logged in user's privilege.
3. The same login screen also provides details of the DB to be connected by this app once the authentication is successful.
What risks we see here apart from the traditional 2-tier risks such as decompiling, business logic at client side, sensitive info in memory etc etc.
From the architectural point of view, we can list down the below risks:
The login exe first accepts logged in user's supplied password and 'authenticates' him/ her with AD. Once successfully authenticated, the login UI launches the the main UI withe logged in user's privilege. Now since they are two different UIs and first one launches the 2nd one, the first one really authenticates the user and the second one just check the id of the logged in user to fetch the relevant privileges to launch the UI.
The noticeable thing here is the second UI is just launched with the privilege of logged in user's id. It really does not perform any authentication on its own, only the the first UI does and once it decides it's valid user, it launches the second UI with the logged in user's id. If we somehow try to invoke the second UI directly, there's no use of authentication, we can still fetch the UI and privilege using logged in user's id. So if we go to second UI's properties to fetch the command and directly executes it to launch the 2nd UI, we are bypassing the authentication screen and using the identification of logged in user.
If an app is designed like that we can easily bypass the authentication, which gives false sense of security that the user has to supply passwords in order to access the second UI.
Another issue with this architecture is, windows auth to the db. It's quote possible to directly connect the db using any other sql client and bypassing the business layer.
Comments