What is the difference between “Authenticated” and “Unauthenticated” Scanning or Testing?
Unauthenticated = No usernames and passwords are used in the scanning or testing.
- This means if your website allows users to create a shopping cart tied to a user, the testing will not attempt to use a username and password to replicate a user’s usage of that shopping cart.
- This type of testing is typically less intense because it will only be able to find basic configuration issues or input and output validation type errors that don’t include the code base that handles user transactions like shopping carts.
- Unauthenticated scanning and testing may attempt username and password combinations to attempt to logon to your system, but they typically only check to see if the credential is valid, and will not use it to login to the system to perform further testing.
Authenticated = The scanning or testing is able to use usernames and passwords to simulate a user being on that system or website.
- Authenticated testing can be much more intense and have the possibility of causing impact to your website or system.
- Authenticated testing will usually find more vulnerabilities than unauthenticated testing if a vulnerability scanner is given credentials into a system. This is simply due to a scanner’s ability to see more of the system due to being able to get “inside” the system and validate issues instead of the guesses that a scanner or tester must make without authentication.
- Authenticated testing has much better code coverage on applications since it can simulate much more of the user based functionality like transactions.
- Some authenticated and un authenticated scans can simulate “brute-force” style attacks, which could cause account lockouts depending on your system configurations.
Why should I care?
- Authenticated testing is much more thorough and is often able to find more issues than unauthenticated. However, it is also more likely to cause issues on a system or application.
- Since authenticated testing will often find more, you will spend more time parsing through data and trying to determine which findings are higher risk.
- Finally, unauthenticated testing alone will not simulate targeted or successful attacks on your application or system, and is therefore unable to find a wide range of possible issues.
Ask yourself these questions to decide what kind of testing or scanning you need.
- What is the purpose of the scan or test? (Specific compliance requirement??)
- Do my scanning or testing requirements give preference to authenticated or unauthenticated testing?
- Do I want to simulate what a user on the system could do? (Go with Authenticated)
- Do I want to start at the highest risk findings that any scanner or user on my network could find? (Go with unauthenticated)
- Is this the first time the system or network has ever been scanned or tested? (Go with unauthenticated unless you have other requirements.
So what should my approach be?
Using a risk based approach, you could start with unauthenticated scanning and testing because it will typically find the highest risk and most significant issues. Once you have the unauthenticated findings, you can gradually start authenticated testing once you have a good comfort level that it will not impact systems.
Note*** In large environments you may need to be wary of old printers and devices that may have old network stacks. You will typically only see scan issues on legacy network appliances or devices like old network printers.