A multi-factor authentication system. I need feedback and evaluation from you

[sram]

I designed an authentication system as a project for a cyber security class. I want you to critique it please. Here is a quick explanation:


Note: Sorry no images but I'll provide links to videos for the create account and login process

Our authentication system consists of four authentication stages with the third stage disabled by default (An explanation will be provided later). Users start by choosing a username and entering their full name. For the first stage, users draw a line pattern by clicking on a grid displayed on the screen at the time of registration. For login into the first stage the same grid is shown but with a character inside each box. Users need to indicate the same line pattern by inputting characters from the set of characters appearing in the grid using a virtual keyboard. Users need to select characters based on their position on the grid so that it matches the pattern drawn at time of account creation. The character set is the ten digits (0 – 9) and the English alphabets (small and capital letters), which makes the total 26 + 26 + 10 = 62 possible entries. Characters appear randomly in the grid boxes, so a person observing the login process will hardly gain any valuable information. Figures 1 & 2 illustrate the first stage.

Figure 1: Pattern creation for 1st stage

Figure 2: Inputting characters in accordance with the pattern

For the second stage, users need to input four characters—using a virtual keyboard—selected from a set of ten characters according to a certain numeric code specified at the time of registration. The order of the ten characters is random and they are provided from the same character set as the first stage (the full alphanumeric set = 62 characters). The numeric code is communicated secretly to the user. Figure 3 shows the second stage at time of registration and login.

Figure 3: Second authentication stage

For the third stage, the system provides users with a seed value they will need to input into their smartphone to generate a passcode and enter it into the system. At time of registration, the authentication system generates a complex mathematical formula and associates it with the user. The mathematical formula is communicated secretly to the user. The user enters the formula in an Excel like program in his smartphone. For login, the user plugs in the randomly generated seed value into the Excel sheet in his smartphone to get the output. Then, the user finally enters the output (the passcode) into the third stage login screen to be authenticated. Figure 4 shows the third stage.

Figure 4: Third authentication stage

For the fourth stage, users will need to answer a security question selected from a set of questions created at the time of registration as shown below in figure 5.

Figure 5: Fourth stage
As you can see, and in order to maximize usability, we chose to use factors mainly from the “something you know” category for our solution to lessen disadvantages. Only one factor (third stage) can be regarded as one from the “something you have” category. The reason we used this one factor was to add some diversity to the system, and the fact that the item needed to be carried is a smartphone. A smartphone is not an extra item to carry because the assumption is that every individual is in possession of a smartphone nowadays, so the disadvantage usually accompanied with factors from the “something you have” category is not really applicable here. However, the third stage is disabled by default, again to maximize usability and minimize user effort. We also added some properties to the system to improve its overall performance. Properties are:
a. A timeout option of 60 seconds for each stage, after which the user will have to start all over again.
b. For the first stage, the minimum number of boxes for pattern creation is 9.
c. The maximum number of login attempts is 10.
d. The system logs the user out if inactive for 5 minutes.
e. Security questions ask about facts about the user. This makes it easier for the user to remember answers for security questions.
We also chose to make the system flexible by allowing the user to enable/disable authentication stages with two as the minimum number of stages as per the discussion above. Our proposed method uses variations of shared secrets, and aims to minimize the user effort, but thwart almost all types of attacks.


Here are the videos:



Create account Create account process

Login with third stage enabled Login process

I know that the proposed system is an overkill. Most people will not like it. A good defense will be to say that the system is targeted toward a sensitive application like those found in the military. But the actual goal is to come up with a system that balances security and usability.

I need to make it two stages at most with good security.

 

[Schro]

Of note, I didn't watch the videos as I didn't want to install a plugin, but here's some quick thoughts -

1. You already acknowledge that a lot of the stages are based in "something you know" which is often the weakest link for authentication systems. I'm not sure what the scope/goals of the project are, but you may want to consider other types of "what you have" items as well, though, the cell phone assumption is a safe one to make.

2. For seeding the values into your authenticator app, you will want to consider devising a method to prevent a compromised seed from being used by an attacker. How do you know that someone else hasn't swiped the calculator app?

3. For military purposes, this system would trip over their hurdles rather than jump over them. I would suggest taking a look at NIST 800-53 Rev4 for the high risk authentication controls, as that is where military/high level US governments would start for outlining requirements.

4. Since you seem to be doing a bit of fancy cryptography, I would suggest looking at FIPS 140-2 and its annexes which will give you guidance for proper technique on the back end.

 

[sram]

Of note, I didn't watch the videos as I didn't want to install a plugin, but here's some quick thoughts -

1. You already acknowledge that a lot of the stages are based in "something you know" which is often the weakest link for authentication systems. I'm not sure what the scope/goals of the project are, but you may want to consider other types of "what you have" items as well, though, the cell phone assumption is a safe one to make.

2. For seeding the values into your authenticator app, you will want to consider devising a method to prevent a compromised seed from being used by an attacker. How do you know that someone else hasn't swiped the calculator app?

3. For military purposes, this system would trip over their hurdles rather than jump over them. I would suggest taking a look at NIST 800-53 Rev4 for the high risk authentication controls, as that is where military/high level US governments would start for outlining requirements.

4. Since you seem to be doing a bit of fancy cryptography, I would suggest looking at FIPS 140-2 and its annexes which will give you guidance for proper technique on the back end.

Watch them please. You can watch them in a sandboxed environment.

Well, the reason I wanted them all to be the "something you know" category is because I want the system to be highly scale-able and can be applied everywhere. People hate to carry extra items with them, and the "something you are" category requires expensive hardware or hardware which might not be available on all systems. One requirement for the system is to be inexpensive.

 

[sram]

Of note, I didn't watch the videos as I didn't want to install a plugin, but here's some quick thoughts -

1. You already acknowledge that a lot of the stages are based in "something you know" which is often the weakest link for authentication systems. I'm not sure what the scope/goals of the project are, but you may want to consider other types of "what you have" items as well, though, the cell phone assumption is a safe one to make.

2. For seeding the values into your authenticator app, you will want to consider devising a method to prevent a compromised seed from being used by an attacker. How do you know that someone else hasn't swiped the calculator app?

3. For military purposes, this system would trip over their hurdles rather than jump over them. I would suggest taking a look at NIST 800-53 Rev4 for the high risk authentication controls, as that is where military/high level US governments would start for outlining requirements.

4. Since you seem to be doing a bit of fancy cryptography, I would suggest looking at FIPS 140-2 and its annexes which will give you guidance for proper technique on the back end.

Also, isn't FIPS 140-2 a standard for physical requirements for an encryption module? How does that help me? Maybe you mean if I decided to use a hardware module, I need to make sure it follows the standard??

And what do you really mean by "How do you know that someone else hasn't swiped the calculator app?" ? You mean changed or modified the app in the smartphone ? Or caught the formula so that he can use it in his smartphone? Sorry the late replies as I was traveling.

Many thanks.