1. Signature
1.1. How does it work?
1.1.1. The user draws a pattern on the screen
1.1.1.1. The pattern is compared with the one stored on the server. If the algorithm decides they match, the server returns the auth token
1.2. Considerations
1.2.1. Quite secure, until it's stolen
1.2.2. Could be bad UX
1.2.2.1. Hard to reproduce a complex signature on a phone screen
1.2.2.2. Simple signatures are easy to guess (circle, X etc)
1.3. Available solutions
1.3.1. OpenCV
1.3.1.1. SIFT (Scale Invariant Feature Transform) is something that could be used
1.3.1.2. No idea if there is any .NET implementation
2. Dot Pattern
2.1. How does it work?
2.1.1. Uses a dot pattern similar to the one used by Android for unlocking the screen
2.1.1.1. The user defines their own pattern, which is stored on the server
2.1.1.2. The user draws a pattern by connecting the dots and sends to the server the resulting data
2.2. Available implementations
2.2.1. https://code.google.com/p/android-lockpattern/
2.2.2. Easy to create a custom one from scratch
2.3. Plus
2.3.1. Easy, familiar UX
2.3.2. Quite secure, difficult to steal
2.3.2.1. Same security level as a PIN
2.3.2.2. If nobody else sees it, it can only be guessed by usual password-cracking techniques
2.3.3. Server implementation is a no-brainer
2.4. Minus
2.4.1. Can be forgotten often
3. General Considerations
3.1. Using a unique token for each device along with the actual authentication data would improve security
3.1.1. We can use the unique id I'm sending for tracking the UI interaction, or a hash of it
3.1.2. This way, we have the option to blacklist certain devices, if they fall into the wrong hands
3.1.3. One could not login without an approved device id, even if the authentication data is valid (could be stolen)
4. Face Unlock
4.1. How does it work?
4.1.1. The user takes a photo of their face
4.1.1.1. Retake photo
4.1.1.2. Send to server for authentication
4.1.1.2.1. Failure: prompt user to retry
4.1.1.2.2. Success: server returns token
4.2. Considerations
4.2.1. Technical issues
4.2.1.1. Lighting affects the login photo a lot
4.2.2. Security issues
4.2.2.1. Logging in as someone else is quite easy
4.2.3. UX issues
4.2.3.1. Not available on phones with no front-facing camera
4.3. Available solutions
4.3.1. OpenCV
4.3.1.1. Description
4.3.1.1.1. opencv.org
4.3.1.2. Plus
4.3.1.2.1. Free and open source
4.3.1.2.2. Widely used, lots of implementations
4.3.1.2.3. First-party, we don't rely on others
4.3.1.3. Minus
4.3.1.3.1. No idea on what it would take to implement the server-side part. There are at least two wrappers for OpenCV in .NET, but I don't know more details
4.3.2. LambdaLabs
4.3.2.1. Description
4.3.2.1.1. http://lambdal.com/
4.3.2.1.2. Decent pricing: $64 for 5000 face recognitions per month, 1 cent per extra recognition over 5000
4.3.2.2. Plus
4.3.2.2.1. Judging from their documentation and samples, the implementation is piece of cake
4.3.2.2.2. Server-side implementation minimal, the Android client does all the work
4.3.2.3. Minus
4.3.2.3.1. Third-party
4.3.2.3.2. Not free
4.4. Unavailable solutions
4.4.1. The Google API used for Face Unlock on Android 4.0+ devices is closed-source and proprietary
5. NFC
5.1. How does it work?
5.1.1. Encrypted token is written on an NFC tag. Can be done by the user through the application, or by support using a dedicated application
5.1.1.1. NFC tag can be stored in a secure pocket, or attached to a permanently worn accessory (watch, bracelet)
5.1.1.2. The tag is scanned with the phone and the info sent to the server. The server returns the token on success
5.2. Considerations
5.2.1. Very secure
5.2.2. Easy to implement and maintain
5.2.3. Cheap
5.2.4. Not available on the currently used phones :(
6. Barcode / QR Code
6.1. How does it work?
6.1.1. An encrypted token is printed on a badge
6.1.1.1. The badge is scanned with the phone and sent to the server. The server returns the token on success
6.2. Considerations
6.2.1. Insecure
6.2.1.1. Can be easily (even accidentally) copied
6.2.2. Security can be enhanced by using a control token generated by the application, so only requests coming from a recognized source (Android application, website) will be considered
6.3. Available solutions
6.3.1. The implementation is more or less already done, we would only need the UI interaction
7. Voice Unlock
7.1. How does it work?
7.1.1. A voice sample is recorded and assigned to the user, kept on the server
7.1.2. The user is prompted to read a phrase
7.1.2.1. The resulting recording is sent to the server
7.1.2.1.1. The server analyses and compares the two recordings and decides if they match. Returns the token on success
7.2. Considerations
7.2.1. Insecure
7.2.2. Prone to noise
7.2.2.1. Would need specialized algorithms for cleanup
7.3. Available solutions
7.3.1. https://code.google.com/p/musicg/
7.3.1.1. Description
7.3.1.1.1. lightweight audio analysis library, written in Java, with the purpose of extracting both high level and low level audio features.
7.3.1.1.2. Some features can be used for voice identification, no idea how reliable
7.3.1.2. Plus
7.3.1.2.1. Free and open source
7.3.1.3. Minus
7.3.1.3.1. No idea if it works
7.3.2. http://amsecure.aftek.com/
7.3.2.1. Description
7.3.2.1.1. Commercial, not much info
7.3.2.1.2. Seems focused on the client side, lock/unlock access to the device rather than login using a server
7.3.2.1.3. Third-party
7.3.2.1.4. $24 per year
7.3.2.2. Plus
7.3.2.2.1. Theoretically, offers support
7.3.2.3. Minus
7.3.2.3.1. Judging by their website, it's an old-fashioned company, serving large, inflexible corporations. Not exactly what we would need.
7.4. Not available solutions
7.4.1. The Android built in voice recognition
7.4.1.1. Won't work because it's focused on speech recogniton, not actual voice matching