User Device Verification (UDV) as part of Two-Factor-Authentication is a process that establishes an additional security layer on applications that handle sensitive data.
UDV is built on top of a normal Authentication (Username/Email/Password) and targets the device the user is currently using to log in to an account.
Ways of implementing UDV
There are two ways to implement a UDV, depending on the security needs of the application.
Passive UDV
A passive UDV stores device information permanently (in a database), once a user authorizes a certain device to use the account, it will be stored forever (although devices can also be manually de-authorized).
Active UDV
A active UDV stores the device information permanently as well (also in a database), however an additional security layer is established by storing a verification string (matching the current account AND the device information) as a cookie, session string or local storage string.
If a user clears the browser’s cookies, the session expires or the local storage is emptied, the device is automatically being de-authorized and has to be verified again before using it.
In addition to manual deletion of those verification strings, the system can issue the generation of a new string every time the user logs into the system (or on an interval basis: daily, weekly, etc.).
If we assume that a user logs in on a daily basis, a new verification string would be generated every day (without asking the user to re-verify the device).
How UDV works
UDV stores a set of data to ensure that the user is using an authorized device with it’s corresponding user account:
- Browser header
- Operating System
- Device specifications (if available)
- Browser time
- Browser timezone
- IP address
- Proxy IP (if available)
- Forwarded IP (if available)
This data is encrypted and stored in the database, along with the user’s account information.
If the user logs in to the application, the system will not just check for valid credentials (Username/Email/Password) but also if the current device “matches” one of the known devices stored in the database.
Depending on the security needs of the application, one or more data components can be ignored if they don’t match (Proxy IP and Forwarded IP if the Remote IP address is the same), or the system can be advised to match only exact data sets.
If the system detects a known device, the user is being logged in without any further steps.
If the system does not detect the current device as a known one, it will prevent the user from logging in and instead send an email/sms to the user, requesting to authorize the device.
In case using a different device than before is an intended action, the user can enter the code that was sent via email/sms and the device will be authorized. The next time the users uses this device, the system will not ask for a verification anymore.
It is possible to store an unlimited amount of devices per user.
Advantages/Disadvantages of using Email/SMS for receiving verification codes
Sending verification codes via Email or Text message (SMS) can have a huge impact on the security grade of a UDV.
Sending verification codes via email
Not only probably the easiest and fastest method of sending verification codes, also the mail server can possibly be a part of the application. This allows fast and secure distribution of verification codes.
However if the email account for example uses the same username/password combination as the application itself, or in addition to the user account the email account was hacked (accessed by a malicious entity), the UDV does no longer work, since the verification code can easily be caught and entered by an authorized user.
Sending verification codes via SMS
Although it seems overprotective, sending verification codes via Text message (SMS) provides a greatly higher security than sending them via email.
If we assume that a user account as well as an email account can be accessed by someone unauthorized, your cellphone’s text messages are quite a bit more difficult to access. Sending the verification via SMS protects your account even after it was attacked.
However, sending text messages via the internet requires a 3rd party provider, which often is paid (if it has to reach a certain reliability) and can not be directly under the control of the application.
Problems and known security issues
Although UDV in combination with a normal authentication is a heavy protection system that cannot be easily hacked, it is possible to “fake” device data and send it to the server.
The server has no possibility of verifying the device data, it can only compare it to known sets of data.
- I can change what the browser is sending as the BIS(Browser-Identification-String), this includes current browser, device and operating system
- I can change the time and timezone the browser is using (by changing the system time)
- I can hide my IP, fake a proxy or hide my forwarded IP
- Cookies, session strings and local storage strings can be manipulated
This problems may only occur when using a passive UDV.
Using an active UDV creates an encrypted string that is extremely difficult to encrypt and can change on a daily basis.
